Page tree
Skip to end of metadata
Go to start of metadata

Track overview

Short Description

This track will test the creation and exchange of patient summary data across jurisdictions and usage contexts using the FHIR International Patient Summary (IPS) Implementation Guide specification.  A current highly relevant application is the creation and exchange of COVID-19 laboratory results and related clinical data (symptoms, pre-existing conditions, SDH, etc.).

Long Description

This track will test the creation and exchange of patient summary data across jurisdictions and usage contexts using the FHIR International Patient Summary (IPS) Implementation Guide specification.

In this phase, one of the intents of this testing activity, beyond exercising technically the IPS IG, is to:

  • promote the sharing of experiences.
  • identify gaps and pitfalls in the IPS adoption.
  • discuss how the IPS can be used to support some current highly relevant application as the creation and exchange of COVID-19 laboratory results and related clinical data (symptoms, pre-existing conditions, SDH, etc.).

In this sense an open approach will be followed, expecting attendees to actively participate in the selection and definition of the tests to be performed and topics to be discussed, beyond those suggested by the track leaders.

Possible goals may be:

  • identify, discuss, and evaluate possible issues and gaps in the current specification
  • exercise, analyze and discuss different IPS workflow pathways, including, but not limited to:
    1. IPS created based on resources all owned by the FHIR server Vs not-all owned by the FHIR server
    2. IPS generated on the fly by using the $document operation Vs IPS submitted as a bundle
    3. IPS retrieval by querying DocumentRefernces Vs Composition Vs Bundle
    4. Query of resources (e.g. Immunizations; Lab results) included in the IPS
  • Investigate the conversion / use of existing data (e.g. FHIR US core resources; EU CDA eHDSI Patient Summaries; FHIR GECCO or Logica profiles resources) for generating IPS or extracting data for other purposes.
  • Evaluate how to support display and or text translation, also using FHIR terminology services

Type

  • Test an Implementation Guide

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group

Patient Care WG (IPS Project)

Proposed Track Lead

Rob Hausam, rrhausam@gmail.com

Giorgio Cangioli, giorgio.cangioli@gmail.com

Related tracks

2020-09 COVID-19 In-Person Pre-Arrival Clinical Workflow

2020-09 Situation Awareness for Novel Epidemic Response DRAFT

2020-09 FHIR Mapping Language Track

FHIR Version

  • FHIR R4

Specification(s) this track uses

http://hl7.org/fhir/uv/ips/index.html

Artifacts of focus


Clinical input requested (if any)

Clinical input regarding COVID-19 related data will be useful.  Clinical participation is encouraged and always welcomed.

Patient input requested (if any)

A patient perspective is always welcome (e.g. health considerations during international travel during the current pandemic).

Expected participants

Giorgio Cangioli 

Robert Hausam

Francois Macary

Christof Gessner

Robert Scanlon(MITRE Inferno team)

Michael O'Keefe (MITRE Inferno team)

Ian Bacher (openMRS)

Simon Gerrard

Alex Kontur (ONC)

Chris Melo (Philips)

Bett Kipchumba (openMRS)

Carlo Mataverde (eHealth NSW)

Vamsee Karanam

John Moehrke

Zulip stream

IPS Zulip stream (multiple topics)

Track Orientation

We invite interested participants to join the weekly IPS calls on Wednesdays from 11:00 AM to noon Eastern (https://global.gotomeeting.com/join/399580637).

Link to track orientation recording from IPS call 2020-09-09.

Track details

System Roles


Role 1 Name


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 and/or individual component resource instances created by the Document Creator from the FHIR server and does one or more of the following: a) validates the document and/or component resource instances against the IPS Clinical Document profile, b) displays the document and/or discrete data components 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.

Scenarios

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.

The following scenarios describes few of the many situations that can be realized and tested:

  1. Create and submit an IPS document bundle (bundle end point)

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 component resources containing the summary clinical data.

User then POSTs the document to a FHIR server, by using the bundle end point.

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.

  1. Create and submit an IPS document bundle (base end point)

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 component resources containing the summary clinical data.

User then POSTs the document to a FHIR server, by using the base end point.

Precondition: used resources are not

Success Criteria: all of the resources that the IPS bundle contains are processed as individual resources. Consumer 4 can ask to generate a new IPS bundle by using the $document operation.


  1. Submit an IPS composition and retrieve the IPS by using the $document operation

Action:

  • 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 (persistent option) on the Composition to get a full document Bundle back,

Precondition: all referenced resources are owned by the FHIR server generating the IPS

Success Criteria: The IPS Bundle is successfully generated and made persistent by the FHIR server.

  1. Display an IPS document and/or individual component resources

Action: User retrieves an IPS document and/or discrete component resources from the FHIR server and displays the data in a web browser (or by other means).

Precondition: An IPS document exists on the target FHIR server.

Success Criteria: Document is successfully displayed.

  1. Translate (or Map) the narrative and coded data

Action: the consumer retrieves an IPS (or some of the used resources) and possibly using FHIR terminology services translate the narrative and coded data into different language(s) for display or to other code systems appropriate for different jurisdictions.

Precondition:

Success Criteria: a translated display for a codeable element, or a code mapped into another code systems appropriate for different jurisdictions is shown.

TestScript(s)

No test scripts have been defined at the present time.

Security and Privacy Considerations

No specific security expectations have been identified or defined at the present time.


Track Report Out (draft)

Summary

This track aimed to test the creation and exchange of patient summary data across jurisdictions and usage contexts using the FHIR International Patient Summary (IPS) Implementation Guide specification.

Participants

Several participants joined the IPS track mainly to learn more about the IPS, to discuss about IPS related topics and to observe the track. Hereafter an incomplete list of the attendees: Robert Scanlon(MITRE Inferno team); Michael O'Keefe (MITRE Inferno team); Ian Bacher (openMRS); Simon Gerrard ; Alex Kontur (ONC); Chris Melo (Philips); Bett Kipchumba (openMRS); Carlo Mataverde (eHealth NSW); Vamsee Karanam; John Moehrke; Christopher R Burrow (humetrix); Francois Macary; Christof Gessner; Robert Hausam; Giorgio Cangioli and others joined the IPS track.

Systems involved and actions performed


The Mitre Inferno team was mainly engaged in the IPS track aiming to support the IPS Validation by using the Inferno tool and upgrading the Synthea tool for generating IPS syntetic data, by converting US core resources to create IPS bundles.

IPS samples collected before the connectathon have been used to exercise the validation and evaluate IPS posting and querying alternatives.

Notable achievements

  • The validation of IPS by using the inferno tool has been exercised.
  • Increased the awareness about the IPS.
  • Discussed IPS implementation issues with people not involved with the IPS IG development.
  • Identified some validation issues. (see below)
  • Evaluated different IPS 'posting' (Bundle end point Vs base end point) and querying (e.g. search Bundle per patient ID ; per document type) mechanisms.

Discovered issues / questions 

Now what?

  • Follow up the progresses of the Inferno validation tool
  • Suggest improvements for the current FHIR validator
  • Collect more examples to better exercise the IPS validation
  • Continue the conversation about FHIR server desired capabilities; validation policies and on-demand versus human curated IPSs
  • No labels