FHIR Chat · Parameters as MessageHeader focus: okay to use now?

Stream: implementers

Topic: Parameters as MessageHeader focus: okay to use now?

Frank McKinney (Jul 08 2020 at 13:39):

Quick background: @Josh Mandel started a thread in Februrary that led to an approved Jira FHIR-26368 relaxing a limit on the use of Parameters so that it could be used as the focus of a message. @Vassil Peytchev submitted a Jira (FHIR-26390) to further clarify the resulting allowed use. @Lloyd McKenzie I see that you're working on the requested clarification in FHIR-I

Question: I'm working on an IG where we have a similar need to what Josh described... to clarify the different purposes of two Patient resources in a message bundle... and would like to pursue using Parameters as the message focus to do that. Is it safe to do that now?
Thanks!

Vassil Peytchev (Jul 08 2020 at 13:47):

We are in the process of gathering use cases for where the use of Parameters beyond operations would make sense, so sharing the details of what you are trying to achieve will be helpful. In general, however, the MessageHeader resource can potentially be persisted at a RESTful endpoint, in which case the Reference in MessageHeader.focus will be non-resolvable, as the Parameters resource cannot be persisted.

Frank McKinney (Jul 14 2020 at 18:03):

Hi @Vassil Peytchev Our use case is focused on the US, and would enable a pharmacy to request additonal patient information related to a prescription they've received. The pharmacy won't typically be affiliated with the prescriber or clinic, and the pharmacy system typically goes through an intermediary/network to interact with prescribers/clinics (e.g., to receive electronic prescriptions or request refills using the NCPDP SCRIPT standard). We're looking at FHIR messaging because the stakeholders depend on intermediaries for locating the correct clinic and pharmacy systems and routing data.

The basic scenario is...

Initiating event: The pharmacy receives a prescription in a non-FHIR format (US regs require use of the NCPCP standard) and determines that it needs additional patient information to fulfill it (clinical and/or insurance info)
Request: The pharmacy system bundles up a request message that includes the Patient from the pharmacy system (the pharmacy typically won't have a reference to the clinic's Patient resource), a MedicationRequest reflecting the prescription they received (to help the responder locate the patient and context) and search strings identifying the information needed
Response: The responding clinic system performs a patient match and if successful, performs the searches using the matched patient and returns a message containing the search results, along with the matched Patient from the responder system and also the submitted pharmacy Patient for reference

We're thinking that a Parameters resource in the request message could hold the search strings and references to bundled Patient and MedicationRequest resources as parameters. In the response, separate parameters would clarify which Patient is the responder's match and which is the requester's patient.

I'm very interested in your thoughts. Thx

Lloyd McKenzie (Jul 14 2020 at 18:27):

In R4 implementations, it's possible that zealous validators could treat Parameters in a Bundle as being invalid, but I suspect in general you'd be safe. In terms of future guidance, I'm pretty confident we're going to land on saying that Parameters is fine in a message, but in the end that decision isn't "final" until we pass ballot - and that could be a year or more away.

In general, I discourage the use of FHIR messaging. However, your use-case is a space where I think it's reasonable and appropriate.

Vassil Peytchev (Jul 14 2020 at 19:18):

Is the response expected to be synchronous? If it is, I think that what you are describing sounds very much like an operation. The presence of an intermediary could be an issue to front an operation, but it doesn't necessarily mean you have to resort to FHIR Messaging.

As for the use of the Parameters resource as the MessageHeader.focus, as Lloyd says it is not currently in the "letter of the law". To me the big question mark is whether and how the MessageHeader resource is going to be persisted, and how are references from MessageHeader.focus going to be handled. I don't think this is a well-implemented area, and my understanding is limited.

Finally, have you considered a RESTful approach to handle your use case? The intermediaries will need to be very much involved in it, but it could be a better match to existing EHR capabilities.

Lloyd McKenzie (Jul 14 2020 at 20:12):

Operation doesn't allow for routing

Vassil Peytchev (Jul 14 2020 at 20:16):

One or more of the parameters can have sufficient information to route it.

Frank McKinney (Jul 14 2020 at 20:17):

We'll need to support asynchronous responses as well.

Related to this seeming like an operation... I noticed that the FHIR Messaging page has a section toward the bottom about how to invoke operations via messages. As I understand it, you do this by referencing an OperationDefinition in the MessageHeader's event element and including a Parameters resource as the focus (with the parameters matching what's defined in the OperationDefinition).
It looks like the example on that page uses a pre-v3 FHIR version... I wonder if this is something that folks are doing nowadays.

Grahame Grieve (Jul 14 2020 at 20:34):

As for the use of the Parameters resource as the MessageHeader.focus, as Lloyd says it is not currently in the "letter of the law"

I don't agree with this. I think it's implicit in the definition. This is a question of clarity

René Spronk (Jul 15 2020 at 07:52):

This has always been in scope for messaging IMHO, as this is the way to send a query in a message, or as a means to invoke an operation.

Vassil Peytchev (Jul 16 2020 at 16:42):

"The Way" to send queries via messages? Can't queries be expressed as the input/output of the Task resource which is referenced in the MessageHeader.focus?

As for invoking operations over FHIR messages, given that the above mentioned STU2 content has survived this long well into R5, is an indication that no one has tried to do this. If I am wrong on that, I would like to hear about it...