201809 International Patient Summary
International Patient Summary
This track will test the creation and exchange of FHIR International Patient Summary (IPS) documents (using a document Bundle resource containing a Composition and other supporting resources). We anticipate working closely with the FHIR Documents track.
Submitting WG/Project/Implementer Group
- Structured Documents WG
- FHIR Product Director
- IPS Project
The updated FHIR R4 version of the International Patient Summary (IPS) is being balloted in the September cycle (http://hl7.org/fhir/uv/ips/index.html). The primary use case envisioned for the IPS specification is the cross-border, unscheduled care of a patient. The Connectathon in Baltimore provides an opportunity for initial implementation and testing of this specification. We intend to build on the initial efforts on this which were made with the STU3 version of the IPS specification during the May Connectathon in Cologne, and we hope to further integrate and coordinate with the Clinical Documents track and work further on current and planned future alignment with the Argonaut specification.
Proposed Track Lead
- Rob Hausam
- Francois Macary
- Others TBD
IPS Document Creator
Creates a FHIR IPS document (Bundle containing a Composition and supporting resources) from source data. The source data likely will be existing data on a FHIR server, but this can be done using whatever means are appropriate, including manual creation, assembling documents from other resources, transforming from a CDA IPS document, etc. Submits that document to a FHIR server. Optionally a document creator may digitally sign the document (but this is not expected at this time).
IPS Document Consumer
Retrieves a FHIR IPS document created by the Document Creator from the FHIR server and does one or more of the following: a) validates the document against the IPS Clinical Document profile, b) displays the document in a browser (or by other means), c) translates the coded and/or narrative data to a different language for display, or d) translates the coded data to different code system(s) used in a jurisdiction that is different from the source.
For all scenarios below, participants are expected to provide their own content for the documents (obviously nothing with PHI should be used at a public Connectathon). If participants don't have readily available content, they are encouraged to create documents that mimic the content in IPS or other patient summary sample files.
1. Create an IPS document
- Action: User creates a FHIR IPS document consisting of a Composition resource with narrative sections, bundled with Patient (Composition.subject) and Practitioner (Composition.author) and the additional supporting resources containing the summary clinical data. User then POSTs the document to a FHIR server.
- Precondition: none, but existing resources may be used.
- Success Criteria: Bundle is successfully submitted to a FHIR server. Consumer in Scenario 4 can display the document and render all attested content.
- Step 1: Create a Composition resource
- Step 2: Ensure the subject, author, and custodian references point to valid Patient, Practitioner, and additional clinical resources .
- Step 3: POST the Composition to a FHIR server
- Step 4: Check the operation outcome to ensure it was successful
- Step 5: Call $document on the Composition (if supported by the server) to get a full document Bundle back, or create the Bundle through other means (custom code, etc.)
2. Display an IPS document
- Action: User retrieves an IPS document from the FHIR server and displays it in a web browser (or by other means).
- Precondition: An IPS document exists on the target FHIR server.
- Success Criteria: Document is successfully displayed.
3. Translate the narrative and coded data into different language(s) for display or to other code systems appropriate for different jurisdictions (as in IPS Document Consumer c, d above).