FHIR Chat · Use of endpoints · fhir-messages

Stream: fhir-messages

Topic: Use of endpoints

Eirik Myklebost (Sep 09 2021 at 13:38):

Hi,

We are currently having a discussion in the norway stream regarding messaging and how to correctly interpret and use the required elements: source.endpoint and destination.endpoint. The use of the word endpoint with the datatype url suggests that this should be a resolvable protocol specific endpoint where the message can be delivered, e.g. http, ftp or email endpoint.

However, the Notes says the following:

If _MessageHeader.source.endpoint_ and _MessageHeader.destination.endpoint_, are literal URLs, then they SHOULD identify the addresses to which messages can be delivered. If they are logical URIs (i.e. non-dereferenceable), message delivery intermediaries must know how to deliver the message to the destination application.

And from the Basic Messaging Assumptions:

The exact mechanism of transfer is irrelevant to this specification, but may include file transfer, HTTP based transfer, MLLP (HL7 minimal lower layer protocol), MQ series messaging or anything else. The only requirement for the transfer layer is that requests are sent to a known location and responses are returned to the source of the request. This specification considers the source and destination applications as logical entities, and the mapping from logical source and destination to implementation specific addresses is outside the scope of this specification

Is it correct to interpret that an endpoint can either be a protocol-specific URL or a business identifier (URI) to identify the logical entity, e.g. a practitioner, organization or office? In this case, why is not the uri datatype used, is it related to this paragraph from Canonical URLs?

Some resource types have a defined element url which is the 'canonical URL' that always identifies the resource. This is a special kind of Business Identifier. Note that the element actually contains a URI, but is named url for legacy reasons.

In Norway we use a business identifier called HER-id to identify the communicating entities within the health sector, e.g. a practitioner-role or a department within an organization. When using the Identifier datatype this would look like this:

"identifier":{
  "system":"urn:oid:2.16.578.1.12.4.1.2",
  "value":"102287"
}

In some cases this is the only known address of the destination and the message could pass through multiple transfer-protocols (http, kafka, mq, mail) before arriving at the destination. Since destination.endpoint is of type url and not Identifier, would the following be the preferred representation?:

"destination": [
  {
    "endpoint": "urn:oid:2.16.578.1.12.4.1.2.102287"
  }
]

The alternative would be to add the identifier in the destination.receiver as a logical-reference, but that leaves us with empty endpoint elements. This situation is similar to this Jira issue.

What about the Endpoint resource, what is its intended use in the messaging context? The only mentioning is the following, which I do not understand:

Messaging: (currently defined in the Message Header, but only as the address)

Eirik Myklebost (Sep 14 2021 at 07:57):

@John Moehrke , @Lloyd McKenzie, do you have any insight to share on this topic?

John Moehrke (Sep 14 2021 at 12:55):

I don't have deep insight into how the model got to where it is, but I suspect it is modeled off of early concepts in FHIR and thus might not benefit from current modeling methodology.

John Moehrke (Sep 14 2021 at 12:57):

That said, i would expect in a messaging pattern that the sender and destination should be URI or Identifiers. Having them be references would seem odd. So one recommendation may be to allow them to be identifiers or URI, with another to use current URI modeling.

John Moehrke (Sep 14 2021 at 12:58):

I don't see the relationship of what you describe to the Jira ticket you mention. (I don't understand how the jira ticket expects to work as to me a destination seems always to be necessary in messaging. But I leave that to the workgroup).

John Moehrke (Sep 14 2021 at 12:59):

Overall, I your interpretation is workable. I would recommend you create jira tickets that describe where you feel the specification is lacking and where your design chose to go.

Eirik Myklebost (Sep 14 2021 at 13:13):

John Moehrke said:

I don't see the relationship of what you describe to the Jira ticket you mention. (I don't understand how the jira ticket expects to work as to me a destination seems always to be necessary in messaging. But I leave that to the workgroup).

I interpret the Jira issue as being the same as our scenario:
What he refers to as destination URL is what I refer to as protocol specific endpoint. Because he lacks an endpoint he uses the destination.receiver of type Reference(Organization) as a logical-reference to the destination, but that still leaves him with an empty destination.endpoint.

