Stream: ihe
Topic: Endpoint connection type
John Moehrke (Jan 29 2021 at 13:20):
There is a CR open asking for FHIR to consider EndPoint connection types more fine grain than currently specified. Currently IHE profiles like XDS, XCA, and XDR are mentioned. But the CR proposes that there might be a different EndPoint for each transaction within these profiles. I am not convinced that this theory is reality. Thus I am not persuaded. What do the likes of @Joe Lamy @Keith Boone @Vassil Peytchev or other IHE implementers and deployers think?
https://jira.hl7.org/browse/FHIR-12342
John Moehrke (Jan 29 2021 at 13:29):
realistically with synchronous there is only one endpoint type of interest in most cases.. like XCA the responding-gateway is the only service. However with async there would be a useful need to have endpoint records for both ends of the communication for the purposes of recording the certificates used. Is this the need?
Spencer LaGesse (Jan 29 2021 at 15:58):
We have a limitation in our web services stack that prevents us from accepting Text and MTOM encoded messages at the same endpoint. So this forces us to have different endpoints for, say, ITI-38 and ITI-39, despite the fact that both transactions are to the XCA responding gateway actor.
We also need to distinguish between Sync and Async, again because of limitations in our web services stack.
And for ITI-41, we have a single endpoint regardless of whether we're in an XDR or XDS.b integration.
So, for us, IHE transaction + Sync vs Async (WS-Addressing) would be a good fit. I think the Gazelle suite for IHE Connectathon offers distinction based on Actor+Transaction+Sync vs Async, and it works well for us.
Elliot Silver (Jan 29 2021 at 16:47):
I think I raised the issue originally because knowing something is an "XDS" endpoint isn't sufficient. At the most basic level, is it a Registry or a Repository? On the other hand, is it necessary to distinguish between XDS and XCA endpoints? (I think probably, but not always.)
Elliot Silver (Jan 29 2021 at 16:49):
How do you encode endpoints for XDS-I/XCA-I? Obviously, the Imaging Document Source is a separate endpoint (or endpoints, if you separate XCA), but do you need XDS and XDS-I Repositories?
John Moehrke (Jan 29 2021 at 17:20):
ah, I agree Actor is important. I saw only mention of transaction..
John Moehrke (Jan 29 2021 at 17:21):
might the classic IHE triplet be the right level: Profile/Actor/Option?
John Moehrke (Jan 29 2021 at 17:32):
I think it might need to be Profile/Actor/Transaction/Option -- that explodes the list of terms greatly
- XDS-Registry-Feed
- XDS-Registry-Feed-v3
- XDS-Registry-Feed-v3-async
- XDS-Registry-Feed-v3-as4
- XDS-Registry-Register
- XDS-Registry-Register-async
- XDS-Registry-Register-as4
- XDS-Registry-Query
- XDS-Registry-Query-async
- XDS-Registry-Query-as4
- XDS-Registry-RegOnDemand
- XDS-Registry-RegOnDemand-async
- XDS-Registry-RegOnDemand-as4
and that is just for Registry
which feels like a task that should be done by IHE, not something that should be done in FHIR core... possibly in mCSD, or in grouping behavior between XDS and mCSD? Which points out that mCSD did not include Endpoint resource type.
Elliot Silver (Jan 29 2021 at 17:32):
You and I discussed that when the issue was first filed.
Elliot Silver (Jan 29 2021 at 17:32):
Yes.
Elliot Silver (Jan 29 2021 at 17:34):
I think the discussion was whether what you just listed is overkill. When do we need to list the profile/actor, vs just the transaction?
John Moehrke (Jan 29 2021 at 17:36):
it would be a shame to have no evidence of IHE in the valueset... but it would also be unfortunate if IHE needs 500 codes.
Elliot Silver (Jan 29 2021 at 17:37):
Agree.
John Moehrke (Jan 29 2021 at 17:48):
which ones do you think can be eliminated? I think they are all possibly distinct. Especially given @Spencer LaGesse comments
John Moehrke (Jan 29 2021 at 17:56):
It is possible for some simple profiles (two actors in synchronous interaction) that only Profile is needed. (e.g. PDQ). But clearly XDS is an example of the extreme, especially because there are two forms of async.
Elliot Silver (Jan 29 2021 at 18:08):
So, sync/async is obviously needed. But I had been thinking of all 50 RAD profiles where an Image Manager/Image Archive needs to receive a C-STORE, or does it matter if ITI-8 (patient info feed) goes to a PIX manager or a Doc Registry (that example is probably going the wrong direction)?
Elliot Silver (Jan 29 2021 at 18:09):
Is knowing the transaction and options sufficient?
Elliot Silver (Jan 29 2021 at 18:11):
It probably is from a connectivity point of view....But you may need to know Actor to decide if you want to connect to an endpoint, even if you know (based on transaction) that you can.
Spencer LaGesse (Jan 29 2021 at 18:44):
I'm not sure all options need to be distinguished; I think only the ones that affect the web service stack would need to be distinguished (Sync vs Async). For example, I'm not aware of any situations where one would have separate endpoints for OnDemand vs non-OnDemand. If the system supports OnDemand, it would simply publish an endpoint that handles that option as well as the base case.
Regarding Actors, I'm not sure that is needed. I typically think of a directory as a list of systems I can talk to where each system as a list of endpoints I can hit to do various things. I would expect that either there would be a separate system for each actor, or I should be able to send the transaction to a singular endpoint for all actors it supports and it will figure it out internally.
That being said, having the Actor listed wouldn't hurt, other than potentially unnecessarily expanding the value set.
Carl Leitner (Jan 29 2021 at 22:07):
John Moehrke said:
it would be a shame to have no evidence of IHE in the valueset... but it would also be unfortunate if IHE needs 500 codes.
Unfortunate, but useful
John Moehrke (Feb 01 2021 at 15:15):
@Spencer LaGesse correct. I only mentioned an option when it would have affected interop. There are other options that I did not mention.
John Moehrke (Feb 01 2021 at 15:15):
@Elliot Silver DICOM would need both ends.
John Moehrke (Feb 01 2021 at 15:16):
I think Profile/Actor/Option is more useful than Transaction-ID. Because some transactions have different behaviors per actual named Actor (and option).
Carl Leitner (Feb 01 2021 at 15:17):
agreed on the triple (profile,actor,option)
John Moehrke (Feb 01 2021 at 15:44):
@Joe Lamy what did care quality do?
Elliot Silver (May 11 2021 at 02:05):
@John Moehrke , @Joe Lamy - Is this a topic that could get closed out this week during the IHE S2S (screen-to-screen) meeting?
John Moehrke (May 11 2021 at 12:06):
@Elliot Silver you may join us and drive the point. I think this would be something that should be covered somewhere in IHE. It is not clear to me if this is mCSD, or elsewhere. Today mCSD does not have any Endpoint specification. So this would seem to be a big change, although I think it was in the scope of one of the work item proposals that drove mCSD.
Elliot Silver (May 11 2021 at 16:28):
I wasn't thinking about anything as grand as updating a profile, just closing out the jira ticket. When would be good for me to join?
John Moehrke (May 12 2021 at 18:03):
which jira ticket?
John Moehrke (May 12 2021 at 18:05):
oh... well we did talk about this a bit this morning
John Moehrke (May 12 2021 at 18:06):
I think @Joe Lamy will be writing the use-case up for mCSD
John Moehrke (May 12 2021 at 18:06):
It is not clear the level of detail that will be needed
Elliot Silver (May 12 2021 at 18:16):
FHIR#12342. I'd be really happy not to get a nag email about it every week.
Elliot Silver (May 12 2021 at 18:17):
I don't need an extension for mCSD, I just need a vocabulary we can give to Patient Admin.
John Moehrke (May 12 2021 at 19:10):
I think XDS and XCA are already there. right?
John Moehrke (May 12 2021 at 19:10):
so, this seeems like it should be closed as redundant
John Moehrke (May 12 2021 at 19:11):
we were discussing today if there was a need to add ihe-mhd.. but that was agreed was unnecessary as there is already a fhir type, and one would discover MHD by looking at the capability statement
Elliot Silver (May 12 2021 at 19:11):
They are there, but is the vocab right? One value for all XDS endpoints (including both initiator and receiver)
Spencer LaGesse (May 12 2021 at 21:31):
I don't think it is quite right. A distinction is needed between synchronous/asynchronous. Differentiation between actors is usually not needed, since in XCPD, XDS, and XCA, for each transaction there is only one actor that needs a URL published, so the actor is assumed. (An XCA Initiating Gateway, for example, could publish a URL for it's asynchronous response endpoint, but at least in WS-Addressing async this is not needed because it is also supplied in the request message. At the same time, one can imagine somebody wanting those to be published in a directory, in which case differentiation between initiating vs responding would be needed).
I suggest values represent an actor+transaction+synchronicity combination, unless there's a better way to represent synchronicity in Endpoint that I'm not seeing.
John Moehrke (May 12 2021 at 21:34):
@Spencer LaGesse do you have a solution in your pocket you can provide? I don't know of an alternative proposal, so your proposal would likely win.
John Moehrke (May 12 2021 at 21:37):
could these alternatives be represented in the .payloadType? Meaning the .connectionType is just XDS or XCA... but the .payloadType represents the options
John Moehrke (May 12 2021 at 21:37):
or do we just need a small set of flavors of XDS and flavors of XCA (flavors of XDR?)
Spencer LaGesse (May 12 2021 at 21:42):
Actually specifying those things as payloadType might make more sense. Then you can have a single endpoint for XDS/XCA/etc. and specify which payload types that endpoint supports. So if the payloadType valueset was updated to be more in line with the SOAP actions we have in our profiles, I think that could work.
John Moehrke (May 12 2021 at 22:29):
I think that valueSet could be something we manage in IHE as an IHE vocabulary. Not clear where, but the idea we had today was that mCSD would be a logical choice.
Elliot Silver (May 12 2021 at 22:54):
Right, it probably should be an IHE managed vocabulary, but given how long it's taken to move format codes over, I'd prefer to see a short term solution that closes this issue, then IHE can tackle a longer term project to take over the vocab.
Elliot Silver (May 12 2021 at 23:00):
Spencer, are you suggesting endpoint per transaction and synchronicity moves into payload, or...? Setting aside synchronicity (and questions about initiator/responder) for a moment, what is the argument that profile and actor are not needed?
Spencer LaGesse (May 12 2021 at 23:25):
I'm suggesting we leave profile as it is, in connectionType, and specify a list of accepted SOAP actions in payloadType. Multiple endpoints with the same connectionType but (potentially) different payloadTypes would need to be expected to accomodate systems that have different endpoints for different message types. Usually the SOAP actions + the profile will imply the actor, and in cases where that isn't necessarily the case (XDS.b Document Repository/On-Demand Document Source) the client is unlikely to care about what the actor is.
John Moehrke (May 12 2021 at 23:34):
@Elliot Silver do you mean a formal solution? Or a write up of the plan? Because the writeup of the plan can be done quickly on either the hl7 confluence, or the ihe wiki.. and be done by the end of today
John Moehrke (May 12 2021 at 23:35):
I would like MnM to see the plan and agree it is an approach intended
Elliot Silver (May 12 2021 at 23:36):
The Jira ticket is waiting for input. If you or Spencer wants to provide that input to the ticket, that would be great.
John Moehrke (May 12 2021 at 23:37):
I nominate Spencer
John Moehrke (May 12 2021 at 23:40):
I think the plan we have, could be reviewed for intent... and that approval of plan intent would be sufficient to reject the jira ticket.
John Moehrke (May 12 2021 at 23:40):
they might choose to reject with mod... choosing to update Endpoint to explain this pattern.
Spencer LaGesse (May 13 2021 at 02:27):
I've left a comment on the Jira ticket. Is that all that is needed for now? I don't work with the HL7 Jira often.
Elliot Silver (May 13 2021 at 14:58):
I think that's good. I'm going to leave a comment suggesting that this be closed, that IHE will be developing their own value sets for various elements, and that at some point IHE may ask for an update to the HL7 value set, but that will be via a separate ticket.
Joe Lamy (May 27 2021 at 15:59):
I added this on the ticket:
In eHx, we make use of Endpoint for XCA (and XCPD) as follows:
We use payloadType to convey document content types (with the defined FHIR valueset), adding an "All" value.
We use connectionType at the level "IHE-XCA"
We use extensions to independently specify Transaction, Actor, Version (of eHx profile over the transaction), Purposes of Use allowed, Roles allowed, IP address. We don't address synchronicity because we currently don't support WS-Addressing async.
So unfortunately I can't support taking payloadType at this time for that purpose. I do like eliminating codes that would be unnecessary, and perhaps we could further cut them down by utilizing an IHE-defined extension for an independent aspect like synchronicity.
Joe Lamy (May 27 2021 at 16:30):
By the way, I don't think there is a big need for the eHx-specific aspects to find their way into this solution. I do think options supported besides synchronicity are useful to make known, but also not critical to be solved here.
Spencer LaGesse (May 27 2021 at 17:06):
It seems like Carequality might also use payloadType for document content, so I agree that payloadType might not be appropriate here. For reference, this is the Carequality R4 IG: https://carequality.org/healthcare-directory/index.html
Joe Lamy (Mar 09 2022 at 21:17):
There has been a bit of work on this both in HL7 and IHE, so I wanted to update this thread. The IHE work is in the 3.6.1 version of the mCSD profile, which is out for Public Comment here.
- FHIR-12342 will allow connectionType to hold more than one value.
- IHE has defined a code system for connection types to IHE-profiled SOAP endpoints, e.g. "XCA-RespGateway-Query". These codes provide the descriptiveness lacking in HL7-defined codes like "ihe-xca".
- In Endpoint.connectionType, because the binding to the HL7 value set is extensible, we cannot simply add codes to connectionType, for example, connectionType = {ihe-xca, XCA-RespGateway-Query} - every code used must be chosen from the HL7 value set if it applies. So instead IHE has defined an extension to hold these codes. The extension is defined here and the profiled Endpoint StructureDefinition that uses it is here.
Please review and offer feedback. Thanks!
Elliot Silver (Mar 09 2022 at 22:08):
Isn't extensible met by, within each repetition of connectionType, having a coding from the HL7 value set, with additional values from the IHE value set permitted? Thus, following your notation, connectionType[0].coding = {ihe-xca, XCA-RespGateway-Query}.
John Moehrke (Mar 09 2022 at 22:14):
the given codeSystem should be seen as nothing but example.
Elliot Silver (Mar 09 2022 at 22:16):
Maybe, but Joe says, "In Endpoint.connectionType, because the binding to the HL7 value set is extensible, we cannot simply add codes to connectionType" which I'm challenging in one direction, and you are challenging in another.
John Moehrke (Mar 09 2022 at 22:17):
I don't know that it makes good sense for FHIR to have IHE document sharing codes. We can do that in mCSD
John Moehrke (Mar 09 2022 at 22:18):
so, i just want R5 to not be extensible bound to something that has codes that are not real codes. the current codeSystem is really nothing but some example codes.
John Moehrke (Mar 09 2022 at 22:19):
if they want to pull in some of the IHE defined codes into their example valueSet... I can see doing that, but it would be odd for FHIR core to do that
Elliot Silver (Mar 09 2022 at 22:19):
OK, so again, that's two reasons why there's no need for the proposed extension.
John Moehrke (Mar 09 2022 at 22:30):
we need the extension for R4
John Moehrke (Mar 09 2022 at 22:32):
I tried to go down the logic you are trying. I lost. Hence the extension today
John Moehrke (Mar 09 2022 at 22:32):
the mCSD code is more specific, not equivalent
Elliot Silver (Mar 09 2022 at 23:59):
Ah, so is the extension in R5 too?
John Moehrke (Mar 10 2022 at 00:29):
no, in R5 we won't need it
Elliot Silver (Mar 10 2022 at 15:50):
In R5 you move to an example valueset and ..*, in R4 you accomplish that with an extension? Got it.
John Moehrke (Mar 10 2022 at 15:53):
feel free to enter a comment. this version of mCSD is open for comment.
Elliot Silver (Mar 10 2022 at 16:03):
I was thinking about it from a FHIR point of view, not mCSD.
Joe Lamy (Mar 23 2022 at 19:47):
There's been a lot of recent work by PA to address issues with Endpoint (see the comments for https://jira.hl7.org/browse/FHIR-36074). I opened a new issue to request they change Endpoint.connectionType to CodeableConcept, so we can include our more detailed codes, as it didn't appear there was one specifically for this.
John Moehrke (Mar 23 2022 at 19:59):
those improvements can be used when R5 gets released and IHE moves to R5.
Last updated: Apr 12 2022 at 19:14 UTC
