Sharing of IPS (sIPS)
1.0.1-current - ci-build International flag

Sharing of IPS (sIPS), published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 1.0.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.sIPS/ and changes regularly. See the Directory of published versions

3:5.9 IPS Content Module

Editor, add the following new section to ITI Volume 3 :

3:5.9 International Patient Summary Content Module

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 IPS document specification is published by HL7.

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.

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.

3:5.9.1 Referenced Standards

3:5.9.2 Document Sharing Metadata

The IHE Document Sharing infrastructures define a common set of Document Metadata, Submission Set, and Folders. There are defined methods of communicating documents including push, centralized registry, and federated discovery and retrieval. The metadata model is designed to be content agnostic so it can support any past or future document specification, which enables all existing networks to support the IPS without modification.

A Document Entry (aka FHIR DocumentReference) is metadata about a document. This metadata is designed to support provenance, lifecycle, authenticity, patient identity, privacy, and exchange of the document that is described. The document can be any kind of format, in this content module we are focused on the International Patient Summary (IPS) document and the format of JSON or XML. Submission Set is the metadata about the publication event, who published these documents, why, when, where, etc. The Folder is an adhoc grouping mechanism that can be used for purposes like grouping a clinical episode. Further explanation of the Value of Metadata is covered in the HIE Whitepaper.

There is a limitation in the Document Sharing metadata that each Document entry must have only one mime-type. The FHIR model supports many mime-type encodings, as does IPS. Some environments may choose one of the FHIR mime-type encodings, where others may need both JSON and XML mime-type encoding of the IPS document bundle. Where more than one mime-type encoding is needed, one would need to register multiple Document entries and indicate they are transforms only differing in mime-type. With multiple Document entries registered, the Document Consumer can pick the mime-type desired, and with the transform relationship be confident that there is no semantic difference between the two mime-type encodings.

To fill out a Document Entry there is a mapping table at PCC TF-2: 4.1.1 that provides guidance. The mapping to a FHIR DocumentReference from the document FHIR Composition is the same as is found in the FHIR Core DocumentReference Mapping from Composition. PCC TF-2: 4.1.1 provides additional guidance.

3:5.9.2.1 DocumentEntry/DocumentReference Metadata

IPS is a FHIR document, the Document Entry metadata is derived from the FHIR document Composition Resource following the Document Sharing Metadata requirements in the PCC TF-2:4 unless otherwise specified below.

3:5.9.2.1.1 FormatCode

The FormatCode shall be http://hl7.org/fhir/uv/ips/StructureDefinition/Bundle-uv-ips, the canonical URI of the IPS Bundle Profile. As a canonical URI, where a system is needed, it shall be urn:ietf:rfc:3986.

3:5.9.2.1.2 On-Demand

When the Document Source is willing to offer to Document Consumers the ability for an on on-demand instance of the IPS to be returned using current data, it can register a Document Entry (DocumentReference) as “On-Demand”. XDS and XCA the On-Demand entry is indicated with a given On-Demand ObjectType as expressed in the given options, in MHD/MHDS an On-Demand entry is indicated with an absent .size and .hash. The Document Entry (DocumentReference) will express specific parameters that would be used if the Document Consumer were to request a document be created “On-Demand”; such as timeperiod refinements, setting, language, etc.

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.

The returned document would, based on configuration, result in an additional DocumentEntry/DocumentReference (aka Snapshot) existing that is in snapshot relationship with the On-Demand DocumentEntry/DocumentReference, and representing the returned document metadata. This snapshot is a “stable” instance that can be retrieved again in the future. More discussion of the relationship between the on-demand and the instances that are preserved as snapshots is explain in HIE Whitepaper: Dynamic Documents.

When a document is produced on-demand, it is typical for this to be created by software without a human interaction. A summary often includes rules such as timeframe of content to include, thus the software is indeed crafting the Composition content; thus it is not just assembling a Bundle based on the pre-authored Composition. A software author of a document can be expressed using a FHIR Device Resource.

The following figure shows one On-Demand Document Entry (DocumentReference) and two instances that have been requested and preserved as snapshots with a snapshot relationship.

DocumentReference 0On-Demand entryIPS SummaryDocumentReference 1Stable entryIPS SummaryJanuary 1, 2023DocumentReference 2Stable entryIPS SummaryJuly 1, 2023IPS 1 document~~~~~~~~~~~~IPS 2 document~~~~~~~~~~~~snapshotsnapshotinstanceinstance
Figure 3:5.9.2.1.2: Example On-Demand relationship to snapshot Stable entries.


3:5.9.2.2 SubmissionSet Metadata

No additional requirements. The SubmissionSet represents the activity For more information, see PCC TF-2: 4.1.1.1.

3:5.9.2.2 Folder Metadata

No additional requirements. For more information, see PCC TF-2: 4.1.1.3.

3:5.9.3 Specification

This Content Module does not constrain the IPS content. See IPS content as defined by HL7 for the definition of the IPS content as defined by HL7.

3:5.9.4 Examples

Given the IPS examples provided in the IPS Implementation Guide, the following DocumentReference would be an example as Registered in Document Sharing. Submission Set and Folders are not shown as they are more dependent on the situation of the publication than the content itself.

See example artifacts