Maybe @Cooper Thompson can clarify this himself?

Cooper Thompson (Sep 14 2021 at 13:22):

I agree with John that I'd normally expect the sender and destinations to be URIs or identifiers rather than references.

Cooper Thompson (Sep 14 2021 at 13:22):

For messaging, there always may be a destination, but the entity that is generating the MessageHeader may not know it. Or rather, there are two types of destinations: 1) the ultimate recipient(s) 2) the first hop (e.g. to a routing intermediary). I don't think we will normally want the MessageHeader.destination to point to the routing intermediaries unless that routing intermediary is a first-class entity in the exchange (like an HIE. For the purpose of this discussion, I consider the first-class intermediaries as just a recipient. The routing intermediaries I'm thinking about here are org-internal helper systems like CorePoint, Cloverleaf, etc. Those routing intermediaries may be the party that knows the ultimate destination(s).

Cooper Thompson (Sep 14 2021 at 13:24):

We (Epic) have had a TON of internal discussion about FHIR messaging, and one of the key points is that the entity that generates and sends a message may not know who the ultimate recipient(s) will be. And this is desired, as it creates a decoupled architecture.

John Moehrke (Sep 14 2021 at 13:26):

that feels more like an internal systems-design challenge where you could simply ignore the 1..1... That is to say that there is communication between internal systems to some goal, but by the time the "message" is complete it has a destination.

John Moehrke (Sep 14 2021 at 13:27):

as to intermediaries... agree, tendency should be to just target the endpoint.. if one needs to target an intermediary, then wrap it again in another messageHeader. (turtles all the way down)

Cooper Thompson (Sep 14 2021 at 13:28):

I expect Epic and Corepoint (for example) would want to talk "real" FHIR to each other, since we are different systems within an organization footprint. I think the base spec should be 0..1. An IG could make that 1..1 if that IG was intended to be used only for non-internal use.

Cooper Thompson (Sep 14 2021 at 13:29):

Unless you're telling me that we can fudge all the FHIR spec requirements as long as we are just talking org-internal :p.

John Moehrke (Sep 14 2021 at 13:31):

im not against it. just giving my initial reaction. I am sure there is some communication of the destination end point, so why is that acceptable in your model to not be part of the interop standard?

Eirik Myklebost (Sep 14 2021 at 13:32):

What about using the destination.endpoint as a logical id (URI) as mentioned in this topic?

John Moehrke (Sep 14 2021 at 13:32):

im not sure how the idea of multi-casting was intended... Send this patient demographics update to all members...

John Moehrke (Sep 14 2021 at 13:33):

it might eventually be unicast, but I can see how an intermediary that only role is to change multi-cast to unicast(s)

John Moehrke (Sep 14 2021 at 13:35):

my overall impression is that messaging has not received much attention, and been denigrated by many core. So I would expect you should see this as an opportunity to improve the spec, rather than that the spec has some reason to be so poorly defined.

Cooper Thompson (Sep 14 2021 at 13:35):

I expect most FHIR messages might be going to multiple recipients. The benefit of a message is that it is a unit of (event,data) that a bunch of folks probably care about. E.g. a message for a lab order or result probably goes to the lab, but also the infection control system, the data warehouse, maybe a bed monitor so patients can track the status of their labs, etc.

Cooper Thompson (Sep 14 2021 at 13:35):

There is usually one primary recipient (lab) but a ton of secondaries (infection control). But if your job is infection control, you don't really consider yourself as a secondary.

John Moehrke (Sep 14 2021 at 13:39):

one vision is that each of those groups of target end points is given a URI. the intermediary is the one registered for receipt of that URI, and knows that the role is to change multi-cast (URI) into unicast multiple sends of the copies. Not clear that in this case the origial URI must be changed, but it could be.

John Moehrke (Sep 14 2021 at 13:40):

the URI space is infinite.. so plenty of URI to support this.

Cooper Thompson (Sep 14 2021 at 14:38):

