Stream: social
Topic: Is FHIR just interoperabilty platform or architecture base?
Michael Austen (Nov 02 2017 at 18:33):
Hi All,
I am just new to FHIR stuff. We are planning to develop in house EMR, ADT, Pharmacy , RIS and LIS components. We are very enthusiastic about using futuristic FHIR stuff more than just for interoperabilty with other hospitals and patient Apps. infact for time being interoperabilty is of least priority for us. What we are concerned is the capability of FHIR to act as complete back end data exchange platform between independent modules of OPD/IPD EMRs, Pharmacy, LIS and RIS deployed in a single hospital connected over LAN? would that FHIR based setup enable me to have complete real-time data exchange and notifications between these modules and operate seamlessly in realtime handling all kind of required communication between these modules for differnet hospital's HIMS workflows, by deploying a comprehensive FHIR server? We have concerns and unclear if it can be a seamless functional alternative to direct real time messaging like simple plain TCP sockets between different ancilliaries and OPD/IPD with in premises of a hospital.. kind suggestions are required and welcome from respected group members... If yes , is there some one who has used this or it is infeasible for this situation?
Grahame Grieve (Nov 02 2017 at 18:42):
I think it's feasible for all this, but AFAIK no one has actually done it
Michael Austen (Nov 02 2017 at 18:52):
Graham thanks for quick reply. Can you please guide base on your experience what is normal practice by solution providers to integrate these different ancillaries to make communication real-time when deployed in single hospital? HL7 or core communication tools like plain sockets, message queues or through database?
Grahame Grieve (Nov 02 2017 at 19:02):
hl7 for now because that's what trading partners are able to do
Michael Austen (Nov 02 2017 at 19:07):
Do you think FHIR stack latest version is mature and comprehensive enough to build a fully functional commercial product based on FHIR or we should stick to old but prevalent HL7 to secure investments?
Grahame Grieve (Nov 02 2017 at 19:13):
that's not a binary choice. I think that the stack is mature, but the contents of the resources are still stabilising. And if you are greenfield and interested in communicating internally, FHIR would be an obvious choice. But if you need to exchange data with other systems, then right now that will mean HL7 v2
Michael Austen (Nov 02 2017 at 19:23):
Thats really helpful.. Highly appreciated...One more important question if we decide to integrate all inhouse ancilliararies via FHIR, we will need to go via FHIR Messaging framework instead of RESTfull due to realtime exchange of two way requests, events notifications .. Are we on right track? and do we need to adapt a FHIR Adapter approach connected with DB of each ancilliary for translation or It will be FHIR EndPoint architecture with all DB schema based on FHIR Resource definitions for respective ancilliary data storage?
Grahame Grieve (Nov 02 2017 at 19:31):
you will probably need a combination of push and pull. You can implement push without messaging (just us the RESTful API and subscriptions). The Messaging framework is about routing and delayed delivery. If you need those things, then you should look at messaging
Grahame Grieve (Nov 02 2017 at 19:31):
I don't understand the second question
Michael Austen (Nov 02 2017 at 19:39):
Yes . Push is fine but doubtful about PULL or realtime notifications .. doable by RESTful .. not sure ?
Second question was about architecture.. should we design DB Schema independent from FHIR and then write FHIR adapter with every ancilliary for communcication with othe modules/ancilliaries Or we should design schema of each ancilliary directly mapped to resources defined by FHIR for respective ancilliary? For us that latter option seems bit impractical as one thing, FHIR Resource definations may not contain many hospital specific item defincations and second resource definations of FHIR are still evolving and immature? Which path for DB design would be better to make it deployable as fully functional solution in any hospital?
Grahame Grieve (Nov 02 2017 at 19:48):
there's certainly systems out there using a pure FHIR store at the back end. They do have to deal with the evolving-ness of FHIR. Most of these are post-sql databases, with the strengths and weakness of these types of systems
But most systems of your type would define their own relational database model. It wouldn't be the same as FHIR, but FHIR (and other formats) are implicit informational requirements that will infuse through the system design
Michael Austen (Nov 02 2017 at 19:57):
So grateful for this detailed response.. What I have concluded from your guidelines that we should build customized relational schema for each ancillary and write FHIR adapters for each ancillary for communication with other ancillaries to avoid from possible frequent changes in core ancillary applications and DB schemas required to cater frequent revisions of FHIR resource definitions.. Please correct me if I am wrong ?
Grahame Grieve (Nov 02 2017 at 20:55):
not wrong in terms of understanding my comments
Michael Austen (Nov 03 2017 at 10:36):
Grahame Thanks a lot for your valuable guidelines regarding approach for a greenfield deployment.
Last updated: Apr 12 2022 at 19:14 UTC
