General design question: Mirth as mediator database for FHIR resources and change notifications to involved systems?

[usrflo]

I tested the FHIR Listener Example and see that all FHIR resources are saved to a single database table backed by this example.

I wonder if this database setup is meant as a test setup only or if it might be production ready to use postgresql with this single table design as a mediator database that fills up over time with any changes and history data. What about performance of XML search queries on postgresql if there are a million records in the resource table?

---

Next I think about creating update notifications to all consuming systems: instead of sending FHIR resources directly after create/update/delete operations, it might be more efficient to send notifications and let the consuming system fetch the data when and if appropriate.

More specific I think about the development of a Javascript function

• to detect the source system of a create/update/delete operation to determine the consuming system(s)
• increase a system version counter to detect missing notifications on the receiving system
• send out a http-post with FHIR resource type and involved UUIDs (1...n), operation and system version
• queue some lastest http-post requests with Mirth's queuing mechanism if the receiving system cannot be reached for a short time

Is this design reasonable or might there be a better approach, e.g. sending FHIR resources directly to consuming systems?

[narupley]

Yes you're right, it's meant to be primarily a test setup / example of how to integrate the FHIR extension with a database. The specific database structure others may need to integrate with will almost certainly vary widely from company to company, vendor to vendor, etc.