Stream: implementers
Topic: FHIR ADT Bundle Examples
Todd Cocks (Dec 17 2020 at 17:15):
Just starting in FHIR and have been reading up on a whole bunch of items so pardon me if I'm off on anything.
My company wants to create it's first FHIR implementation by consuming FHIR ADT messages and converting them to v2.x HL7. Our long-term plan would be to consume these natively but we feel like it would give us a good feel for FHIR (and a faster implementation) to first just build HL7 2.x messages from FHIR ADT bundles.
I've been looking and looking and nowhere can I find full examples of what a full FHIR ADT bundle would look like. Can anyone point me to some sort of resource that where I can see this? Ideally I'd like to see it for a range of messages from A01's, A02's, A03's, etc in JSON. Thank you so much for any help you can provide.
Lloyd McKenzie (Dec 17 2020 at 17:19):
Most implementers of FHIR don't do messaging at all. So far, there's been little interest in defining standardized equivalents of ADT functions. What messaging is supported tends to be defined by local implementation guides. There is however a v2->FHIR mapping project that would provide guidance if you really want to do this (#v2 to FHIR). Keep in mind that for a lot of messaging functions (updating patient demographics, changing patient location, etc.), you can do it more simply with a REST call.
Vassil Peytchev (Dec 17 2020 at 17:24):
I agree with Lloyd, and I don't think that consuming FHIR ADT messages and converting them to v2.x will give you a good feel for FHIR. An essential part of the FHIR appeal is the RESTful API, so starting there is a better be to get a "good feel for FHIR"...
Josh Lamb (Dec 17 2020 at 17:24):
With payers attempting to expose the clinical data we maintain to members/patients through the new patient access api, interest in converting v2 to fhir may grow. I have been looking at some of the open source implementations as well.
In this same vein, qrda1/ccda to fhir is also attractive.
David Pyke (Dec 17 2020 at 17:26):
Converting HL7v2 to FHIR is becoming a boom business right now as many orgs can only output V2 messages, however, there are many pitfalls in doing so.
Josh Lamb (Dec 17 2020 at 17:28):
Is there an adt to qdm intermediate (or similar) that could facilitate this? If everyone is creating their own processes to convert to FHIR we may lose interoperability.
David Pyke (Dec 17 2020 at 17:28):
Check with https://chat.fhir.org/#narrow/stream/179188-v2-to-FHIR, they an give you the best guidance
Todd Cocks (Dec 17 2020 at 17:39):
So in a clinical setting as a hospital, where v2.x messaging is used to let all ancillary systems know about a patient existing, being modified, getting discharged, etc., you are saying that ADT would continue to really just be HL7 2.x if the downstream system needs to be updated realtime? Generally systems would use FHIR to pull info such as 'show me all the lab results for a certain patient'? Or the downstream system could say 'get me the patient in bed 1SOUTH 210' which would then return the information from the source of truth? Sorry if that's an elementary question.
David Pyke (Dec 17 2020 at 17:49):
Using the Encounter resource or the Patient resource can manage most of the patient updates but neither easily converts to an ADT message. In most cases, you'll end up with a Bundle with Patient, Encounter, Organization, Condition and other resources to handle all the fields. The search by location can be handled if the source system is set up to search that way.
Lloyd McKenzie (Dec 17 2020 at 19:31):
There aren't very many hospitals that are looking to replace their existing ADT interfaces. If they did, it would likely be driven by something other than just a change in syntax.
Kevin Mayfield (Dec 18 2020 at 06:27):
I'm expecting to only see FHIR Messaging introduced (in the UK) where the v2 wasn't nationally defined or where we have V3 messages or CDA documents.
We probably should be looking at reducing the need for ADT feeds. Too many systems are getting data they won't process or require and it would be better if they looked up the data instead. Refocus ADT's as being notifications rather than a data distribution system?
René Spronk (Dec 18 2020 at 08:36):
Even in v2, ADT is essentially a 'subscription based approach', whereby the subscription is configured/hard coded on the sending system. A receiver could opt out of an ADT feed. The subscription is implicit.
Kevin Mayfield (Dec 18 2020 at 09:07):
I'd probably describe V2 as pipes (https://www.enterpriseintegrationpatterns.com/patterns/messaging/PointToPointChannel.html).
Using a 'pub-sub' (https://www.enterpriseintegrationpatterns.com/patterns/messaging/PublishSubscribeChannel.html) is optional.
David Pyke (Dec 18 2020 at 14:40):
I'm working with several orgs that are "getting FHIR" by hooking up integration engines to convert V2 messages to FHIR Bundles. With the resulting issues... Smarter companies are hooking up FHIR as a separate API and leaving V2 for those who need V2
Frank Oemig (Dec 18 2020 at 14:51):
This discussion more relates to v2-fhir-mapping...
Frank Oemig (Dec 18 2020 at 14:52):
The problem is to convert a single v2 ADT message into an appropriate set of resource crud actions
Matt Ping (Dec 18 2020 at 15:49):
It might be worth looking into the DaVinci Alerts/Notifications spec http://build.fhir.org/ig/HL7/davinci-alerts/ . That specifically outlines the ADT bundle. The team I've been on took the approach of a bundle with Encounter + more as suggested above. We're working on moving that API to the DaVinci Alerts model as it more closely aligns with ADT work.
Last updated: Apr 12 2022 at 19:14 UTC
