Sharing of IPS (sIPS)
1.0.1-current - ci-build
Sharing of IPS (sIPS)
1.0.1-current - ci-build
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
| The following is an excerpt from PCC Volume 2: It is provided here for convenience to the reader and is not intended to be different. It does have CP-PCC-0300 integrated. |
This section defines each IHE transaction in detail, specifying the standards used, and the information transferred.
[PCC-1] describes common functional requirements for content exchange.
Option for a Content Consumer are described below. Content profiles may reference these options as requirements for its Content Consumer; profiles may define other options as necessary.
Documents are created by a Content Creator and consumed by a Content Consumer.
The sharing or transmission of content from one actor to the other is addressed by grouping with appropriate actors from IHE profiles such as:
The population of metadata in the transport from the created content to the IHE transaction that shares it must be described in a Content Binding. Bindings for Document Sharing transactions such as XDS, XCA, XDR and XDM have been described in the section on Content Bindings in IHE PCC TF-2: 4. Transactions found in other IHE profiles (e.g., RFD, MHD) may also be used to exchange content.
Content Creator Expected Actions
Content Consumer Expected Actions
A Content Consumer that supports the View Option:
When a CDA Document is used, this rendering shall meet the requirements defined for CDA Release 2 content presentation semantics (See Section 1.2.4 of the CDA Specification: Human readability and rendering CDA Documents). CDA Header information providing context critical information shall also be rendered in a human readable manner. This includes at a minimum the ability to render the document with the stylesheet specifications provided by the document source, if the document source provides a stylesheet. Content Consumers may optionally view the document with their own stylesheet, but must provide a mechanism to view using the source stylesheet.
The Content Consumer that supports the Document Import Option shall also support the View Option. In addition, the Content Consumer that supports the Document Import Option shall be able to support the storage of the entire document (as provided by the sharing framework, along with sufficient metadata to ensure its later viewing). This Option requires the proper tracking of the document origin. Once a document has been imported, the Content Consumer shall offer a means to view the document without the need to retrieve it again. When viewed after it was imported, a Content Consumer may choose to access the sharing framework to find out if the related Document viewed has been deprecated, replaced or addended.
Note: For example, when using XDS, a Content Consumer may choose to query the Document Registry about a document previously imported in order to find out if this previously imported document may have been replaced or has received an addendum. This capability is offered to Content Consumers by this Integration Profile, but not required, as the events that may justify such a query are extremely implementation specific.
The Content Consumer that supports the Section Import Option shall also support the View Option. In addition, the Content Consumer that supports the Section Import Option shall be able to support the import of one or more sections of the document (along with sufficient metadata to link the data to its source). Once sections have been selected, a Content Consumer shall offer a means to copy the imported section(s) into local data structures as free text. This is to support the display of section level information for comparison or editing in workflows such as medication reconciliation while discrete data import is not possible. When viewed again after it is imported, a Content Consumer may choose to find out if the related information has been updated.
Note: For example, when using XDS, a Content Consumer may choose to query the Document Registry about a document whose sections were previously imported in order to find out if this previously imported document may have been replaced or has received an addendum. This capability is offered to Content Consumers by this Integration Profile, but not required, as the events that may justify such a query are extremely implementation specific.
This Option does not require, but does not exclude the Content Consumer from offering a means to select and import specific subsets of the narrative text of a section.
The Content Consumer that supports the Discrete Data Import Option shall be able to support the storage of the structured content of one or more sections of the document. This Option requires that the user be offered the possibility to select among the specific sections that include structured content a set of clinically relevant record entries (e.g., a problem or an allergy in a list) for import as part of the local patient record.
Note: The Discrete Data Import Option does not require the support of the View, Import Document or Import Sections Options so that it could be used alone to support implementations of Content Consumers such as Public Health Data or Clinical Research systems that might aggregate and anonymize specific population healthcare information data as Document Consumer Actors, but one where no care provider actually views the medical summaries.
When discrete data is accessed after it was imported, a Content Consumer may choose to check if the document related to the discrete data viewed has been deprecated, replaced or addended.
A Content Consumer Actor grouped with the XDS Document Source Actor may query the Document Registry about a document from which discrete data was previously imported in order to find out if this previously imported document may have been replaced or has received an addendum.
A FHIR document is a FHIR Bundle where the first entry is a FHIR Composition and resources referenced are in the Bundle. A composition is a coherent set of information that is a statement of healthcare information, including clinical observations and services. A document is an immutable set of resources with a fixed presentation that is authored and/or attested by humans, organizations and devices.
All documents have the following structure: a Bundle of resources of type “document” that has a Composition resource as the first resource in the bundle, followed by a series of other resources, referenced from the Composition resource, that provide supporting evidence for the document. The bundle gathers all the content of the document into a single XML or JSON document which may be signed and managed as required. Please see http://hl7.org/fhir/documents.html; http://hl7.org/fhir/bundle.html#document.
A Bundle of type “document” is a RESTful object that is not updated, it is just retrievable. See http://hl7.org/fhir/bundle.html#rest . When a Bundle is placed into the control of Document Sharing (e.g., XDS, MHD, XCA, XDM, etc) it is retrieved in the Bundle form as a document given the Document Sharing metadata. The mapping from Composition to DocumentReference can be found in the FHIR core in both Composition and DocumentReference. However, this mapping is only between Composition and DocumentReference. See http://hl7.org/fhir/composition-mappings.html#fhirdocumentreference; http://hl7.org/fhir/documentreference-mappings.html#fhircomposition.
For a mapping between DocumentReferenece and XDS DocumentEntry attributes see http://hl7.org/fhir/documentreference-mappings.html#xds.
Additionally, below in Table 4.1.1 is a mapping between FHIR Document Composition elements and the XDS DocumentEntry attributes.
This section describes how the payload used in a transaction of an IHE profile is related to and/or constrains the data elements sent or received in those transactions. This section is where any specific dependencies between the content and metadata / transaction are defined.
A content integration profile can define multiple bindings. Each binding should identify the transactions and content to which it applies.
The source for all required and optional attributes have been defined in the bindings below. Two tables describe the XDS object types: XDSDocumentEntry, and XDSSubmissionSet. The definitions of the metadata attributes is defined in ITI Volume 3:4, with the optionality defined in ITI Volume 3:4.3. For a mapping between DocumentReferenece and XDS DocumentEntry attributes see http://hl7.org/fhir/documentreference-mappings.html#xds.
This binding defines a transformation that generates metadata for the XDSDocumentEntry and XDSSubmissionSet elements of appropriate transactions from the Document Sharing profiles given a medical document and information from other sources. The medical document refers to the document being stored in a repository that will be referenced in the registry. The other sources of information include the configuration of the Document Source Actor, the XDS Affinity Domain, the site or facility, local agreements, other documents in the registry/repository, and this Content Profile. See Overview of Health Document Sharing Communities.
In many cases, the CDA/FHIR document is created for the purposes of sharing within an XDS Affinity Domain. In these cases the context of the CDA/FHIR Document and the context of the XDS Affinity Domain are the same, in which case the following mappings shall apply.
In other cases, the CDA/FHIR document may have been created for internal use, and are subsequently being shared. In these cases the context of the CDA/FHIR document would not necessarily coincide with that of the XDS Affinity Domain, and the mappings below would not necessarily apply. See Principles of IHE for Health Document sharing.
Please note the specifics given in the table below.
|
XDSDocumentEntry Attribute |
derivation comment |
FHIR Document |
CDA Document |
|---|---|---|---|
|
availabilityStatus |
NA |
||
|
authorInstitution |
Composition. author where the Reference is to an Organization |
$inst <= /ClinicalDocument/author |
|
|
authorPerson |
Composition.author where the Reference is to a Practitioner, Device, or Patient |
$person <= /ClinicalDocument/author |
|
|
authorRole |
This metadata element should be based on a mapping of the participation function defined in the document to the set of author roles configured for the affinity domain. |
Composition.author where the Reference is to a PractitionerRole |
If the context of the CDA coincides with that of the affinity domain,
then the following x-path may be appropriate: |
|
authorSpecialty |
This metadata element should be based on a mapping of the code associated with the author to detailed defined classification system for healthcare providers such configured in the affinitity domain. Possible classifications include those found in SNOMED-CT, or the HIPAA Healthcare Provider Taxonomy. |
Composition.author where the Reference is a PractitionerRole use the PractitionerRole.speciality |
If the context of the CDA coincides with that of the affinity domain,
then the following x-path may be appropriate: |
|
classCode |
Derived from a mapping to an Affinity Domain specified coded value to use and coding system. Affinity Domains are encouraged to use the appropriate value for Type of Service, based on the LOINC Type of Service (see Page 53 of the LOINC User's Manual). |
Must be consistent with Composition.category |
Must be consistent with /ClinicalDocument/code/@code |
|
classCodeDisplayName |
DisplayName of the classCode derived appropriate Display Name based on the Type of Service. |
Must be consistent with Composition.category |
Must be consistent with /ClinicalDocument/code/@code |
|
confidentialityCode |
Derived from a mapping of the document confidentialityCode and other security labels to Affinity Domain specified coded values and coding system. |
Derived from Composition.confidentiality, Composition.meta.security |
/ClinicalDocument/ |
|
comments |
There is no well-known element in a document to derive a simple comment. |
||
|
creationTime |
Times specified in clinical documents may be specified with a precision in fractional sections, and may contain a time zone offset. In the XDS Metadata, it can be precise to the second, and is always given in UTC, so the timezone offset if present must be added to the current time to obtain the UTC time. |
Composition.date |
/ClinicalDocument/effectiveTime |
|
entryUUID |
This element identifies the Document Entry, not the document. |
||
|
eventCodeList |
These values express a collection of keywords that may be relevant to the consumer of the documents in the registry. They may come from anywhere in the document, according to its purpose. |
Composition.event |
They may come from anywhere in the CDA document, according to its purpose. |
|
eventCodeDisplayNameList |
These are the display names for the collection of keywords described above. |
Composition.event |
These are the display names for the collection of keywords described above. |
|
formatCode |
The format code for each PCC Document content profile is provided within the document specifications. |
Bundle.meta.profile |
The format code for each PCC Document content profile is provided within the document specifications. Usually related to the CDA template id. |
|
healthcareFacilityTypeCode |
A fixed value assigned to the Document Source and configured form a set of Affinity Domain defined values. Usually from a mapping to an Affinity Domain specific ValueSet. |
May be derived from Composition.author where the Reference is to an Organization |
Must be consistent with /clinicalDocument/code |
|
healthcareFacility |
The display name for the healthcare facility type code indicated above. |
May be derived from Composition.author where the Reference is to an Organization |
Must be consistent with /clinicalDocument/code |
|
languageCode |
The human language of the narrative within the document |
Composition.meta. language |
/ClinicalDocument/languageCode |
|
legalAuthenticator |
Composition.attester |
$person <= /ClinicalDocument/ The legalAuthenticator can be formatted using the following XPath
expression, where $person in the expression below represents the
legalAuthenticator. |
|
|
mimeType |
The mime type of the document. |
text/xml |
|
|
patientId |
The XDS Affinity Domain patient ID can be mapped from the patient identity in the document by using transactions from the ITI patient identity profiles. See sourcePatientId below. |
Composition.subject |
$patID <= /ClinicalDocument/recordTarget/ |
|
practiceSettingCode |
This elements should be based on an Affinity Domain managed ValueSet of coarse classification system for the class of specialty practice. Recommend the use of the classification system for Practice Setting, such as that described by the Subject Matter Domain in LOINC. |
May be derived from Composition.author where the Reference is to an Organization |
|
|
practiceSettingCodeDisplayName |
This element shall contain the display names associated with the codes described above. |
May be derived from Composition.author where the Reference is to an Organization |
|
|
serviceStartTime |
Times specified in clinical documents may be specified with a precision in fractional sections, and may contain a time zone offset. In the XDS Metadata, it can be precise to the second, and is always given in UTC, so the timezone offset if present must be added to the current time to obtain the UTC time. |
Composition.event.period |
/ClinicalDocument/documentationOf/ |
|
serviceStopTime |
Times specified in clinical documents may be specified with a precision in fractional sections, and may contain a time zone offset. In the XDS Metadata, it can be precise to the second, and is always given in UTC, so the timezone offset if present must be added to the current time to obtain the UTC time. |
Composition.event.period |
/ClinicalDocument/documentationOf/ |
|
sourcePatientId |
This element contains the patient id as is known in the source domain. |
Composition.subject |
$patID <= /ClinicalDocument/recordTarget/ The patientId can be formatted using the following XPath expression,
where $patID in the expression below represents the appropriate
identifier. |
|
sourcePatientInfo |
The sourcePatientInfo metadata element can be assembled from various components of the patientRole element in the clinical document. |
Composition.subject |
/ClinicalDocument/recordTarget/ |
|
title |
/ClinicalDocument/title |
Composition.title |
/ClinicalDocument/title |
|
typeCode |
The typeCode should be mapped to an Affinity Domain managed ValueSet of document type codes. One suggested coding system to use for typeCode is LOINC, in which case the mapping step can be omitted. |
Composition.type |
/ClinicalDocument/code/@code |
|
typeCodeDisplay |
The display name of the typeCode above. |
Composition.type |
/ClinicalDocument/code/@displayName |
|
uniqueId |
The uniqueId is the unique id within the document. |
Composition.identifier (business identifier) or full URI to the Composition if no business identifier given |
$docID <= /ClinicalDocument/id The uniqueId can be formatted using the following XPath expression,
where $docID in the expression below represents the identifier. |
The submission set metadata is as defined for XDS, and is not necessarily affected by the content of the clinical document. Metadata values in an XDSSubmissionSet with names identical to those in the XDSDocumentEntry may be inherited from XDSDocumentEntry metadata, but this is left to XDS Affinity Domain policy and/or application configuration.
For XDR and XDM the XDS Submission Set intendedRecipient attribute may be populated as specified in the table below.
| XDSSubmissionSet Attribute | FHIR Document | Source/ Value |
|---|---|---|
| intendedRecipient | NA | $person <= /ClinicalDocument/intendedRecipient and/or $inst <= /ClinicalDocument/intendedRecipient/receivedOrganization |
This content format uses the XDS Submission Set to create a package of information to send from one provider to another. All documents referenced by the Medical Summary in this Package must be in the submission set.
No specific requirements identified.
IHE Content Profiles using this binding require that Content Creators and Content Consumers be configurable with institution and other specific attributes or parameters. Implementers should be aware of these requirements to make such attributes easily configurable. There shall be a mechanism for the publishing and distribution of style sheets used to view clinical documents.
IG © 2023+ IHE IT Infrastructure Technical Committee. Package ihe.iti.sips#1.0.1-current based on FHIR 4.0.1. Generated 2024-05-09
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change