OHSUCMP / coach

web application frontend for OHSU HTN U18 grant
2 stars 0 forks source link

build out fallback strategy for when Logica is down #31

Open mattStorer opened 1 year ago

mattStorer commented 1 year ago

Logica, the sandbox repository we use for local development, can be flaky. When it flakes out, it reports no patients in any of our test repositories, which makes it impossible to conduct local testing.

this is a problem.

proposed solution is to copy one or more Logica patient resource bundles, rename their IDs, etc. appropriately, and store them locally as serialized JSON flat files in the COACH repo. Then, adjust COACH logic such that, when configured to operate in this way via some property set in application.properties most likely, to read these resources in from those flat files instead of going out to the FHIR server to get them. we would need to prevent writebacks in this case (this flat-file repository would need to be read-only), but that's okay.

to start, we just need to be able to launch COACH and have it load the UI and run recommendations in the absence of a viable sandbox to test against.

we could even possibly tweak those resources to dynamically set the dates in them, which could be good for testing (e.g. replace hardcoded timestamps with something like "{now-2m}T10:30:00Z" or something like that, where {now-2m} would get replaced with a date that is two months ago from today. this would help resolve the issue of system logic changing as time passes due to different things getting out of their respective time windows, if that makes sense. but this is a downstream need, not immediate.

mattStorer commented 1 year ago

strategy :

FHIRService should be made abstract, and have two implementing classes - RemoteFHIRService and LocalFHIRService. the Remote version would operate as it currently does, executing search-API calls to remote FHIR servers. the Local version would operate on the locally-selected Bundle specified by the user at launch. to build out the search logic in this class, we would want to iterate over Bundle items and use SearchParamMatcher to identify matches.

see https://stackoverflow.com/questions/61884285/validate-if-a-resource-matches-a-search-criteria for details

all that should be required then is to be able to configure which implementation to use. this should be pretty easy as we already perform a similar operation with VendorTransformer.

mattStorer commented 1 year ago

mostly complete, just need to sort this last bit with SearchParamMatcher which is having issues, of course. got a post out on HAPI FHIR's Google Group seeing if anyone has any ideas. see https://groups.google.com/g/hapi-fhir/c/BneijhIFXMw/m/s_tSaRf3AAAJ for details.

mattStorer commented 1 year ago

sent email to Bryn requesting assistance sorting out detached usage of SearchParamMatcher, it appears that the issue with its usage blowing up relates to autowired dependencies not being found. I've identified a way to resolve these through COACH, but some of these dependencies are easier to resolve than others. hoping Bryn knows a way to do this in a less painful manner.