PCC TF-1/XDS-MS
Cross-Enterprise Sharing of Medical Summaries (XDS-MS) Integration Profile
Scope and Purpose
Patient, clinician, industry and governmental demands for improved healthcare quality have created increased focus to make patient healthcare information interoperability across disparate systems a reality.
A solution for interoperability is, however, not a simple undertaking. Unstructured textual data forms remains the predominate mechanism for information exchange among health care providers, and a good majority of data needed by physicians and other health care providers to make good clinical decisions is embedded in this free text. Efficient and effective interoperability therefore begins by identifying the most relevant documents and the most relevant sections within those documents.
By their nature, Medical Summaries form a class of clinical documents that contain the most relevant portions of this information. As the name would indicate they have the purpose of summarizing, both abstracting the most important pieces of information from the EMR and recording free-text summaries at the time of medical summary creation. Operationally, they are commonly created at points in time of transfers of care from one provider to another or from one setting to another.
Patient transfers and, therefore, the summary documents that accompany these transfers can be categorized into 3 primary types: Episodic, Collaborative, or Permanent. These categories are important because they represent a breadth of use case scenarios for Medical Summaries. For example, summaries for collaborative transfers of care such as referral notes have a focused objective for providing the most relevant information about the patient intended for a specific provider. Collaborative summaries have a general audience that is generated as an artifact since they also provide the most relevant spot to obtain information about specific classes of patient problems that the patient has.
By contrast, episodic summaries have the primary purpose of highlighting the most relevant details of focused periods of time in a patient history. Examples include discharge summaries or history and physicals. Episodic summaries are written for a broad audience by intent.
Permanent transfers have yet a third purpose of summarizing the entirety of a patient's medical history and therefore covers a broader range of patient problems. The audience may be focused (as in a transfer to a new provider) or general (as in a discharge from the military).
The challenge is to identify the clinically relevant documents (and data elements those documents contain) that are used in typical "transfer of care" scenarios and then to provide interoperability standards to promote ease in transmission of those documents (and data elements). The Cross-Enterprise Sharing of Medical Summary (XDS-MS) Integration Profile facilitates this by defining the appropriate standards for document transmission and a minimum set of "record entries" that should be forwarded or made available to subsequent care provider(s) during specific transfer of care scenarios. In addition, this integration profile needs to define the utilization requirements/options for the receiving entity in order to ensure that the "care context" of the sending entity is appropriately maintained following the information transfer.
Process Flow
The basic process flow supported by XDS-MS mirrors current manual practices: someone gathers the appropriate documents from the patient medical record, copies them, packages them up with a cover letter explaining the reason the information is being sent, and then ships the package to the receiving provider. This is often accompanied by a telephone call from the sending provider to the receiving provider that indicates that such information is forthcoming.
Because the Collaborative care transfers and Episodic Care transfers differ significantly, these two use cases are defined. Users or implementers of this Integration Profile are offered options in the support of either of these two use cases. Permanent Care Summaries also differ significantly. However their use is less frequent; so this use case was deferred for future work.
Use Case 1: Ambulatory Specialist Referral
This use case involves a "collaborative" transfer of care for the referral of a patient from a primary care provider (PCP) to a specialist. This use case is a central component of an "e-referral" process, which typically requires an appropriate level of agreement/collaboration between the two parties prior to the actual transfer of clinical information being initiated.
The preconditions assume a PCP sees a patient in his office. The PCP has talked to the patient and performed an examination, and has decided to refer the patient to a specialist. An assumption is made that the PCP has an EMR system with capability to write notes and manage data elements. The specific data elements managed by the PCP's EMR are expected to be the source for the information used in creating the medical summary document related to this transfer of care. A variety of EMR implementations and usage by clinicians may result in some variability in the content of the medical summary.
The detailed content of the medical summary to support this use case will be detailed as part of the document content profile specification (See PCC TF-2: 5.4.1.3).
Steps to identify the specialist and obtain insurance preauthorization have been placed out of scope for this Integration Profile.
Post conditions include the specialist physician receiving the notification of referral, locating the documents (via the Document Registry), retrieving the Documents and viewing them and optionally importing data. Import assumes the specialist with an EMR system with the capability for managing those discrete data elements.
Use Case 2: Acute Care Discharge to Ambulatory Care Environment
This use case involves an episodic transfer of care in the form of a patient discharge from a hospital to home. The attending physician in the hospital generates a discharge summary document that is used by the hospital record keeping and billing abstraction. The attending physician in the hospital may or may not also be serving as the ambulatory PCP. If not, a copy of this record is sent to the PCP as well as other specialist providers that will have ambulatory follow-up care.
The events of the use case involve creation of the discharge summary, sharing it, and notifying other providers such as the PCP's office and the surgeon's office.
The post conditions include the receipt and viewing of the discharge summary with optional import into the ambulatory EMR system.
The detailed content of the medical summary to support this use case will be detailed as part of the document content profile specification (See PCC TF-2: 5.4.1.4).
Note that the two use cases above use the same set of transactions and differs only in the content of the Medical Summary. A process flow for these use cases using XDS and NAV is listed in Figure 3.2 1. Other process flows are possible using XDM and/or XDR.
These steps are:
- Extract/capture a collection of records into a set of documents packaged as an XDS Submission Set. This submission contains a Medical Summary, and may contain a number of other related clinical documents. Medical Summaries are clinical documents (already known in the paper world), which often serve a dual purpose of documenting an encounter, while providing the rationale for sending the information to another provider. This step utilizes the transactions provided by the ITI XDS profile to place the records in an XDS Repository (local or shared).
- The Repository ensures that the documents of the submission set are registered with the XDS Registry of the Affinity Domain (set of cooperating care delivery institutions).
- Notify the other provider that documents are now available for review. This step utilizes the transactions provided by the ITI NAV profile to perform the e-mail notification.
- The e-mail notification that contains no patient identified information is received by the specialist EMR system.
- The receiving provider can then utilize existing query transactions from the XDS profile to find the URL of the Documents.
- Finally, the receiving provider may choose to display the document, or import relevant information from these records into their own EMR system.
Use Case for Unplanned Access to past Medical Summaries
In many cases, a provider may need to assess information from the patient care history, and patients may have Medical Summaries in the XDS repository from prior visits to other providers. For example, Medical Summaries, as well as other documents such as laboratory and radiology reports are critical for emergency physicians and nurses to provide the best care to patient in acute conditions. Figure 3.2 2 shows the transactions required for this use case, again, using XDS. Other process flows are possible using XDM and/or XDR.
Content Interoperability Levels
The use cases described above imply different levels of interoperability. At the lowest level, a clinician simply needs to be able to access and view some content such as a medical summary. At this level, minimal structured data elements must be present – just enough metadata to verify that access to that document can be accessed appropriately associated with a visual representation of the document.
Beyond this simple metadata, nearly all medical summary documents have organizational elements that group the relevant parts of the medical summary. For humans this allows for more rapid review because it is easier to skip to portions of interest for care. Computers too can take advantage of this structuring. For example, it is relevant to see the list of discharge medications from a discharge summary in relation to current medications for comparison and reconciliation.
At a very high level of interoperability, the ability to pass fully structured and codified data is necessary for computer processing and mapping. For example, the ability to import medications identified in medical summaries from another institution could have tremendous potential for ensuring that medication orders are transferred correctly. Unfortunately, the cost for providing high levels of semantic interoperability is increased complexity of implementation, and therefore long implementation times.
The HL7 Clinical Document Architecture (CDA) standard and Care Record Summary (CRS) CDA implementation guides support progressive interoperability at multiple levels of complexity, from those needed to provide simple low level interoperability for supporting the most important use case of simple viewing to those providing a path to progressively higher levels of interoperability for vendors and providers wishing to implement it. CDA as constrained in the CRS implementation guides is therefore the base standard for the XDS-MS content profile.
The XDS-MS content profile builds on and further constrains the CDA-CRS implementation guide by defining the required and optional sections required for the Acute Care Discharge and Specialist Referral use cases. Additionally, it places constraints for the most important sections (Medication, Allergy and Problems) of Medical Summaries to ensure that structured field level data are provided.
The figure below shows how the XDS-MS Content profile defines these progressive levels of interoperability for sections of different importance. Header metadata must be present and coded. Most sections must define, at minimum, a section label to identify that section. For the Medication, Allergy, and Problems Sections, data must contain a more granular field level data as discrete text (for example dose or frequency). This is referred to as structured textual representation. Note that the textual strings in this structured text are not duplicates of the textual strings in the human readable text, but simply referenced extracts from the human readable text content, reducing the risk for inconsistencies
Granular field level data may then be optionally coded. If any coded terminology is used it shall be uniquely identified.
| Note: The lack of mature and broadly accepted standards for coded terminology requires that this integration profile not specify specific coded vocabularies. However, when agreements can be reached, the capability to exchange coded level information is possible. IHE has on its roadmap to continue working with appropriate standards bodies so that coded terminology standards can be added to this profile in the future. |
Use Case Conclusion
The process flow of this profile exhibits a great deal more power and flexibility than the existing manual process. The physician workflow is improved by reusing an existing work product in the very first step (the summary report) to accomplish two purposes: recording care that has been provided, and communicating with another provider.
Secondly, each step utilizes the power of inter-connected EMR systems to make the entire process faster, easier, and less reliant on human labor to accomplish the same feats. This results in reduced time to transfer records between providers, safer transport of the information, and more reliable receipt.
Lastly, the process facilitates the import of relevant data from one set of patient records to the receiving physicians EMR system, resulting in more reliable transfer of information, reduced labor costs transferring information from one provider to another and less time required by the patient to provide information that is already in the physician's possession.
Actors/Transaction
There are two actors in the XDS-MS profile, the Content Creator and the Content Consumer. Content is created by a Content Creator and is to be consumed by a Content Consumer. The sharing or transmission of content from one actor to the other is addressed by the appropriate use of IHE profiles described below, and is out of scope of this profile. A Document Source or a Portable Media Creator may embody the Content Creator Actor. A Document Consumer, a Document Recipient or a Portable Media Importer may embody the Content Consumer Actor. The sharing or transmission of content or updates from one actor to the other is addressed by the use of appropriate IHE profiles described in the section on Content Bindings with XDS, XDM and XDR.
Options
| Actor | Option |
|---|---|
| Content Consumer | View Option (1) |
| Document Import Option (1) | |
| Section Import Option (1) | |
| Discrete Data Import Option (1) | |
| Content Creator | Referral Option (1) |
| Discharge Summary Option (1) |
Content Consumer Options
View Option
This option defines the processing requirements placed on Content Consumers for providing access, rendering and management of the medical document. See the View Option in PCC TF-2 for more details on this option.
A Content Creator Actor should provide access to a style sheet that ensures consistent rendering of the medical document content as was displayed by the Content Consumer Actor.
The Content Consumer Actor shall be able to present a view of the document using this style sheet if present.
Document Import Option
This option defines the processing requirements placed on Content Consumers for providing access, and importing the entire medical document and managing it as part of the patient record. See the Document Import Option in PCC TF-2 for more details on this option.
Section Import Option
This option defines the processing requirements placed on Content Consumers for providing access to, and importing the selected section of the medical document and managing them as part of the patient record. See the Section Import Option in PCC TF-2 for more details on this option.
Discrete Data Import Option
This option defines the processing requirements placed on Content Consumers for providing access, and importing discrete data from selected sections of the medical document and managing them as part of the patient record. See the Discrete Data Import Option in PCC TF-2 for more details on this option.
Content Creator Options
Referral Option
Content Creators implementing this option shall create Referrals that comply with the Referral Content Module described in PCC TF-2: 5.4.1.3.
Discharge Summary Option
Content Creators implementing this option shall create Discharge Summaries that comply with the Discharge Summary Module described in PCC TF-2: 5.4.1.4.
Coded Terminologies
The Medical Summary Content Module (See PCC TF-2: 5.4.1.2) supports the optional capability to encode a number of coded record entries beyond the IHE required coding associated with structured text. The export and import of these specific coded record entries (See PCC TF-2: 3.1.4) is not an explicitly identified option in this XDS-MS Integration Profile, as the associated coded terminologies are not specified by this Profile. Content Creators and Content Consumers may choose to utilize coded data, but interoperability at this level requires an agreement between the communicating parties that is beyond the scope of this Profile. With further progress in the development of standard coded terminologies, future extensions to this Integration Profile are expected to address these higher levels of interoperability.
Content Bindings with XDS, XDM and XDR
It is expected that this profile will be used environment where the physician offices and hospitals have a coordinated infrastructure that serves the information sharing needs of this community of care. Several mechanisms are supported by IHE profiles:
- A registry/repository-based infrastructure is defined by the IHE Cross-Enterprise Document Sharing (XDS) and other IHE Integration Profiles such as patient identification (PIX & PDQ), and notification of availability of documents (NAV).
- A media-based infrastructure is defined by the IHE Cross-Enterprise Document Media Interchange (XDM) profile.
- A reliable messaging-based infrastructure is defined by the IHE Cross-Enterprise Document Reliable Interchange (XDR) profile.
- All of these infrastructures support Security and privacy through the use of the Consistent Time (CT) and Audit Trail and Node Authentication (ATNA) profiles.
For more details on these profiles, see the IHE IT Infrastructure Technical Framework, found here: http://www.ihe.net/Technical_Framework/.
Such an infrastructure is assumed by the use cases that focus on the context for defining the specific clinical information content for this profile.
A content binding describe how the payloads used in IHE transactions are related to and/or constrained by the data elements contained within the content sent or received in those transactions. This section is where any specific dependencies between the content and transaction are defined. The Patient Care Coordination Technical Framework defines a binding to use when grouping the Content Creator with the IHE ITI XDS, XDM or XDR Integration Profiles.
| Content | Binding | Actor | Optionality |
| Discharge Summary PCC TF-2: 5.4.1.3 |
Medical Document Binding to XD* PCC TF-2: 4.1 |
Content Creator | O (Note 1) |
| Content Consumer | R | ||
| Referral PCC TF-2: 5.4.1.4 |
Medical Document Binding to XD* PCC TF-2: 4.1 |
Content Creator | O (Note 1) |
| Content Consumer | R |
| Note 1: Content Creators must support generation of at least one type of content from this table with a transaction in order for the transaction to meet the requirements of the XDS-MS profile. Content Consumers must support both types of content to meet these requirements. |
Content Modules
Content modules describe the content of a payload found in an IHE transaction. Content profiles are transaction neutral. They do not have dependencies upon the transaction that they appear in. These dependencies are reflected in the Bindings listed above.
Discharge Summary
All discharge summaries shall be structured and coded as required by the Discharge Summary Content Module. The inclusion of the specific coded attributes explicitly defined as optional, may be supported by specific implementations of Document Sources using an IHE identified coded terminology (See PCC TF-2: 5.1.1) of their choice. The requirements and manner in which implementations support such capabilities is beyond the scope of this Integration Profile.
Referral
All referral summaries shall be structured and coded as required by the Medical Summary Content Module. The inclusion of the specific coded attributes explicitly defined as optional, may be supported by specific implementations of Document Sources using an IHE identified coded terminology (See PCC TF-2: 5.1.1) of their choice. The requirements and manner in which implementations support such capabilities is beyond the scope of this Integration Profile.
Grouping with other Profile Actors
Content profiles may impose additional requirements on the transactions used when grouped with actors from other IHE Profiles.
Cross Enterprise Document Sharing, Media Interchange and Reliable Messages
Actors from the ITI XDS, XDM and XDR profiles embody the Content Creator and Content Consumer sharing function of this profile. A Content Creator or Content Consumer must be grouped with appropriate actors from the XDS, XDM or XDR profiles, and the metadata sent in the document sharing or interchange messages has specific relationships to the content of the clinical document described in the content profile. These are described in 3.7 Content Bindings with XDS, XDM and XDR above.
Notification of Document Availability (NAV)
A Document Source should provide the capability to issue a Send Notification Transaction per the ITI Notification of Document Availability (NAV) Integration Profile in order to notify one or more Document Consumer(s) of the availability of one or more documents for retrieval. One of the Acknowledgement Request options may be used to request from a Document Consumer that an acknowledgement should be returned when it has received and processed the notification.
A Document Consumer should provide the capability to receive a Receive Notification Transaction per the NAV Integration Profile in order to be notified by Document Sources of the availability of one or more documents for retrieval. The Send Acknowledgement option may be used to issue a Send Acknowledgement to a Document Source that the notification was received and processed.
Document Digital Signature (DSG)
When a Content Creator Actor of the XDS-MS Integration Profile needs to digitally sign a medical summary or any other documents in a submission set, it may support the Digital Signature (DSG) Content Profile as a Document Source.
When a Content Consumer Actor of the XDS-MS Integration Profile needs to verify a Digital Signature, it may retrieve the digital signature document and may perform the verification against the signed document content.
Security Considerations
The XDS-MS Integration Profile assumes that a minimum security and privacy environment has been established across all participants. There must exist security policies regarding the use of training, agreements, risk management, business continuity and network security that need to be already in place prior to the implementation of XDS-MS.
The IHE ITI ATNA Integration Profile is required of the actors involved in the IHE transactions specified in this profile to protect node-to-node communication and to produce an audit trail of the PHI related actions when they exchange messages.
In addition, the IHE ITI DSG Integration Profiles can be applied to the actors involved in the transactions specified in this profile to securely identify individuals involved in transactions and verify document integrity and authorizations (DSG).
Interested parties should also read the detailed Security Considerations sections provided for each of the aforementioned profiles in the IHE ITI Technical Framework and its supplements.
The XDS-MS profile does have a few security considerations of its own.
EMR systems should be thoughtfully designed so that providers are able to review and verify information before it is imported into their EMR system, and that positive user acknowledgements are made before import, and audit trails are recorded when imports occur.
Imported information should be traceable both to the source [the sharing EMR], and the receiver that accepted it into the EMR system. XDS Affinity domain policies should support policies and procedures for tracing information flows between EMR systems.
Because the information being transferred is in XML, it will be common that different EMR systems utilize different transformations to render the contents into human readable form. A Content Creator should make available the transforms used by the sending provider to review the documents, and a Content Consumer must support rendering the information as seen by the sending provider, allowing both providers to see what was sent in its original rendered form.