The wrinkle is that some national messaging frameworks (I'm thinking Denmark MedCom and the Norway e-prescribing stuff I think), require (or are considering requiring) the EHR to specify the ultimate destination, not the intermediary.

I.e. I think we (as an industry) are trying to implement two different messaging models using the same FHIR Messaging framework.

Kevin Mayfield (Sep 14 2021 at 17:32):

In the English Prescribing system. destination.endpoint isn't needed. It's always the prescription manager endpoint.
From the Prescription Manager we swap over to FHIR Workflow and rest.

Cooper Thompson (Sep 14 2021 at 18:06):

In the US e-prescribing, the (direct) destination is normally a network (like Surescripts), however we also send along the specific pharamcy (e.g. Walgreens on 1st Street in Verona WI) we want Surescripts to send the prescription to.

Lloyd McKenzie (Sep 14 2021 at 22:08):

The intention is that you specify either the URL or some other URI that uniquely identifies the recipient. We had no use-case for Identifier so didn't specify that as an option. Also, URI seemed more consistent with "the FHIR way". If you'd really like an identifier, that could submit a change request for it.

Not sure about making either optional. A message needs to have a sender and a receiver and every messaging system I've ever encountered has had a computable means of identifying both. (Really hard to route things without it.) What's the use-case for making them optional?

Eirik Myklebost (Sep 14 2021 at 22:49):

If I were to create an issue for change for source.endpoint and destination.endpoint, what do you think about the following alternatives?:

1. Change the datatype from URL to URI (why is it not URI in the first place?)
2. Change the datatype from URL to a choice between URI and Identifier.

In both of these alternatives the endpoints will remain required (card. 1...1), I also believe this is a reasonable requirement in a message. The exception would be when messaging is used in an Event Oriented Architecture where events are broadcasted without knowing who is interested, but this scenario is already achievable by having 0 destinations.

Lloyd McKenzie (Sep 15 2021 at 04:28):

URL to URI I'd support. URL to choice with identifier, I'd need to understand why Identifier was necessary and URI couldn't work. (Changing to URI would be non-breaking, while changing to a choice would be breaking.)

Thomas Tveit Rosenlund (Sep 15 2021 at 05:41):

Cooper Thompson said:

The wrinkle is that some national messaging frameworks (I'm thinking Denmark MedCom and the Norway e-prescribing stuff I think), require (or are considering requiring) the EHR to specify the ultimate destination, not the intermediary.

I.e. I think we (as an industry) are trying to implement two different messaging models using the same FHIR Messaging framework.

In Norway we usually have three layers of messagingHeaders for our mainstream messaging infrastructure.

1. On the business level we have a message header that identifies the sender and recevier as business entities e.g. using HER identifiers and other business identifiers. The actual endpoint address is usually not know by the systems generating the actual business messages.
2. Most messages use a SOAP MEssageHeader (ebMS 2.0) for non-rep and encryption of the payload, eb:From and eb:To still contain no acutal endpoint adresses.
3. On the transport layer (usually SMTP but other protocols are implemented as well) an actual endpoint adress is provided.

This means that in Norway a better mapping would be for the destination and source elements to be mandatory, but endpoints should be optional as only the transport level MessageHeaders would contain an actual endpoint address.

Kevin Mayfield (Sep 15 2021 at 06:34):

@Lloyd McKenzie Re: Also, URI seemed more consistent with "the FHIR way".

Sounds similar to Reference. You can use a uri/reference or an identifier. We've chosen identifier for our national system

Kevin Mayfield (Sep 15 2021 at 06:45):

https://jira.hl7.org/browse/FHIR-33690

Eirik Myklebost (Sep 20 2021 at 10:28):

Kevin Mayfield said:

https://jira.hl7.org/browse/FHIR-33690

This example uses References instead of URI/Identifier to identify the recipient, why cannot the endpoints contain the business-id of the sender/recipient as URIs? Is your interpretation that the endpoints MUST contain a protocol-specific URL?

Kevin Mayfield (Sep 23 2021 at 07:09):

I don’t think we have a use at the moment for reference or uri.

Last updated: Apr 12 2022 at 19:14 UTC