Sharing of IPS (sIPS) - defines how HL7 FHIR IPS is communicated using IHE Document Sharing
Home Page: https://profiles.ihe.net/ITI/sIPS/index.html
License: Creative Commons Attribution 4.0 International
Sharing of IPS (sIPS) - defines how HL7 FHIR IPS is communicated using IHE Document Sharing
Formal Publication -- https://profiles.ihe.net/ITI/sIPS
.
Given that the IPS is a patient level summary, and can be created by invoking the $summary operation, it is possible to exchange an IPS without conventional document sharing actors or working with document sharing objects. This would be done by simply having the Content Consumer invoke the $summary operation of the Content Creator.
Implementations that are FHIR focused, and need only to exchange IPS and not other documents, would likely want to implement this solution, as it is the least complex.
$summary should probably be considered an option for sharing the IPS along with the existing document sharing profiles. Linking this to the On-Demand concept and explaining the limitations of $summary (no ability to expand to additional documents) would also be helpful.
No response
No response
Comment received from @stl-steve-moore
The many prior PCC content profiles referenced the PCC-1 transaction as required, but weasel language in that transaction made it a suggestion rather than a specification. Further, because there are many ways to exchange a document using PCC-1 by design, the customer who reads an IHE Integration Statement has no idea which mechanisms are supported by a product in conjunction with a content document.
This supplement is better than the other supplements in that it does not invoke PCC-1 as a requirement. Yet, it still falls short because it does not provide a mechanism to write an Integration Statement that clearly spells out what sharing mechanisms are supported.
There is a solution that can be tested here and adopted with other profiles if found worthy. You could add formal, named options to the Creator and Consumer actors that clearly indicate a document sharing mechanism. Those options are the usual suspects, but by explicitly naming them, I can now put that in my Integration Statement. As a customer, I can put that directly in my RFP rather than having to invent language.
We had many discussions years ago about this issue, but could never get past the "Do we list content first and transport second, or do we list transport first and content second?". Here is the chance to make a choice where the top level is now "Sharing content of document X" and the options are the sharing mechanisms. "Sharing content of document X" is the sIPS profile.
aIPS is currently very XDS focused. While this is helpful for XDS minded readers, readers that are not familiar with XDS and wish to implement an MHD compatible solution might find the frequent references to XDS concepts off-putting.
I think it would be helpful to these readers to concisely explain the minimal concepts needed to exchange IPS with DocumentReference in aIPS in a way that allows them to avoid referencing external specifications. References to XDS and the HIE white paper can still be provided, but for readers that wish to work in a traditional XDS environment or accomplish advanced exchange.
For On-Demand vs Stable, example use cases for both would be helpful.
I also think a Profile of DocumentReference with the PCC mappings applies to IPS would be helpful.
No response
No response
1:56.1.1.1
In section 1:56.1.1.1, the requirements on the Content Creator are:
"The Content Creator creates the IPS content and shares it using one of the methods defined in the IHE Document Sharing Health Information Exchange."
Similarly, the requirements on the Content Consumer are:
"The Content Consumer consumes the IPS content and obtains it using one of the methods defined in the IHE Document Sharing Health Information Exchange."
But in section 3:5.9.2.1.2, we say:
"When the On-Demand entry is requested by a Document Consumer, the responding actor may chose to utilize the IPS $summary operation. This use of the $summary operation is not required to be the method used."
So, volume 3 suggests one can use $summary to exchange IPS. But, there is no IHE profile that defines $summary. So, based on the Volume 1 text, is is unclear whether a Content Creator/Consumer that supports exchanging of IPS using $summary, but does not support exchanging it via any IHE document sharing profiles, would be conformant to sIPS.
Clarify whether this is allow. IMO, $summary is a very straightforward way to exchange IPS and should be a mechanism to satisfy sIPS.
{"High"=>"Important issue where there is major issue to be resolved. Requires discussion and debate."}
Given an IPS document fully populated carries sensitive information, and thus would have limited access to only those allowed access to restricted information.
When one needs to support broad availability of the non-sensitive information as normal confidentiality.
Then one can publish a Transform of the original sensitive document, where this transform has redacted the sensitive information but otherwise is the normal data. This normal document would have normal confidentiality, and would be indicated as a transform.
See https://healthcaresecprivacy.blogspot.com/2012/09/advanced-access-controls-to-support.html
aIPS_001: Minimal View Option is referring the reader to FHIR Core for Documents. Are there more specific requirements available from IPS or IHE?
The second sentence in the intro seems to have gotten cut off during editing. I'm not quite sure where it's going.
The International Patient Summary (IPS) content, as defined in the ISO 27269 data model specification, utilizing IHE’s document sharing infrastructure including cross-community.
3:5.9.2.1.2
The following statement is confusing:
"The IPS $summary operation being invoked in this way uses the Document Sharing network to enable very remote clients, such as those many XCA communities away."
It is not clear how the $summary relates to degrees of separation of document exchange communities.
Clarify the meaning of the statement or remove.
{"Medium"=>"Significant issue or clarification. Requires discussion, but should not lead to long debate."}
As for the intro, I think it needs some work. I wanted to work with you on it, but if you don’t have cycles, then I’ll take a stab at drafting a version that I think will be more marketing oriented. Please confirm that this is the direction you’d like me to take. The content now is found below, and I’ll use that as my starting point:
Given that HL7 has published an International Patient Summary, which is a FHIR-Document, this Implementation Guide defines how to communicate and access the IPS using IHE Document Sharing Health Information Exchange. This is an IHE Content Module as defined in the IHE Technical Frameworks General Introduction. This Implementation Guide does not further refine the IPS, and thus any document conforming to the HL7 base IPS specification is applicable here.
An International Patient Summary (IPS) document is an electronic health record extract containing essential healthcare information about a subject of care. As specified in EN ISO 27269, it is designed for supporting the use case scenario for ‘unplanned, cross border care’, but it is not limited to it. It is intended to be international, i.e., to provide generic solutions for global application beyond a particular region or country.
The IPS dataset is minimal and non-exhaustive; specialty-agnostic and condition-independent; but still clinically relevant. The FHIR IPS document specification is published by HL7 and is the focus of the sIPS. There is a CDA encoding of the IPS, but there has been little interest in use at this time.
The IHE sIPS does not modify the HL7 IPS specification, but provides for methods of sharing the IPS using IHE Document Sharing. The IPS, as a “current summary”, is an excellent document for the “On-Demand” capability of the Document Sharing infrastructure. On-Demand is available in XDS with On-Demand Documents Option, XCA with On-Demand Documents Option, and with MHD/MHDS. Further details for IPS use of On-Demand are outlined below in section 3.9.2.1.2. IHE Document Sharing also has “Stable” and “Delayed Assembly” document entry types that are further explained in the HIE Whitepaper: Dynamics Documents.
The IPS document is composed by a set of robust, well-defined and potentially reusable sets of core data items (indicated as IPS library in the figure below). The tight focus of the IPS on unplanned care is in this case not a limitation, but on the contrary, facilitates their potential re-use beyond the IPS scope.
I've taken the liberty of re-drafting the introduction section to the sIPS profile, to better accommodate how this profile might be marketed to the implementation community. The changes reflect a few important considerations:
I hope my suggestions are understood, and eventually find their way into the final published version. Please reach out if you need to get further clarity or background. Mike.
My proposed re-draft is as follows:
The Sharing of IPS (sIPS) IHE Profile has been created to facilitate the exchange of the International Patient Summary (IPS) content, as defined in the ISO 27269 data model specification, utilizing IHE’s XDS document sharing infrastructure both “locally” and “cross-community”. It has been designed specifically to remove barriers to adoption, by leveraging architectures that are currently implemented, well-established, and robust. The sIPS Profile provides implementation guidance to vendors and implementers, and joins a growing “suite” of IPS standards artefacts contributed by a variety of Standards Development Organizations (SDOs), and coordinated by the Joint Initiative Council for Global Health Informatics Standardization (JIC).
An IPS document is an electronic health record extract, taken at a point in time, containing essential healthcare information about a subject of care. It is designed for supporting the use case scenario for ‘planned and unplanned, cross border care’, and although it is intended to be used across international borders, it is equally useful to exchange information across any jurisdictional border, including those within a particular region or country. The IPS dataset is minimal and non-exhaustive; specialty-agnostic and condition-independent but still clinically relevant.
This profile leverages IHE IPS content profile, the most recent version published in 2023, which in turn references HL7s IPS Implementation Guides (IGs) for FHIR (2022) and CDA (2018). Due to the minimal global uptake of the CDA encoding of the IPS at this time, the focus of the sIPS Profile is currently based on the specification provided in the HL7 FHIR IG. As such, the sIPS Profile does not further refine the IPS, thus any document conforming to the HL7 base IPS specification is applicable here. The IPS specification is composed of a set of robust, well-defined and potentially reusable sets of core data items (indicated as the IPS library in the figure below).
The sIPS Profile provides guidance to implementers on how a number of important functions may be leveraged to support key IPS use cases. These include:
• Publishing an IPS
• On Demand Access to an IPS
• Retrieving an IPS
• Pushing an IPS to a Recipient
As noted, the IHE sIPS Profile does not modify the HL7 IPS FHIR specification, but rather provides for methods of sharing the IPS using IHE Document Sharing. The IPS, as a “current summary”, is an excellent document for the “On-Demand” capability of the Document Sharing infrastructure. On-Demand is available in XDS with On-Demand Documents Option, XCA with On-Demand Documents Option, and with MHD/MHDS. Further details for IPS use of On-Demand are outlined below in section 3.9.2.1.2. IHE Document Sharing also has “Stable” and “Delayed Assembly” document entry types that are further explained in the HIE Whitepaper: Dynamics Documents.
4.1.1
The mapping table from DocumentEntry metadata attributes to Composition elements suggests that if there is no suitable Composition.identifier then Composition.id might be mapped to DocumentEntry.uniqueId. This is likely not appropriate, since DocumentEntry.uniqueId shall be globally unique, but Composition.id need only be unique within the FHIR server on which it resides.
If there is no suitable Composition.identifier, the DocumentEntry.uniqueId would need to be a full URI to the Composition Resource.
No response
{"Medium"=>"Significant issue or clarification. Requires discussion, but should not lead to long debate."}
56.2.1 View Option
There is a TODO in this section that looks like it should possibly be an open issue for the public comment.
Determine if an open issues is the best place for this.
No response
{"Low"=>"Typo or other minor classification that an editor can manage. Requires no group discussion."}
4.1.1
Composition bundle column for healthcareFacilityTypeCode ends abruptly:
"May be derived from Composition.author where the Reference is to an Organization
Composition.author where"
No response
No response
{"Low"=>"Typo or other minor classification that an editor can manage. Requires no group discussion."}
Artifacts
There are two artifacts titled "DocumentReference for the Bundle-01 IPS document"
These should be given names that differentiate them.
No response
{"Low"=>"Typo or other minor classification that an editor can manage. Requires no group discussion."}
https://profiles.ihe.net/ITI/sIPS/content.html#359212-on-demand
should recommend that when the on-demand document is produced by automation that the software and possibly the rules the software is using should be expressed in a Device resource as the author.
Should this author be expressed in both the IPS and the DocumentReference, or just the DocumentReference?
See IPS-122 https://jira.ihtsdotools.org/browse/IPS-122
Figure 1:56.4.1-1 and 3:5.9.2.1.2
These figures refer to the relationship between an OnDemand DocumentReference and Stable DocumentReferences as "transforms". However, that terminology is not consistent with ITI Volume 3, which refers to this association type as a "snapshot". See ITI TF-3 Table 4.2.2-1 for this definition.
Change the figures to say "snapshot" instead of "transform".
{"Low"=>"Typo or other minor classification that an editor can manage. Requires no group discussion."}
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
