Stream: IPS
Topic: Query for IPS retrieval
Alessio Graziani (Mar 02 2020 at 14:04):
Hello,
the IPS Implementation Guide standardizes the structure of the Patient Summary using FHIR resources. The Patient Summary is represented with an instance of Composition referring to all other FHIR resources needed to describe other specific aspects of PS. For this reason, the whole PS (Composition + related resources) in FHIR is contained within an instance of Bundle whose first entry is a Composition.
So, my question is: what is the right query to retrieve an instance of IPS,? At the moment I have only these two options:
- query Composition resource in this way: Composition?type=http://loinc.org|60591-5&subject=<ID>&_include=&_count=1*
- query Bundle resource in this way: Bundle?type=document&composition=<ref to Composition representing IPS>
With the first option, the bundle is automatically created by the responding server (and this bundle will be the standard FHIR one not compliant to IPS specs), while with the second option the Bundle must have been previously saved to the server (respecting IPS specs) as a Bundle of type Document.
I suppose that option number 2 is the right way to ask for a PS, but I'm a little worried about the fact that the search parameter "composition" is tagged as TU (Trial Use) so it' far away from being a standard search attribute.
Cheers and thanks
Alessio
Giorgio Cangioli (Mar 02 2020 at 14:22):
Hi @Alessio Graziani if you want that an IPS document is generated by the FHIR server you should use the $document operation (https://www.hl7.org/fhir/composition-operation-document.html)
Giorgio Cangioli (Mar 02 2020 at 14:24):
in this case you need to be able to identify the composition and the server needs to know where to get the referred resources...
Giorgio Cangioli (Mar 02 2020 at 14:27):
If you want to query directly the bundle in principle you could use "Chained parameters" (https://www.hl7.org/fhir/search.html#chaining)
Giorgio Cangioli (Mar 02 2020 at 14:30):
another option that you could consider is that of having the IPS referred by a DocumentReference and query the DocumentReference
Giorgio Cangioli (Mar 02 2020 at 14:30):
each of these options depends on the architecture you have designed and by the capabilities of the involved servers
Giorgio Cangioli (Mar 02 2020 at 14:33):
e.g. a server may not support the $document operation or the needed chained parameters to allow a reasonable query of the IPS bundle.
It may also depend on the behavior of the server when it receives an IPS bundle: e.g most systems I saw when they received an IPS bundle store that bundle as it is; so the composition/$document solution cannot be applied ...
Giorgio Cangioli (Mar 02 2020 at 14:35):
(quite sure that others could suggest other solutions)
Giorgio Cangioli (Mar 02 2020 at 14:42):
Currently the HL7 IPS standard doesn't prescribe any specific solution for sharing and retrieving IPSs
Alessio Graziani (Mar 02 2020 at 14:51):
OK, so you confirm that for the moment there is no standard way to retrieve the IPS.
I will investigate chaining parameters while querying the Bundle resource (option 2 of my hypothesis). At the moment we're querying the Composition resource performing a search of Composition (of a patient) with type="http://loinc.org|60591-5" , "_count" set to 1 and _include set to "*". As a result, we get a Bundle of type "searchset", containing the Composition as the first entry and all related resources as additional entries in the bundle.
But I think that we must create the right Bundle compliant to IPS specs, save it to the server and then retrieving the PS by searching over Bundle resource and not over Composition resource.
Many many thanks
Alessio
John Moehrke (Mar 02 2020 at 15:08):
This function, querying for IPS and other, is the functionality that the IHE IPS profile is addressing.
René Spronk (Mar 02 2020 at 15:08):
I'd hope one would query for DocumentReference .. akin to how MHD/XDS would approach this style of querying. This would be preferred (IMHO) over querying document bundles, or invoking $document directly. Note that a DocumentReference may use a document URL based on $document, so it supports on-demand documents as well.
Lloyd McKenzie (Mar 02 2020 at 15:09):
To retrieve an IPS you'd typically query Bundle and chain through to filter on characteristics of the Composition - specifically subject, document type and time-range
Lloyd McKenzie (Mar 02 2020 at 15:09):
DocumentReference might exist, but there's no guarantee of that - it depends on the architecture of the repository
John Moehrke (Mar 02 2020 at 15:10):
The IPS project is a joint project between HL7 and IHE...
Lloyd McKenzie (Mar 02 2020 at 15:11):
E.g. Bundle?composition.subject.identifier=1234&composition.type=[code for IPS]
Lloyd McKenzie (Mar 02 2020 at 15:11):
Does IHE mandate that MHD be used for IPS?
John Moehrke (Mar 02 2020 at 15:15):
IHE will define for those that chose ANY of the IHE defined Document Sharing profiles, how the data would be published, discovered, and retrieved. This includes MHD, but also includes XDS, XCA, XDM, etc...
As with any IG, it can't state what one does outside of claim of compliance with that IG... so, yes it is fine to have other access methods defined. I simply wanted to have the bulk of the discussion recognized in the appropriate group, and mostly keep everyone aware of the joint project between IHE and HL7
Giorgio Cangioli (Mar 02 2020 at 15:28):
Alessio Graziani said:
OK, so you confirm that for the moment there is no standard way to retrieve the IPS.
I would rephrase your sentence in there are several standard ways to retrieve the IPS.
and this depends on the context of use.
For example if you have the IPS stored into an XD*-like infrastructure MHD is the most reasonable way to access it;
..but you can use an MHD-like approach even if you have not an XD* behind...
I see use cases in which a combined IPS/IPA (International Patient Access) approach is the most useful: e.g the server receives an IPS and it is queried to known if that patient has allergies (or the contrary it receives atomic data and an index of the relevant information (the composition) and it produces the summary, i.e. the IPS bundle, on demand.
Alessio Graziani (Mar 02 2020 at 16:21):
Giorgio Cangioli said:
I would rephrase your sentence in there are several standard ways to retrieve the IPS.
and this depends on the context of use.
Ok. Our context is that the PS must be retrieved from a server adopting FHIR API (the PS has been previously stored in the server by a doctor using an ad-hoc editing application).
Thanks
Alessio
Rob Hausam (Mar 02 2020 at 17:29):
I think, as Giorgio mentioned, that "IPS on IPA" is likely to become a common (and probably recommended) approach to generating/retrieving IPS documents/data from EHR systems. But this is still mostly an idea at present, and we would welcome participation in the discussions and further specification development (IPA, particularly, is still very early) and in planning for and participating in Connectathon testing.
Francesco Torelli (Mar 03 2020 at 10:28):
Hi @Giorgio Cangioli,
I wonder if the answer to the question of @Alessio Graziani depends also from the legal context, other than from the tecnical details of the server.
For example, what is the legal status of an IPS generated automatically in Italy? I know that in Italy the Patient Summary must be created by the GP of the patient. Of course a GP could ask to automatically generate an IPS, review, sign and store it. I understand that only the IPS stored by the GP would be the official Patient Summary. In other term, is it correct to say that on an Italian FHIR server, at least with the current legislation, the automatic generation of the IPS would not return the official Patient Summary, also if the server tecnically supports it?
Giorgio Cangioli (Mar 03 2020 at 10:58):
Hi @Francesco Torelli yes the technical solution depends on the business scenario (including legal constraints) ... but this is true not only for the IPS :-)
Giorgio Cangioli (Mar 03 2020 at 11:04):
Francesco Torelli said:
I understand that only the IPS stored by the GP would be the official Patient Summary. In other term, is it correct to say that on an Italian FHIR server, at least with the current legislation, the automatic generation of the IPS would not return the official Patient Summary, also if the server tecnically supports it?
There are several countries - not only Italy - in which the Patient Summary is the result of a summarization act that has to be realized by a clinician.
In principle nothing prevents to imagine that this act will have as outcome the composition, so that the $document approach could be still valid.... (but as mentioned before it is not the only possible approach)
Francesco Torelli (Mar 03 2020 at 12:48):
Giorgio Cangioli said:
There are several countries - not only Italy - in which the Patient Summary is the result of a summarization act that has to be realized by a clinician.
In principle nothing prevents to imagine that this act will have as outcome the composition, so that the $document approach could be still valid.... (but as mentioned before it is not the only possible approach)
Right, but that composition would not be considered as the entire Patient Summary but just part of it. I mean: if the act of the clinician must produce also a digital signature we should assume that in that country the Composition exists only as part of a signed Bundle containing it. Only the signed Bundle would be considered as the complete and official Patient Summary, because the composition does not contain the signature.
The business scenario that I have in mind is a future version of the eHDSI National Contact Point (NCP) that offers a FHIR based API for retrieving, from a country A, a complete and structured Patient Summary of a patient living in a different country B. I think that, for this business scenario, a standard way to retrieve the complete and official Patient Summary should be agreed and this should be independent from how the Patient Summary is created in each country.
The standard way to retrieve a complete patient summary, in such a cross border scenario, should be a FHIR query that returns an IPS Bundle, because only a Bundle may include also a digital signature, that is part of the Patient Summary in some country. It should be not the client, but the country that exposes the NCP, to decide if the Bundle is generated automatically from a composition or is created and stored manually by a clinician.
The standard API could allow to retrieve also single parts of the Patient Summary, including the entire composition, but it should be agreed that the composition is not (always) the complete official Patient Summary. The standard API could allow to retrieve also a DocumentReference, but only for those situations where, for some reason, a structured content based on FHIR cannot be produced.
Do you agree?
Giorgio Cangioli (Mar 03 2020 at 13:37):
Francesco, your question goes beyond the IPS itself and it might be applied also to other types of information that may be exchanged cross-border in Europe.
The first question to answer is what is the business architecture: i.e. what is your vision, what are your objectives, which are your usage scenarios, what are the external constraints (policy, legal, technical,...), and so on....
I personally see a (very) little advantage of "just" replicating in FHIR the current European CDA based eHDSI technical solution; but this discussion goes beyond the scope of this stream :-)
@Christof Gessner any suggestion on where this kind of discussion may happen ? maybe a "Europe" stream ?
John Moehrke (Mar 03 2020 at 14:41):
I will repeat... The IHE MHD implementation guide provides a constrained methodology of using the FHIR DocumentReference for the purpose of Document Sharing... This API can be to a FHIR server acting as the persistence, other service acting as the persistence (or generator), XCA, or XDS.
There are EC cross boarder requirements to use AS4, which there is an option in IHE XCA that is designed around this cross boarder requirement. Not sure how to handle this AS4 requirement with http/REST, that is for EC participants to argue about.
The IHE portion of IPS is to show binding between the IPS content specification defined in HL7, with the Document Sharing transports (metadata, etc).
Christof Gessner (Mar 04 2020 at 12:55):
@Francesco Torelli @Giorgio Cangioli As @John Moehrke indicates: The functionality of a FHIR interface on the national side of the NCPeH would be very much like MHD. That is because the NCPeH is using XCA on the international side, to connect to the other NCPs. And it may be possibly moving towards AS4 in the future, maybe using Message Queues as an intermediate layer between XCA and AS4. To my knowledge, this is not a requirement, but part of a "feasability analysis" of reusing infrastructure components from European eGov solutions.
I guess that the next steps in EU cross-border exchange are already envisaged. The EHRxF recommendation specifies Exchange formats for EHR content, all document-oriented. So I see little room for FHIR APIs within the current service infrastructure, that connects the NCPeHs between member states.
Christof Gessner (Mar 04 2020 at 13:15):
@Giorgio Cangioli regarding a "Europe" stream: My preferred location would be a page on the eHDSI wiki, e.g. here https://ec.europa.eu/cefdigital/wiki/display/EHMSEG/eHDSI+MS+Expert+Community+Home or here https://ec.europa.eu/cefdigital/wiki/display/EHSEMANTIC/
Francesco Torelli (Mar 04 2020 at 14:24):
Hello @Christof Gessner,
let's remember that the EHRxF recommendation 2019 also says: "The refinement of the exchange format should consider the possibility offered by resource driven information models (such as Health Level Seven Fast Healthcare Interoperability Resources (HL7 FHIR©))". If it makes sense or not is topic for another stream.
As you know, within the InteropEHRate project, we are trying to envision how the eHDSI infrastructure, that is intended for exchange of health data among healthcare providers, will coexist and interoperate with FHIR based mobile protocols for exchange of health data among Patients and healthcare providers and researchers. That is also topic for another stream, more related to MHD, Argonaut Data Query IG, IPA.
Christof Gessner (Mar 04 2020 at 17:44):
Yes, @Francesco Torelli. And I believe, there could be a move towards FHIR-based documents in the future (not soon, though). I just wanted to point out that the architecture of the currently operational cross-border exchange is based on the IHE Cross-Community Access profiles. This is the normative interface between NCPeH instances, agreed between the member states. So whatever interfaces the NCPeH exposes on the national side, this defines the functionality that you can get across borders, for the time being.
Derek Ritz (May 19 2020 at 22:07):
Hi all -- this is a fascinating discussion; and very informative, thank you. Notwithstanding the INTERNATIONAL part of the IPS moniker, there are important use cases that are not focused solely on the exchange of patient summaries across international borders. The IPS -- as a summary -- could satisfy use cases similar to those of the C-CDA; it is a very useful way to support care continuity workflows. For such use cases, a functionality similar to the XDS.b On-demand Document capability is helpful. @Giorgio Cangioli , it appears the the $document operation is the way to support such an on-demand IPS kind of use case. Am I right about that? @John Moehrke -- is this scenario OK within the context of MHDS (although maybe not within the context of MHD)?
John Moehrke (May 20 2020 at 12:07):
The XDS/XCA/MHD system defines a mechanism for "On-Demand" and "Deferred-Creation" document creation/retrieval. These are content agnostic. Thus they will work equally well for CDA documents as they would for FHIR documents; they would even work fine for FHIR resources that don't measure up to the definition of a healthcare document. This because XDS/XCA/MHD use the more liberal internet (http) definition of a 'document', not the more involved (in a good way) definition of a 'document' defined in HL7 (from which we get CDA and FHIR Document)
The FHIR $document operation is specific to FHIR Documents. A good functionality, but very single purpose. It also lacks functionality discovery that is a core part of XDS/XCA/MHD On-Demand system. That said, one could have the instance of a On-Demand document created by way of the $document operation on the backend. Meaning one would publish a "On-Demand" document entry that described a potential use of a $document operation, when a Document Consumer requests it be created and retrieved that is fulfilled on the backend by way of the FHIR $document operation.
So, the infrastructure you have XDS/XCA/MHD already supports On-Demand in a way that can support FHIR Documents. All that is necessary is for custodians to publish FHIR Documents or On-Demand entries indicating support for FHIR Documents; and for Document Consumers to choose to retrieve that kind of content. The infrastructure (XDS/XCA/MHD) is agnostic to this change in content.
Derek Ritz (May 20 2020 at 14:20):
Thanks, @John Moehrke . I asked specifically about MHDS because of my interest in end-to-end FHIR solutions that may be implementable in contexts where there is not a legacy CDA infrastructure already in place. I'm working in such context, now, and am looking for a functionally-equivalent XDS.b On-demand Document... but using FHIR-only.
Marko Jalonen (Aug 06 2020 at 10:22):
About "IPS on IPA" - how is the IPA progressing? There was a mention in this thread that it is still in early stages. There seems to be no change in regard to GitHub in a couple of months.
No mention of IHE QEDm in this thread (XDS/XCA/MHD all are mentioned), is it of any relevance in regard to IPS contents? In QEDm I see only options for specific resource types - not for "IPS-ish" patient summary document --> I see that maybe it would be the domain of IHE MHD then?
Grahame Grieve (Aug 06 2020 at 11:19):
IPA is going slowly. It's important but not urgent
Jens Villadsen (Aug 30 2020 at 19:44):
@Grahame Grieve https://build.fhir.org/ig/grahamegrieve/ipa-candidate/branches/master/ipa-server.html seems immensly empty. Is this because IPA is not doing progress?
Jens Villadsen (Aug 30 2020 at 19:49):
and does "anyone" keep the IPA and IPS profiles in sync/adds dependencies between the IG's? - ie. the patient profiles are not entirely allignd: https://build.fhir.org/ig/grahamegrieve/ipa-candidate/branches/master/StructureDefinition-ipa-patient.html vs https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Patient-uv-ips.html
Grahame Grieve (Aug 30 2020 at 21:03):
IPA hasn't been going anywhere, but it is about to. I'm glad to hear you are interested in it.
Grahame Grieve (Aug 30 2020 at 21:04):
They are different, to reflect their different focus, and I would propose changes to both to get them a little more aligned, but they are not misaligned - that would be that they are incompatible
Jens Villadsen (Sep 01 2020 at 11:25):
k - its going to have pretty much focus from my side once we get to october (@Giorgio Cangioli im looking into pushing the use of IPA in combination with IPS in a #european project which is going to be announced next month I presume )
Giorgio Cangioli (Sep 01 2020 at 12:24):
Hi @Jens Villadsen are you planning to participate the IPS track in the next connect-a-thon ? The European project you mentioned is Gravitate Health or it is a different one ? In both cases let's see if we can reach a wider Eu community and maybe link it to the X-eHealth project started today
Jens Villadsen (Sep 01 2020 at 15:25):
Its gravitate, yes. @Giorgio Cangioli do you also have a part in that?
Giorgio Cangioli (Sep 01 2020 at 15:29):
Yes and I see a possible synergy among UNICOM, X-health and gravitate health
Jens Villadsen (Sep 01 2020 at 17:46):
Awesome - i guess we'll meet later then
Rob Hausam (Sep 02 2020 at 21:55):
@Jens Villadsen I've been hoping that we would start exploring "IPS on IPA" in earnest very soon, so I'm really glad to hear that you are planning to start working on that. And, as @Giorgio Cangioli mentioned, if you have any opportunity to participate in the IPS track in the Connectathon next week, that would be great.
Jens Villadsen (Sep 09 2020 at 17:57):
@Rob Hausam im afraid I cant find the time to attend
Rob Hausam (Sep 09 2020 at 19:52):
I'm sorry to hear that, @Jens Villadsen, but we definitely appreciate your interest and any activities. If you have any update on thoughts or progress, please let us know.
Peter Jordan (Dec 14 2020 at 03:41):
Any advance on the format offered by @Lloyd McKenzie above as a query to request an IPS for a patient with an id of ABC2345? @Rob Hausam , @Giorgio Cangioli ?
GET [base]/Bundle?composition.patient=ABC2345&composition.type=http://loinc.org|60591-5
Although NZ Patient NHIs will be used as IDs by NZ FHIR Servers, many will also use it as an identifier...
GET [base]/Bundle?composition.patient.identifier=https://standards.digital.health.nz/ns/nhi-id|ABC2345&composition.type=http://loinc.org|60591-5
Rob Hausam (Dec 14 2020 at 03:57):
The first one is going to be GET [base]/Bundle?composition.patient.identifier=ABC2345&composition.type=http://loinc.org|60591-5, isn't it? We need to start doing more testing on this - obviously a good topic to explore in the coming Connectathon.
Grahame Grieve (Dec 14 2020 at 03:59):
is this just searching for past summaries? we should use an operation to get the current summary
Rob Hausam (Dec 14 2020 at 03:59):
That makes sense.
Vassil Peytchev (Dec 14 2020 at 04:26):
Although NZ Patient NHIs will be used as IDs by NZ FHIR Servers, many will also use it as an identifiers
Is it expected that FHIR servers will be required to assign a particular value to a Patient.id?
Giorgio Cangioli (Dec 14 2020 at 07:46):
Rob Hausam said:
The first one is going to be
GET [base]/Bundle?composition.patient.identifier=ABC2345&composition.type=http://loinc.org|60591-5, isn't it? We need to start doing more testing on this - obviously a good topic to explore in the coming Connectathon.
We did some quick trials at the last connectathon by using some of the available test servers these are some of the results .. let's try to repeat them increasing the number of examples and specifying more in detail what we'd like to test.
Giorgio Cangioli (Dec 14 2020 at 07:52):
As you can see one server considered GET [base]/Bundle?composition.patient.identifier=XYZ ambiguous (The chained search parameter 'composition.patient.identifier' is ambiguous) and expected that the GET [base]/
Bundle?composition.patient:Patient.identifier=XYZ would be used instead
Peter Jordan (Dec 14 2020 at 08:25):
Rob Hausam said:
The first one is going to be
GET [base]/Bundle?composition.patient.identifier=ABC2345&composition.type=http://loinc.org|60591-5, isn't it? We need to start doing more testing on this - obviously a good topic to explore in the coming Connectathon.
As patient.identifier has a cardinality 0...*, surely it needs to be a token (system|value) when used as a search parameter. OTOH when the patient.id is used as a search parameter, my understanding is that patient=id is sufficient. I would expect that a server that holds a patient resource to have assigned an id to it. I'd only expect to see a patient resource without an id when it's being POSTed by a client for the first time.
Agree with Grahame that an operation would be a more elegant way to request the current summary.
Giorgio Cangioli (Dec 14 2020 at 11:52):
Grahame Grieve said:
is this just searching for past summaries? we should use an operation to get the current summary
Are you thinking to an operation for document bundles ? That would make for sure the life easier for retrieving IPS or other document bundles, beside generating them with the $document operation..
Giorgio Cangioli (Dec 14 2020 at 11:55):
possible search parameters might be
- patient business identifier
- document code/class code
- period (if not set = most recent)
Grahame Grieve (Dec 14 2020 at 12:12):
you can search for existing ones, or explicitly generate them, but I think that the use case is that the requester doesn't know which is which, and shouldn't have to care. They just want a summary if it's available
Grahame Grieve (Dec 14 2020 at 12:12):
whether that means it is generated or not
Grahame Grieve (Jan 15 2021 at 21:46):
Outcome of connectathon discussion about dynamically retrieving an IPS:
GET Patient[/id]/$summary[?graph=xxx&profile=xxx]
GET Patient/$summary?profile=http://hl7.org/fhir/uv/ips/StructureDefinition/Bundle-uv-ips&identifier=
The summary operation asks the server to return the latest appropriate summary for the patient. The patient is either
- explicitly identified by the id of the patient resource
- implicitly identified as the only patient in scope due to security/context
- specified by other additional (unspecified here) parameters (or do we specify the identifier parameter?)
This operation returns a bundle (type = document) for single patient.
Grahame Grieve (Jan 15 2021 at 21:48):
IPS would recommend that smart-app-launch is used to acquire the security tokens for the operation, but that's not part of the definition of the operation
Grahame Grieve (Jan 15 2021 at 21:49):
The operation asks for the latest appropriate summary, whether that already exists, or must be newly generated. Unless otherwise specified, the server has discretion to choose how to fulfill the request. We anticipate that there will be a profusion of business practices around currency/attestation, and therefore variance in parameters around that. If some consistency emerges, HL7 would consider adding additional parameters to the base definition
Grahame Grieve (Jan 15 2021 at 21:50):
IPS will define a profile on Bundle with the URL in the example above, so that an IPS can be reqested. In the absence of a profile parameter, server has discretion to construct/return a summary of it's choice
Last updated: Apr 12 2022 at 19:14 UTC
