Thanks for this Craig, this helps move things forward. Before we jump into some of the design choices that this lays out though I think we need to complete the spike we have written for choosing FHIR libraries and servers: https://openlmis.atlassian.net/browse/OLMIS-4188
I also don’t think we should call Nifi “the OpenLMIS v3 integration engine”. It’s certainly a tool that we’re interested in, however with micro-services I think we should keep in mind that we prefer “smart endpoints and dumb pipes”.
In this particular instance this means that we’d prefer the Reference Data service to more natively use a FHIR server as a data store (much as it does with Postgres), than we’d like to offload FHIR knowledge into a “smart pipe” such as Nifi. With HAPI-FHIR we should have Java libraries that we can add to Reference Data service to enable more of that natural FHIR capability. This is all not to say I’ve reversed my thoughts on proxying
et al requests to a FHIR server, rather I’d rather we do that and treat it as a data store of Reference Data service, and Reference Data service would still be responsible for handling concerns of auth, auditing, etc.
Overall this looks good though, thanks again.
On Friday, August 10, 2018 at 8:27:43 AM UTC-7, Craig Appl wrote:
I just finished writing the Software Requirement Specification for the OpenLMIS Facility Registry using the mCSD standard. This captures and expands upon the prototype that was developed by Elias at the OpenHIE Connect-a-thon. You can view the document on the OpenLMIS wiki.