FHIR International Patient Summary
0.0.1-current - ci-build
FHIR International Patient Summary
0.0.1-current - ci-build
FHIR International Patient Summary, published by IHE Patient Care Coordination Committee. This guide is not an authorized publication; it is the continuous build for version 0.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/PCC.FIIO/ and changes regularly. See the Directory of published versions
This IPS profile uses the Health Level 7's FHIR International Patient Summary (IPS) that realizes the CEN EN 17269 IPS dataset to profile additional implementation options that can be incorporated into the IPS document. This is a Content Module profile that defines these additional Implementation options.
This section defines the actors, transactions, and/or content modules in this implementation guide. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at https://profiles.ihe.net/GeneralIntro/.
The actors in this profile are described in more detail in the sections below.
The IPS Content Creator creates the FHIR IPS Content, FHIR IPS ODH, or FHIR IPS Complete in accordance to the Implementation option selected. The IPS Content Creator then shares it using one of the methods defined in the IHE Document Sharing Health Information Exchange.
The IPS Content Consumer consumes the FHIR IPS content, FHIR IPS ODH, or FHIR IPS Complete in accordance to the Implementation option selected. The IPS Content Consumer obtains the IPS document using one of the methods defined in the IHE Document Sharing Health Information Exchange.
Options that may be selected for each actor in this implementation guide, are listed in Table XX.2-1 below. Dependencies between options when applicable are specified in notes.
Table XX.2-1: Actor Options
| Actor | Option Name |
|---|---|
| Content Creator | HL7 FHIR IPS Option |
| Complete Option | |
| Occupational Data for Health Option | |
| Content Consumer | View Option |
| Document Import Option | |
| Section Import Option | |
| Discrete Data Import Option | |
| Complete Discrete Data Import Option |
Note 1: The Content Creator must be able to support at least one of these options. Note 2: The Content Consumer must implement at least one of these options.
This option defines the processing requirements placed on the Content Creators for producing a FHIR document version of the International Patient Summary defined by HL7's FHIR IPS Implementation Guide. This Included the requirement to implement and support all Section and entry data elements defined as Must Support. These Details can be found in the HL7 FHIR IPS Bundle and HL7 FHIR IPS Composition structure definitions.
The following sections Must always be present. If the system does not support the collection and storage of this content, the appropriate flavors of null SHALL indicate such. Mandatory:
The following sections are expected to be included in an HL7 FHIR IPS Document if the system supports the collections and storage of the content. Must Support:
The Following sections are optional in the implementation of HL7's FHIR IPS Document. Optional:
This option defines the International Patient Summary modeled by HL7, where all of the optional sections(e.g., Advanced Directives, Functional Status, History of Past Illnesses, History of Pregnancy, Plan of Care, Social History, and Vital Signs) will become Must Support sections. The processing requirements placed on the Content Creators for producing a Complete FHIR IPS Document is detailed in the IPS Complete Option. This option specifies that the following sections defined as optional in the HL7 FHIR IPS Composition Have a New optionality of Must Support. This applies to the following sections:
Content Creators implementing this option shall create Occupational Data for Health information that complies with the Occupational Data for Health IG as entries to the Social History Section. The details are defined in the ODH Option.
This option stipulates that the Social History Section has the new optionality of Must Support. Minimally, a system claiming the Occupational Data for Health Option SHALL include an entry for Usual Work of Past Or Present Job, or Both. If the system collects any of the following work observations, these shall also be supported as Must Support:
Those data elements are defined in the Occupational Data for Health IG.
The Content Consumer implementing this option shall be able to discretely import all relevant content provided by the Content Creator as defined by the IPS Complete Option.
There are no Actor Groupings for this profile.
This profile describes how to use the HL7 FHIR IPS to support multiple international use cases, allowing for testing and deployment in commercial products for expanded implementation options.
Patients that are traveling to other jurisdictions may be seeking care or in need of care during their travel. The listed use case scenarios describe a variety of care needs that can be supported by implementation options in this content profile.
This Use case describes unscheduled emergency care of a patient where the healthcare provider is able to access an on demand HL7 IPS Document from an HIE.
A person has gotten into a motor vehicle accident and Emergency services are called to care for them. When the emergency care team arrives at the patient's side, they are able to use the information available on their identification to query their HIE for an on demand IPS document. With the summary available, information on the patient's sever allergy to NSAIDs and antibiotics are noted and their history of Stroke and blood thinners are utilized to make immediate treatment interventions. The patient is transported to the local hospital to continue care. The treatment interventions, assessments, and administered medications can be made available for the next provider.
HIE Replated retrieval of patient summary, single source/ on demand… incorperate the iti register ondemand doccument transaction into process flow ITI-61 TODO - plantuml diagram development
Pre-conditions:
Main Flow:
Post-conditions:
Represents how some systems should represent missing data for required if known section in the IPS documents that are generated due to limitations of the system.
A patient arrives at a treatment clinic that is looking for their patient history information. The patient provides portal information when being seen by a provider with a link to their primary provider portal. It generates an IPS for the reviewing provider, for informed care and treatment. The patient's provider portal is limited and does not have access to procedure, device, or Lab data. when the IPS is generated, those sections are labeled No information available tags. The receiving provider sees this and knows that they may need to utilize a different resource to collect this data on the patient and is informed that there is a gap in their data.
Query to database by portal actor, return Data but not returning information for labs, devices, and procedure due to unavailable data. Content creator generates the IPS document with those sections present and “not available” documented in the section’s Data absent Reason.
Pre-conditions:
Main Flow:
Post-conditions:
This use case describes a scheduled, cross border care scenario, with the Occupational Data for Health Option.
A 43-year-old woman is assigned to train personnel in another country to demonstrate use of a polyurethane foam product in hospitals. After 4 months, she develops respiratory symptoms and is found to have new-onset asthma. The attending clinician reviews her IPS that implements the Occupational Data for Health Option, which includes information about her new job. The clinician infers the causal link between the new work and the asthma and recommends changes in her job activities.
Pre-conditions:
Main Flow:
Post-conditions:
This use case describes how a patient can request the generation of an IPS and mask a portion of the data for personal privacy reasons and contribute to some of the data displayed.
A patient is preparing their personal Health Summary in case it is needed for their care. They are in the third trimester of their pregnancy and has recently been diagnosed with preeclampsia and is preparing for any emergencies ahead. They access their patient portal and generate an IPS. When reviewing the IPS, the patient makes sure that the preeclampsia and birth plan are flagged, lab results, adds some of the over the counter medication that isn't a part of the record, and adds some more information into the Patient Story section to provide more information and personal concerns that providers should be aware about the pregnancy. When these edits are completed, the patient finishes the generation of the IPS, ready to make available when it is needed for future care.
Query to the provider database, the content consumer is the patient portal. Patient reviews the record. Adds patient Story narrative, adds pregnancy test result, over the counter medication she is taking, flags birth plan?, and masks conditions related to her mental health diagnosis for privacy. Then triggers the portal system to generate the IPS as a content creator. IPS document generated and cloud share to other provider system.
Pre-conditions:
Main Flow:
Post-conditions:
In this use case, an IPS document is created by a care Provider. This use case highlights the provider’s decision to include only relevant content in the IPS document and the use of multiple sources for an On Demand Document.
In some jurisdictions (e.g. France, others) there is funding available to care Providers to cover the cost of regularly preparing a patient summary document for their patients. It is typically expected that such a document will be leveraged to support cross-border care delivery as described in other use cases. In the development of a Provider-mediated IPS, the patient’s health data content is curated by the Provider, whose judgement is used to answer the question: “what is the health data relevant to supporting the patient’s (likely unplanned) care?”
A patient with cancer has indicated to their provider that they will be spending several months outside of the country and has requested that a summary be available to them in the event that unplanned care takes place. Due to the complexity of their condition the provider generates an IPS document reflecting the current health information and relevant conditions, medications, labs, results, and imaging are available in the record, for informed care of the patient and their condition. The results section is ensured to contain the relevant pathology and imaging results relative to the patient’s cancer. The IPS is stored somewhere until it is needed. While the patient is on their trip, they have an unplanned visit to the local Health clinic with concerns that it is related to their cancer. Their IPS document is made available to the provider that is seeing to their care, and it is able to inform the care of the patient as they investigate any linkages this condition has to their chronic condition.
Pre-conditions:
Main Flow:
Post-conditions:
The use case describes the use of the standard IPS format for patient summary data to convey de-identified study data content from the primary care environment for secondary use purposes. This use case reflects the Complete Option for testing.
The permitted purpose for this example is Public Interest research in Public/Occupational Health to study co-morbidities, mortality, occupational risks, and treatment effects. The dataset must be minimized and de-identified to preserve utility (longitudinal trends, outcomes, medication impacts) while controlling re-identification risk per permit conditions. In this fictitious use case, the region is under threat of outbreak for a novel virus causing influenza-like-symptoms. An approved public health monitoring program wishes to review primary health information from across multiple jurisdictions for impacts of co-morbidities, mortality rates, and occupational health risks. The study also intends to review the population health impact for medication treatments, including vaccination. The purpose of the research request reflects a permitted purpose of use, Public Interest in the area of Public, Occupational Health. Data for this study represents categories from Healthcare, Medicinal products, Areas of Public Health, Areas of Occupational Health, and possibly Serious cross-border threats.
TODO: connect the plantuml for this use case IPS-Secondary-Access-Use-Case
Pre-conditions: Before the research data can be de-identified and shared, the Researcher conducts data discovery to identify data that is available for the study, and an application for a data permit is submitted and approved according to the region’s policy for secondary use. The Health Data Access Body (HDAB) determines that the information is available within the HDAB Information Resources, indicating data is available in a standard International Patient Summary (IPS).
Main Flow: The Patient data for the research cohort is extracted from the primary care use environment using the standard IPS format. At this stage, the data is under the control of the Health Data Access Body, which may be the care provider, a formal data access body, or a trusted third party.
Post-conditions: The Researcher has retrieved or received the de-identified research study data in the standard IPS format.
See ITI TF-2x: Appendix Z.8 "Mobile Security Considerations"
Consider the ISO 22857:2013 Health informatics — Guidelines on data protection to facilitate trans-border flows of personal health data for trans-border information exchange security considerations. 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.
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.
Health Information Exchange: Enabling Document Sharing Health Information Exchange Using IHE Profiles White Paper IHE Document Sharing Health Information Exchange.
The use of the IHE XD* family of transactions is encouraged to support standards-based interoperability between systems acting as the IPS Content Creator and IPS Content Consumer. However, this profile does not require any groupings with ITI XD* actors to facilitate transport of the content document it defines.
A Document Source in XDS.b, a Portable Media Creator in XDM, or a Document Source in XDR might be grouped with the IPS Content Creator. A Document Consumer in XDS.b, a Portable Media Importer in XDM, or a Document Recipient in XDR might be grouped with the PCS Content Consumer. A registry/repository-based infrastructure is defined by the IHE Cross Enterprise Document Sharing (XDS.b).
The On-Demand Documents Option of the XDS.b Profile may be considered or required by local implementations to assure summary documents include a composite summary of information for the patient.
XDW may be used to define workflow for international patient care management of trans border patient care using Cross-Enterprise Document Workflow Content Profile to manage and track the tasks related to patient-centric workflows.
A reliable messaging-based infrastructure is defined by the IHE Cross Enterprise Document Reliable Interchange (XDR) Profile. A Document Source in XDR might be grouped with the IPS Content Creator. A Document Recipient in XDR might be grouped with the IPS Content Consumer.
Detailed descriptions of these transactions can be found in the IHE IT Infrastructure Technical Framework.
IG © 2021+ IHE Patient Care Coordination Committee. Package ihe.pcc.fiio#0.0.1-current based on FHIR 4.0.1. Generated 2026-02-04
Links: Table of Contents |
QA Report
| New Issue | Issues
Version History |
|
Propose a change