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

Short Description

Patient Access apps will be developed internationally. Make sure your API conforms to the expectation of the clients! Test your client against many different international patient access APIs!

Long Description

International Patient Access (IPA) defines a minimal, base set of FHIR profiles specifically intended to be used as-is, or built on top of by countries looking to enable patient access and patient-facing apps accessing data via RESTful FHIR. In addition to profiling a minimal set of FHIR resources, this IG also specifies the use of SMART on FHIR for authentication and authorization.  Consider using this implementation guide as a foundational building block for national or regional FHIR base or patient access specifications, or for multi-national applications and FHIR servers.  The specification also defines the required and recommend RESTful interactions include search parameters.

During this Connectathon we continue validating the current specification and discussing and exploring future developments.

Specifically, we intend to

  1. Validate the specification with both server and client implementations.
  2. Continue comparing IPA against known national and regional FHIR base profile specifications.
  3. Strengthen cooperation and bindings between IPA and IPS (International Patient Summary).
  4. Discuss future developments.


Type

Test an Implementation Guide

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

Patient Care

Track Lead(s)

Mikael Rinnetmäki, mikael@sensotrend.com

Track Lead Email(s)

mikael@sensotrend.com

Related Tracks

2022-05 International Patient Summary

FHIR Version

Current build, FHIR R4


Specification(s) this track uses

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

Artifacts of focus

Expected participants

We anticipate adoption of this specific specification by national regulators. More generally, the implementation guide is a subset of multiple pre-existing national-scale FHIR base or patient access specifications. We hope several implementations (both servers and clients) currently targeting any of the national-scale specifications to join and test their implementations against the specification and each other. Last track had around 50 participants, we expect about the same number this time.

Zulip stream

https://chat.fhir.org/#narrow/stream/261969-IPA/

Track Kick Off Call

Monday, May 2, 3 PM to 4 PM ET, just before the full connectathon kick off call!

Agenda

  • Kick-off May 2, 3 pm to 4 pm (just before the connectathon kick off)
  • Checkpoint 1, May 3, 2 am
  • Checkpoint 2, May 3, 9 am
  • IPA / IPS joint session, May 3, 2 pm - 3 pm
  • Checkpoint 3, May 3, 3 pm
  • Checkpoint 4, May 4, 2 am
  • Checkpoint 5, May 4, 9 am
  • IG Status Update May 4, 10 am to 11 am
  • Occupational Data for Health (ODH) and IPA, May 4, 11 am
  • Reporting, May 4, 3 pm

Track Details

Signup

  • Subscribe and introduce yourself on #IPA
  • Add yourself to the sign-up sheet! Just name and email are enough to get started, but please add any additional info when you have it.
  • Include information on app or server you're testing, or profiles you're working with.



System roles

app

a SMART on FHIR patient-facing native or web application

server

a FHIR server compatible with draft IPA profiles and specification

Test scripts in Inferno

We expect to have detailed and formal test scripts in the Inferno testing tool for the connectathon. The scenarios below are also available for less formal testing.

Server Scenarios


Scenario Step 0: describe client registration method

Action: Share a link to documentation where client implementers can find out how to talk to your server. Does the client need to be registered? How can this be performed? Is dynamic client registration supported?

Precondition: Success Criteria: Information on client registration published as part of the track's work space.

Success Criteria:  At least one client successfully registered.

Bonus point: Dynamic registration mechanism. 

TestScript(s): None.

Security and Privacy Considerations: Different servers will have different requirements. We're eager to learn what these are and whether there is any harmonization across implementations.


Scenario Step 1: SMART app launch

Action: A registered SMART app initiates a stand-alone launch.

Precondition: Success Criteria: the app is registered.

Success Criteria:  The app gets at least an access token through the launch.

Bonus point: SMART v2 launch support (see the 2022-01 SMARTv2 track).

TestScript(s): None.

Security and Privacy Considerations: None.


Scenario Step 2: serve a Patient resource

Action: A registered SMART app queries for the Patient resource, based on the launch response.

Precondition: Success Criteria: successful app launch

Success Criteria:  the app gets the right Patient resource

Bonus point: selection of the Patient as part of the launch process ("acting on behalf of" case).

TestScript(s): None.

Security and Privacy Considerations: None.


Scenario Step 3: serve a default DocumentReference resource with the $docref operation

Action: A registered SMART app queries the $docref resource

Precondition: Success Criteria: successful app launch

Success Criteria:  the app gets the right DocumentReference resource

Bonus point: construct the resource dynamically

TestScript(s): None.

Security and Privacy Considerations: None


Scenario Step 4: serve a specific DocumentReference resource with the $docref operation

Action: A registered SMART app queries the $docref resource, indicating a profile

Precondition: Success Criteria: successful app launch

Success Criteria: the app gets the right DocumentReference resource

Bonus point: meaningful error message when a non-supported profile is queried

TestScript(s): None.

Security and Privacy Considerations:


App Scenarios


Scenario Step 0: client registration

Action: Register the client to one or more servers available on the track.

Precondition: Success Criteria: Either a public or confidential SMART capable FHIR app.

Success Criteria:  Client registered to at least one server present on the track.

Bonus point: Dynamic registration mechanism. Registered with multiple servers.

TestScript(s): None.

Security and Privacy Considerations: Different servers will have different requirements. We're eager to learn what these are and whether there is any harmonization across implementations.


Scenario Step 1: SMART Launch

Action: Once registered, initiate a stand-alone launch.

Precondition: Success Criteria: The app is registered with the server.

Success Criteria:  The app gets at least an access token through the launch.

Bonus point: SMART v2 launch support (see the 2022-01 SMARTv2 track).

TestScript(s): None.

Security and Privacy Considerations: None.


Scenario Step 2: fetch the Patient resource

Action: Once launched, fetch the Patient resource .

Precondition: Success Criteria: Successful SMART stand-alone launch.

Success Criteria: The app gets the right Patient resource.

Bonus point: 

TestScript(s): None.

Security and Privacy Considerations: None.


Scenario Step 3: fetch the default DocumentReference resource

Action: Once launched, use the $docref operation to get the default DocumentReference resource.

Precondition: Success Criteria: Successful SMART stand-alone launch.

Success Criteria: The app gets a valid DocumentReference resource.

Bonus point:

TestScript(s): None.

Security and Privacy Considerations: None.


Scenario Step 4: fetch a specific DocumentReference resource

Action: Once launched, fetch a DocumentReference resource of a specific type with the $docref operation.

Precondition: Success Criteria: Successful SMART stand-alone launch.

Success Criteria: The app gets a valid DocumentReference resource of the right type.

Bonus point: Test searching for a DocumentReference resource with an unsupported (or non-existent) type, fail gracefully.

TestScript(s): None.

Security and Privacy Considerations: None.