Short Description

This track will test the creation, exchange and visualization of patient summary data across jurisdictions and usage contexts using the FHIR International Patient Summary (IPS) Implementation Guide specification. It will also track and test changes included in the most recent publication of the IPS (STU 1.1). 

Long Description

This track will test the creation, exchange and visualization of patient summary data across jurisdictions and usage contexts using the FHIR International Patient Summary (IPS) Implementation Guide specification.  The track will focus on the primary theme of cross-border IPS document bundle data exchange. This will support initiatives by the Joint Initiative Council (JIC) on IPS (See http://jointinitiativecouncil.org/projects/ips.asp) and also nations participating through the Global Digital Health Partnership (See https://gdhp.health/). Any organization within any country is invited to participate.  

Several themes will be advanced as part of the track including: 

  • Pilot implementations of multiple jurisdictions (e.g., GDHP) for cross-border IPS document bundle data exchange
  • Test implementation of proposed Patient resource $summary operation (See https://build.fhir.org/ig/HL7/fhir-ips/OperationDefinition-summary.html)
    • Can generate an IPS instance for a patient based on existing data and a set of rules
    • Rules can be server-defined (default) or specified by parameter
    • Need to answer the “relevant” question for what data to include
    • Need to refine what narrative text is included in IPS and how that text is linked to machine-readable resources
  • Enhanced IPS instance testing leveraging available testing suites
    • The Inferno testing tool (ONC/MITRE) https://inferno.healthit.gov/
    • Use of the HL7/ONC developed reference implementation server: https://ips.health/
    • The Gazelle testing tool suite (used in common with the IHE North American and European Connectathons) (optionally, as available)
    • One or more FHIR server(s) for demonstrating and testing IPS data exchange
  • Examine the relationship between IPA (International Patient Access) and IPS
  • Optional: Transform IPS data to a WHO DDCC:VS vaccination certificate document including the EU DCC, Smart Health Cards, and DIVOC QR code specifications.

General track goals include:

  • Promote the sharing of experiences
  • Identify tools and resources for IPS examples and validation
  • Identify gaps and pitfalls in the IPS adoption

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.

Type

Test an Implementation Guide

Related Tracks?

International Patient Access

Vulcan Real World Data (RWD)  

Call for participants

  • Personal Health Record (PHR) and Electronic Health Record (EHR) vendors
  • Implementers and consultants involved in regional adaptation of IPS (e.g. PS-CA in Canada, NZIPS in New Zealand, etc.) 
  • Health information exchanges

Track Prerequisites

Track Lead(s)

John D'Amore, Rob Hausam

Track Lead Email(s)

johnd@moreinformatics.com rob@hausamconsulting.com 

Specification Information

https://build.fhir.org/ig/HL7/fhir-ips/

Prior connectathon track: 2022 - 09 International Patient Summary

Zulip stream

https://chat.fhir.org/#narrow/stream/207835-IPS

Agenda (and Track Kick off Call)

Pre-Connectathon Track Kick-off / Track Orientation:

Working Agenda: 

Connectathon Discussions

  • IPA-IPS Joint Session: Saturday (Jan 14 2023) 2pm local time (PT). 
  • Potential to have discussion/breakout around $summary (and possibly $docref) operations and how they should accept parameters to modify expected output (e.g. new sections/resources). Sheridan Cook may be potential leader of discussion
    • Start by collectively defining the requirements for what we'd like to accomplish with the updated operation (e.g., pass it additional resource requests as an input in a way that the server can detect and apply with minimal effort), come up with a handful of test cases (e.g., request FamilyMemberHx resources be included if available, request Encounters be included if available) brainstorm and test whether we can accomplish this with GraphQL or other means (both $summary and $docRef) and discuss the pros/cons of each with participating vendors, and then incorporate any decided changes into at least one participating server and test whether it has the desired effect. Depending what we find - we update the documentation accordingly and ideally get to include it in the IPS CI Build and other specifications
  • Potential to have cross-track discussion with RWD track. 

System Roles

  • Generator of IPS
  • Consumer of IPS
  • Document Processor of IPS

Testing Scenario:

System roles:

Generator of IPS documents (such as personal health records, health information exchanges or electronic health records)
Receiver of IPS documents

No advance preparation is specifically required, although reviewing the implementation guide and examples of IPS samples will be helpful (https://github.com/jddamore/IPSviewer/tree/main/samples)


Roles & Scenarios

IPS Document Creator

Creates or updates 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. 

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.

IPS Document Processor

Uses a FHIR IPS document and/or individual component resource instances for the purpose of creating/updating other kinds of IPS based documents as for example
vaccination certificate.


Action:

Precondition: Success Criteria: 

  • Usage of tools to validate IPS conformance
  • Usage of tools to visualize IPS content 

Success Criteria:  

  • Conformant IPS documents that validate without errors
  • Successful visualization of IPS documents
  • Advancement and feedback on the implementation guidance

Bonus point:

TestScript(s):

No test scripts at this time. 


Security and Privacy Considerations:

No plans to test security at this time. Privacy and confidentiality are within scope for discussion.