Stream: implementers
Topic: FHIR and ADT
Ken Melms (Jul 10 2017 at 21:33):
Does anyone have a thought on how to use FHIR to get ADT events from a FHIR enabled HIE/EHR?
Lloyd McKenzie (Jul 10 2017 at 21:38):
Well, you could do FHIR messaging much as v2 works if you really need event-based processing. Alternatively, you could just subscribe and receive updates to relevant Encounter, Patient, Account, EpisodeOfCare and other ADT-related resources.
Ken Melms (Jul 10 2017 at 21:40):
Can you point me to how to subscribe? I'm wading through the docs but haven't tied that in yet.
Lloyd McKenzie (Jul 10 2017 at 21:41):
http://hl7.org/fhir/subscription.html
Ken Melms (Jul 10 2017 at 21:43):
Thanks Lloyd - I'll start here. We're in green field land in our POC, so I'm still trying to determine the best pattern for integration (thus my wild questions). If we assume that the FHIR server implementation is a DSTU2 - would you think polling for data to be the appropriate pattern, or subscriptions / messaging?
Ken Melms (Jul 10 2017 at 21:45):
Our app needs to be able to bring data from the FHIR enabled EHR back to us to be then processed further downstream. So I'm interested in the mechanics of accessing and retrieval more than storage and transformation (except where a certain Resource is involved).
Lloyd McKenzie (Jul 10 2017 at 21:49):
Pure REST will require less negotition. Messaging gives you more context - you know it was a patient move vs. discharge vs. leave of absense by looking at the event code instead of needing to compare the old data with the new. It's also more "Traditional" for ADT information. It does carry more overhead and won't be nearly as widely supported. RESTful polling in FHIR is pretty easy - you just do a query with _lastupdated=gt[timestamp of whenever you last asked]. Only issue is the load on the server from continuous queries. Subscription does exist in DSTU2, so it's still an option there. It's more complex architecturally, but reduces the communication load.
Lloyd McKenzie (Jul 10 2017 at 21:49):
I'd certainly chat with your communication partners and see what their capabilities/preferences are.
Ken Melms (Jul 10 2017 at 21:56):
Agreed - we're ahead of contracting / negotiations with our partner right now, so we're trying to determine what "would be appropriate" when we sit down with them - as well as to begin writing our bare skeleton service interactions (with resource models). My director asked me to produce "Models for all traditional ADT transactions in FHIR - with request + response examples".... today .... yesterday .....
Ken Melms (Jul 10 2017 at 21:58):
I've looked at some HL7v2 -> FHIR ADT blogs and thoughts, but I was truly hoping to find a reference server I could tease some request/response objects out of
Ken Melms (Jul 10 2017 at 22:07):
Reading the draft from the project, it is a push to us of data -s o this must be subscription or messaging - so I'll focus on Message and their related bundles.
sanjay sao (Jul 10 2017 at 22:19):
Regarding the documentation http://hl7.org/fhir/subscription.html in the context of Subscription.criteria, this document mentions about search criteria which is very specific to filter certain records and looks like we are subscribing to specific patient record. But for subscribing to FHIR Resource, it would be best to accept URI like Patient?name which indicates generic subscription for any patient name change where as Patient?name=san, indicate if patient name san changes then trigger the message, which is little bit confusing.
Ken Melms (Jul 10 2017 at 22:24):
Thanks Sanjay - I was noodling over that one just now. So let's say that I have a set of patients of which I wish to receive ADT information via subscription, my criteria would be individual, and more like this? (Per patient I care to get notified of)?
"criteria": "Patient?id=abcdef12345"
Ken Melms (Jul 10 2017 at 22:25):
Or would I need to tag each Resource which may be changed by an ADT event? (Patient, Encounter, Observation, Procedure, Condition) etc?
Ken Melms (Jul 10 2017 at 22:26):
(And that's just ADT.A01)
Ken Melms (Jul 10 2017 at 22:27):
(Reading this blog: https://fhirblog.com/2015/03/18/more-fhir-messaging-adt-messages/)
sanjay sao (Jul 10 2017 at 22:46):
what I think that both use case of 1) "criteria": "Patient?id=abcdef12345" and 2) tagging each Resource, is valid based on subscriber requirement. In our case, application wants to listen each Resource changes to reflect the patient's current status and take some critical decision at application level. Thank you Ken for the FHIR blog URL, I will go through in more detail to understand David's perspective.
Ken Melms (Jul 10 2017 at 23:29):
Got it - thanks Sanjay!
Kevin Mayfield (Jul 11 2017 at 05:58):
When we did this, we started with the HL7v2 feed coming from our PAS and converted it to FHIR. We didn't use messaging, so a ADT A28 Patient update became a PUT Patient (so we just used the PID segment). We did pass it through a subscription service.
Kevin Mayfield (Jul 11 2017 at 06:03):
Could you use a store and notify pattern? So for ADT_A01, you send a FHIR Encounter, if a system wants extra information (the other segments) they can look it up. The FHIR Encounter is a trigger, systems don't get sent information they would have discarded and it's less traffic on the network. https://developer.nhs.uk/library/architecture/integration-patterns/store-and-notify/
Ken Melms (Jul 11 2017 at 16:37):
We're thinking of using a middle-ware vendor for that kind of pattern, yes. For now, however - I'm still at a bare bones basic level trying to determine which Resources would be involved - and get a sample bundle notification that would be "like" ADT^A01 so I can then mock some data and begin testing my ingest endpoint while contracting is working with the vendor.
Ken Melms (Jul 11 2017 at 17:06):
When we did this, we started with the HL7v2 feed coming from our PAS and converted it to FHIR. We didn't use messaging, so a ADT A28 Patient update became a PUT Patient (so we just used the PID segment). We did pass it through a subscription service.
We "could" let them push HL7v2 to us, but our vendor purports to support FHIR - and we'd much rather move in that direction, so I'm still looking to cobble together a sample data payload (Bundle / Message) that would be generated by a FHIR enabled ADT^A01 (and more) transaction.
Ken Melms (Jul 11 2017 at 17:07):
I may try to add a subscription to Grahame's server and see what happens when I add a Patient Encounter
Ken Melms (Jul 11 2017 at 17:08):
Seems the most straightforward way - though I can't have it hit my endpoint inside my firewall, so ...
Ken Melms (Jul 11 2017 at 17:41):
Dang ... The 2 test servers I use don't seem to have any subscriptions (though one says it has some, they are 401 MISSING)
Ken Melms (Jul 11 2017 at 18:53):
Now I'm confused -- What are the different use cases for MessageHeader vs MessageDefinition?
Lloyd McKenzie (Jul 11 2017 at 19:47):
MessageDefinition describes a kind of message that can exist - what the event code is, what content is sent within it, what types of responses are possibles, etc. MessageHeader appears at the start of a particular message instance. It refers to the event code from a MessageDefinition. It contains a set of resources that complies with the GraphDefinition specified by the MessageHeader. It may be responded to with a message that complies with one of the MessageDefinition's allowed responses.
Lloyd McKenzie (Jul 11 2017 at 19:48):
So essentially MessageDefinition = definition. MessageHeader = header for an instance
Ken Melms (Jul 11 2017 at 21:37):
I don't see that relationship in the UML/Structure definitions, and I don't see an example where a MessageHeader and a MessageDefinition coexist in the same Bundle/space - so I'm not seeing the relationship.
Ken Melms (Jul 11 2017 at 21:39):
I did find that MessageHeader has exactly what I was hoping to find for a start:
Code Display Definition
admit Admit The patient has been admitted.
discharge Discharge The patient has been discharged.
absent Absent The patient has temporarily left the institution.
return Returned The patient has returned from a temporary absence.
moved Moved The patient has been moved to a new location.
edit Edit Encounter details have been updated (e.g. to correct a coding error).
Ken Melms (Jul 11 2017 at 21:39):
Admit/Discharge/Moved (Transferred)
Ken Melms (Jul 11 2017 at 21:40):
http://build.fhir.org/valueset-message-reason-encounter.html
Ken Melms (Jul 11 2017 at 21:48):
I'd love to figure this pattern out.
Ken Melms (Jul 11 2017 at 21:59):
Or is a "MessageDefinition" what we put on the server to describe what "MessageHeader" + "Events" can be transported? As it's a level 0 artifact, is it even needed if the server can produce MessageHeader[Events]?
Lloyd McKenzie (Jul 11 2017 at 22:42):
MessageDefinition would almost never appear in the same bundle as MessageHeader. MessageDefinition would appear in implementation guides - alongside profiles, operation definitions, value sets and other implementation guidance. MessageHeader appears at the start of instances.
Ken Melms (Jul 11 2017 at 22:43):
I think I start to see - though not clearly yet
Lloyd McKenzie (Jul 11 2017 at 22:43):
The system should ideally be able to expose MessageDefinitions along with its CapabilityStatement.
Lloyd McKenzie (Jul 11 2017 at 22:43):
But no need to share them other than that. And it's not a strict requirement - especially if the system doesn't expose a RESTful interface.
Ken Melms (Jul 11 2017 at 22:44):
Sweet. We expect it to be a push integration, where we ACCEPT FHIR bundles.
Ken Melms (Jul 11 2017 at 22:44):
SO I don't see us doing RESTful turnarounds
Ken Melms (Jul 11 2017 at 22:44):
(yet)
Lloyd McKenzie (Jul 11 2017 at 22:46):
Well, if you're receiving the content over http using the $process-message operation, then you sort of have a RESTful interface
Ken Melms (Jul 11 2017 at 22:49):
The direction we're being given right now is to build a simple TypeScript service endpoint which can parse a bundle as a place for a party to push a bundle to. I concur that it would be nice to have it be a FHIR RESTful endpoint, but the developer at the helm wants to do JSON parsing and pluck details.
Ken Melms (Jul 11 2017 at 22:49):
(Not necessarily a bundle - no direction there actually, just "receive FHIR data"
Ken Melms (Jul 11 2017 at 22:50):
This will all clarify once we get into real talks with the vendor
Lloyd McKenzie (Jul 11 2017 at 22:50):
Well, if you're going to be a valid FHIR message, it'll have to be a Bundle.
Lloyd McKenzie (Jul 11 2017 at 22:50):
How you transport it is entirely up to you though.
Ken Melms (Jul 11 2017 at 22:53):
Right. So a bundle of "FHIR Stuff that describes ADT" - which I'm trying to clarify, works for me. Inside that bundle it gets murky as to what would be inside - as a usual ADT transaction has Patient demo, Source (hospital/practice), Encounter/event detals, discharge summary, clinical data etc..
Ken Melms (Jul 11 2017 at 22:53):
So - I'm trying to line that up to FHIR resources so I can make a best guess as to what will be in the Message/Event
Lloyd McKenzie (Jul 11 2017 at 23:03):
The first message in the Bundle would be MessageHeader. MessageHeader.focus would point to the focus (or occasionally focuses) of the event. So for an admit or discharge, it would be a single Encounter focus. For merge Patient or merge Account, there would be two focuses. Everything else that was relevant and needed to be sent to allow the receiver to process the message would be navigable either to or from the focal resource. So, for example, if the focus was Encounter, you might also include the Encounter.subject Patient, the various Practitioners, the Location, the Organization, some Condition instances, etc. How much or how little goes into the messge is determined by the GraphDefinition pointed to by MessageDefinition. (Which is in turn determined by the use-case for the exchange and the needs of the communicating partners.)
Ken Melms (Jul 11 2017 at 23:23):
Lloyd - you're my hero. That cleared the cobwebs nicely!
Lloyd McKenzie (Jul 11 2017 at 23:31):
Glad to help :) If you have suggestions about how to improve the existing documentation to make it clearer, don't be afraid to submit a change request. (Including specific proposed wording changes is always appreciated :))
Ken Melms (Jul 11 2017 at 23:42):
I will - I'm gathering a ton of information today, hopefully I can get to a point where I'm useful
Kevin Mayfield (Jul 12 2017 at 08:03):
I'm not sure FHIR messaging is appropriate for system to system communication within an organisation. For two reasons, it's just copying HL7v2 and so we have solutions and RESTfulAPI (ResourceAPI) would be a more appropriate be a better solution. If you need to update Patient demographics, why send details of the clinician, similarly if a Patient has attended a clinic - why do I need to send out their address???
John Moehrke (Jul 12 2017 at 12:26):
There is a stream dedicated to "v2 to FHIR"
Kevin Mayfield (Jul 12 2017 at 12:30):
This is more messagingAPI vrs resourceAPI
Lloyd McKenzie (Jul 12 2017 at 14:15):
Messaging can be asynchronous, allows indirect routing, supports finer-grained event declaration (and thus gives the recipient more information about what's going on), allows interoperability with a smaller number of transmissions (though those will be larger transmissions) and - perhaps most importantly - does not require independent, maintained identity of all resources.
Lloyd McKenzie (Jul 12 2017 at 14:17):
If you're talking to a system with a v2 or other messaging back-end, it may be very difficult for that system to expose its information RESTfully because it doesn't have identifiers on all of its data elements and may not be set up in a way that allows RESTful query. However, sharing its information in FHIR syntax may allow the data to more easily be used with FHIR down-stream, lets you take advantage of modern syntaxes & tools, lets you use FHIR's conformance capabilities, etc.
Lloyd McKenzie (Jul 12 2017 at 14:18):
In general, I agree that with FHIR there's a preference/bias towards using REST rather than messaging because messaging requires more up-front negotiation with communication partners to enable interoperability to occur. But there are definitely reasons systems will need to use a messaging approach.
Ken Melms (Jul 12 2017 at 16:08):
In our case, it's a push from a vendor who is packaging it as FHIR - not a full FHIR server implementation, so we don't have a RESTFul option here.
Lloyd McKenzie (Jul 12 2017 at 16:37):
Implementation partner or lead architect fiat is definitely something that will influence what communication paradigm gets used too :)
Jayashree Surnar (Jul 17 2017 at 11:29):
hello @Lloyd McKenzie , if i want to send a bundle with MessageHeader and other related resource to hapi-fhir server using Advance Rest Client / PostMan. what is the url? i'm confusing alot . could you please help.
Thank you.
Lloyd McKenzie (Jul 17 2017 at 15:10):
If you're sending a Bundle, you'll have to post to /Bundle. So http://fhirtest.uhn.ca/baseDstu3/Bundle. I don't think hapi supports the http://fhirtest.uhn.ca/baseDstu3/$process-message operation.
Jayashree Surnar (Jul 18 2017 at 04:43):
thank you @Lloyd McKenzie , actually i want to test whether hapi fhir server is able to handle fhir Messaging or not. for that i have gone through the messaging doc given in fhir (http://build.fhir.org/messaging.html), but I was not clear how to test using ARC/Postman.
Lloyd McKenzie (Jul 18 2017 at 05:11):
Well, you can try posting something to $process-message, but my guess is it won't work. Messaging requires mutual agreement between the systems about what's allowed to be in an inbound message, what the server should do in response and what should be in the response message. The test servers don't have any such agreements in place, so they can't really generate appropriate responses. The best they could potentially do is allow you to post stuff to $process-message and throw it away, but that's not terribly helpful.
Jayashree Surnar (Jul 18 2017 at 05:14):
@Lloyd McKenzie thank you somuch
Kevin Mayfield (Jul 18 2017 at 06:00):
I've been using middleware (e.g. Apache Camel) to breakdown the message into individual RESTful calls to HAPI.
Last updated: Apr 12 2022 at 19:14 UTC
