Stream: implementers
Topic: FHIR Messaging - right choice today - interop HL7v2 ?
Frank Misa (Feb 22 2017 at 12:20):
Any thoughts suggestions - is FHIR the wrong choice ?
Frank Misa (Feb 22 2017 at 12:37):
Looking to provide a way for Clinical applications to integrate with our Practice Management framework. Initial application - and likely others - will speak HL7v2: ADT, SIU and DFT messages to start.
- FHIR support (examples) for "messaging" doesn't seem complete; it's more a restful implementation.
- I see efforts to bridge between HL7v2 and FHIR using Batch or Transaction.
I need to define a standard message interface on my side - either JSON or XML - and push messages to ESB layer where mapping to/from HL7 can take place.
Don't want to reinvent the wheel - was hoping FHIR would provide a set of "standard" messages for me - I could bind and process in my application layer.
[3rdParty - Clinical HL7*]<=>[ESB Mapping to FHIR xml/json]<=> [PracticeManagementFramework]
Though it seems possible to map HL7v2 to FHIR messages; FHIR to me seems more a shift towards a restful approach where the HL7 would be used to populate a "repository"/database - which could then be queried/updated using restful API.
Any thoughts suggestions - is FHIR the wrong choice ?
Richard Kavanagh (Feb 22 2017 at 12:52):
In England we use FHIR Messages and FHIR RESTful - different tools for different jobs. Not every interoperability challenge is going to be fixed by a RESTful FHIR interface. That said if that's an option then it is one to consider.
Richard Kavanagh (Feb 22 2017 at 12:55):
Just to labour the point the value of having common "profiles" in place for different exchanges is significant. We use FHIR in the RESTful, Message and Document paradigms - all sharing the same resource profiles.
Frank Misa (Feb 22 2017 at 13:02):
Thank You !
Maybe I'm wrong - but the messaging support implementations don't seem as mature as the support for REST.
I don't see reference open-source FHIR messaging server implementations or hl7ToFHIR bridges that I can leverage/extend.
I see two approaches at least to map HL7v2 to FHIR.
- Mapping to FHIR Batch or Transaction types.
- or Message type: http://hl7.org/fhir/messaging.html
Are there any examples out there ? references ?
http://hapifhir.io/
Can you suggest some urls.
Kevin Mayfield (Feb 22 2017 at 13:18):
You could using both versions of HAPI use Apache Camel to build a bridge (the hl7v2 hapi is a component), I've used this to provide a HL7v2 patient demographic feed to FHIR-HAPI demo database. I'm not finding a need to use FHIR in messaging at the moment and although I expect our EPR to move to FHIR API's, I'm not expecting the orchestration/integration engine to move over except for communication with the EPR and national systems.
Kevin Mayfield (Feb 22 2017 at 13:19):
Link to HAPI/Camel v2 http://camel.apache.org/hl7.html
Frank Misa (Feb 22 2017 at 13:53):
Thanks Kevin
That was helpful.
Curious - given today's landscape.... if you're not moving to FHIR messaging - what are you mapping your vendor/3rd-party hl7v2 to downstream.
Given all the mapping/transformation issues between vendor implementations of HL7 - I want to map to some common message/schema on my end - move the task of mapping/transformation out of my application - to another ESB/layer or the vendor themselves.
What's the standard message profile/schema you want to publish today to vendors wishing to integrate with you.
HL7v2 ? or some custom XML/JSON schema - neither seem the correct choice to me - today.
nicola (RIO/SS) (Feb 22 2017 at 15:26):
While architecting integration between 400 EHRs in one big city, we decided to use persistent FHIR transactions log - as replacement/evolution of messaging. Persistent means log is append only and available by REST API, each transaction has increasing number, so you could replicate this transactions to another server by moving pointer to last transaction and replaying this log (probably filtered by some criteria) on another server. This could be considered like extending FHIR history API. To do this we would like turn all CUD opeartions into transactions, even for one resource. This design is inspired by modern event driven integrations thro queues and databases replication analogy.
Frank Misa (Feb 22 2017 at 16:37):
This is a really interesting thought ! Thank you very much for sharing.
Are you replaying/using those transactions to populate a FHIR repository ? The transactions themselves wouldn't be available by REST API.
But I can see - how they can be used to populate a repository - that could be queried by REST api. So then - instead of processing 'messages' the various points you need to integrate can query the repository using REST/verbs - and process CRUD operations that way.
Can't get my head wrapped around how those 400 EHRs you mention are sending you the FHIR transactions in the first place ?
Are those EHRs using FHIR to begin with or are they/you mapping their HL7 to FHIR transactions ?
There's not an easy 1:1 mapping between HL7 and FHIR message and no reference/open-source bridge I can leverage for this purpose.
If I understand correctly - FHIR 'messages' responses are w.r.t. to a given resource. HL7 'messages' can reference many of these resources in a single message. The only way I see to use FHIR on my end is to use HL7 to populate a FHIR repository. We move away from messages and towards RESTAPI.
Lloyd McKenzie (Feb 22 2017 at 20:21):
There's significantly more focus on RESTful use of FHIR because it provides easier interoperability - no need to negotiate what's in the payload, what responses are allowed or what event codes will be used. And much of the initial implementation of FHIR has been in spaces where REST works well (mobile, PHRs, registries, etc.) So it's certainly true that REST is more mature. (REST is more mature than FHIR documents too.) That said, messaging still makes sense when you need routing, certain types of asynchronous behavior, etc. Also, messaging gives you more context. In REST, an admit, discharge and a bed transfer would all be handled using PUT Patient/x. That's a positive thing in terms of flexibility, but a bit of a downside in terms of detailed control. (As a rule, the less control you try to assert at the server side, the easier it is to get interoperability, but there are certainly times when control is necessary.
Frank Misa (Feb 22 2017 at 21:20):
Thank you very much Lloyd - everyone...
Getting a better understanding of how these technologies complement each-other.
Really appreciate the feedback.
Thanks !
Paul Knapp (Feb 22 2017 at 21:27):
Also, FHIR only documents the transport which isn't documented elsewhere, the FHIR REST protocol. Other protocols such as SMTP, HTTP Request-Response, MLLP, WSI Web Services etc. are document elsewhere and widely used, the only new addition is using FHIR resources as the payload of the exchange. In the Financial track of Connectathons since 2013 we have included at least one Request-Response protocol in addition for FHIR REST as the business is typically Request-Response.
nicola (RIO/SS) (Feb 23 2017 at 01:28):
@Frank Misa transaction log is our extension to FHIR - we've added $transactions Operation, which could be used to pull transactions by REST API. EHR has to dump all changes into log in FHIR transaction bundle format. For example if new patient is registered - EHR create transaction with new Patient and Encounter resource, if Patient demographic changed - transaction with Patch Operation is added to the log. The difference with messages is that EHR should not report redundant information (all this message segments) - only what was changed, created or deleted - this is much simpler to implement, than build HL7v2 message, and also easy to on recipient side to process - just apply this transaction. We are in early stage of evaluation of this approach, we will report results.
Kevin Mayfield (Feb 23 2017 at 10:07):
@Frank Misa it's a bit of mixed bag. We're mostly moving bespoke xml feeds and HL7v2 to EDMS solutions, the EDMS doesn't need the full MDM^T02 message just the metadata (FHIR DocumentReference) and the actual document (FHIR Binary). The closest we come to a message is a FHIR Bundle containing both resources. We're looking at reducing the messaging for a number of reasons (information governance, etc), ideally we'd want systems to use a FHIR resource API to lookup the data rather than receiving it via messaging.
Last updated: Apr 12 2022 at 19:14 UTC
