FHIR Chat · FHIR Message/Graph Definition for ADT^A28 · v2 to FHIR

Stream: v2 to FHIR

Topic: FHIR Message/Graph Definition for ADT^A28


view this post on Zulip Kevin Mayfield (Mar 03 2019 at 09:47):

Experimental (i.e. a gist) but a graph for A28 equivalent https://data.developer-test.nhs.uk/ccri/term/graph/3
and also https://data.developer-test.nhs.uk/ccri/term/messaging/1

Also some work on MDM^T02 https://data.developer-test.nhs.uk/ccri/term/messaging/3 and https://data.developer-test.nhs.uk/ccri/term/graph/2

I'm trying to follow the basic structure of HL7v2 equivalents.

view this post on Zulip Kevin Mayfield (Mar 03 2019 at 09:47):

p.s. I might not have got the content correct, feedback welcome.

view this post on Zulip René Spronk (Mar 04 2019 at 08:29):

Rather minimalistic A28 (none of the optional stuff as defined in the UK A.3 v2 spec). On the MDM T02, that would solely have DocumentReference as its focus (NOT messageHeader, nor Patient). Anything other than DocumentReference would be part of the overall message bundle, but it's not the focus of the trigger event. DocumentReference contains a reference to the subject (Patient), so no need to pull that within the message focus. Probably a best practice to keep the focus as limited as possible, and if the trigger event indicates a state change, only the resource(s) undergoing that state change should be in focus.

view this post on Zulip John Silva (Mar 04 2019 at 11:56):

@René Spronk Thanks for these points. I took a quick look at this and wondered why MessageHeader was there; I was hoping this mapping wasn't only for FHIR message-based workflow but also could work for RESTful, transaction based workflows. I didn't look at the details yet but the MDM T02 is only one of the 'set of V2 transactions' that have to do with document workflow; obviously there are the other variants like T01 (with reference to document, not including the document payload) and the T07/T08 oair for updates to the documents.

view this post on Zulip René Spronk (Mar 04 2019 at 12:17):

Kevin's scenario is heavily constrained for use in his English ITK setting. However, the focus of MDM messages will always be a DocumentReference. MDM messages may include a Binary resource to capture the content, or the document may already exist elsewhere. The underlying use cases (and trigger events) don't change.
In a more general sense, a REST Transaction payload may look like a FHIR messaging structure in terms of Resources, and yet, the effect is different because the paradigms are different.

view this post on Zulip Kevin Mayfield (Mar 04 2019 at 12:34):

So,
MessageHeader is not needed in the MessageDefinition (I presume I set the MessageHeader profile to use in GraphDefinition?)
I'm ignoring the optional stuff at present as I'm after a simple correct example.

view this post on Zulip Kevin Mayfield (Mar 04 2019 at 12:34):

Have updated examples above

view this post on Zulip Craig Newman (Mar 04 2019 at 13:14):

@Kevin Mayfield When I was looking at mapping MDM to FHIR, I was looking at both DiagnosticReport (something you use case may not include) and Composition. I looked at DocumentReference but didn't get a clear sense of benefits of using Composition versus DocumentReference. What was your thought process for selecting DocumentReference?

view this post on Zulip Kevin Mayfield (Mar 04 2019 at 13:40):

I was after a standard method of sending pdf/img/jpg to a document store. Assumption is some would be HL7v2, others IHE MHD but most would be a mix bag of xml and other formats.


Last updated: Apr 12 2022 at 19:14 UTC