Stream: IPS
Topic: IPS Exchange Model
Cooper Thompson (Oct 04 2021 at 21:07):
Is IPS intending to define anything about how the IPS content gets exchanged (REST API, messaging, files, email, fax, etc.) ? I didn't see anything in the actual IG, but I see some history in this stream about $document and $summary operations.
Elliot Silver (Oct 04 2021 at 21:15):
At the moment, IPS separates the content from the exchange model intentionally. Many people want to be able to claim to be able to issue or consume IPS documents, independently of any particular mechanism of exchange.
Cooper Thompson (Oct 04 2021 at 21:26):
So the IPS IG by itself isn't implementable. It would be one of those "abstract" IGs?
Elliot Silver (Oct 04 2021 at 21:34):
No, it is 100% implementable. If I receive a document, I can absolutely determine if it conforms to IPS. It’s just that IPS doesn’t tell you how you have to receive it.
Peter Jordan (Oct 05 2021 at 00:14):
Requesting the IPS - see the proposed $summary operation on the Patient Resource https://jira.hl7.org/browse/FHIR-32014
Receiving the IPS - Bundle conforming to the IG
We'll be testing both at this week's GDHP Connectathon.
Rob Hausam (Oct 05 2021 at 05:39):
Yes. That's where we are right now. We will need to do some things to address "exchange" questions (whether we add that to the current IG, or not) - but we wanted to leave it open until we began to get some real implementation experience, which is beginning to happen now.
Giorgio Cangioli (Oct 05 2021 at 05:50):
I believe that separating content and transport is an added value in the design of the solution. What we could do, perhaps, is to include a page describing some of the possible exchange mechanisms (including the difference between sending a document to the server end point Vs sending it to the 'Bundle end point '. ) in order readers can have an overview of the different options.
Giorgio Cangioli (Oct 05 2021 at 05:51):
This would allow us to include the definition of the $summary operation without giving the impression that this is the only mean for exchanging IPSs
John Moehrke (Oct 11 2021 at 13:04):
IPS could make mention of various transport IGs that are available, including the IHE-MHD and the other IHE transports for documents -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html
These mentions should be informative, as the actual binding between IPS and any specific transport (including $summary) should be yet-another-higher-IG
Carl Leitner (Oct 15 2021 at 22:21):
i would be interested in looking in particular at MHDS for IPS - modulo that open question on submitting a document bundle which @John Moehrke you said was already documented, but I am not sure where the reference is. i think we will be able to bring some resources to this for the january connectathon, particularly in connection with retrieval of an IPS for generation of the WHO DDCC (flagging for @Luke Duncan @Reece Adamson )
John Moehrke (Oct 18 2021 at 12:17):
@Carl Leitner publishing a document as a FHIR document Bundle, not a Binary, is identified as an open-issue. We discussed it, but it has many issues around it. These issues might not be a problem in many settings, but not all.
Rob Hausam (Oct 18 2021 at 12:19):
We should talk about this and decide where we want to and need to go with it - including for the the January Connectathon.
Carl Leitner (Oct 18 2021 at 19:42):
@John Moehrke -yep, i was just having difficulty finding where it is documented as an open-issue (was hoping to provide it as a reference)
John Moehrke (Oct 18 2021 at 20:10):
https://profiles.ihe.net/ITI/MHD/a_issues.html -- Open Issue MHD_058
Rob Hausam (Oct 18 2021 at 20:16):
In my quick reading of this it seems to make sense to allow the document Bundle:
- MHD_058: The profile requires that the document submitted is encoded in a FHIR Binary. Is there interest in also allowing a Bundle of type Document? This would be useful when publishing FHIR-Documents. The FHIR-Document would still need to be seralized into a Bundle of type Document, but that Bundle would not need to be further encoded into a Binary (e.g. base64 encoding). Note that the mime-type in this case would be forced to be the same mime-type as the ITI-65 Bundle, where a Document Source wants to encode ITI-65 in a mime-type that is different than the document, the Binary methodology would need to be used.
- note that retrieve (ITI-68) does allow the Document Client to ask for the document content in various mime types, thus allowing support for preferred mime type encoding if the Document Responder has the ability to return the content in a encoding other than the DocumentReference indicates.
Is there more that we need to consider and/or weigh in on in this regard? I'm not up on the IHE internal considerations and discussions.
@John Moehrke
John Moehrke (Oct 18 2021 at 20:19):
I think it needs only experimentation to uncover if there are issues. Hence why it is an open issue. We had no one engaged trying it out. I wanted to encourage that, so made it an open-issue./
Last updated: Apr 12 2022 at 19:14 UTC
