I do apologize if the following question was asked before. I have searched for the previous post and haven’t found the similar post.
The question is regarding the value of converting event based v2 messages (received by the interface engine) into FHIR resources and uses the FHIR resources to serve up API requests, e.g. patient demographics, encounters, outpatient appointments, referrals, etc. The V2 to FHIR conversion can be implemented as an asynchronous process and keep the resulting FHIR resources in an FHIR based persistent layer for fast retrieval via RESTful APIs.
If this sounds something worth to do, the next question is around how the resources are better stored in the persistent layer, as FHIR Message Resources, or should be stored as separate FHIR resources?
That general architecture is fairly common. In most cases it’s going to be easier to persist separate FHIR resources for Patient, Encounter, etc rather than storing a whole Message as a big bundle. That makes it easier to index and search the database. And the real benefit of the FHIR REST API is in allowing clients to retrieve just the resources they want as small chunks.
Thank you for the reply, much appreciated. We are a health IT services provider and generally we prefer not to build the FHIR server and its persistent layer. Can I ask for some recommendations of commercially available FHIR servers, which are mature enough for production use, including the v2 to FHIR conversion components?
At the moment, we are not in the position to replace the entire integration engine, but would like to add the FHIR capabilities to the existing integration platform.
There are several production ready servers, such as the HAPI FHIR. For commercial support, see https://smilecdr.com/. If you prefer #Net - talk to firely.com