Note: Illustrative flow and content is adapted from the International Patient Access Specification ... significant extension and adaptation will be required.

Finding and Retrieving Information

Once an application has obtained access to the patient record with a SMART on FHIR access token, it can find and retrieve information about the patient from the FHIR endpoint.

Patient Identity Check

The IPA specification recommends that the first thing the application should do after gaining authorization to an endpoint is to retrieve the patient record it has obtained access to and confirm that it is about the right patient.

GET [url]/Patient/[id]

This read returns a single FHIR Patient resource. The details in the patient record should match what the user of the application is expecting. The application chooses how to check this, though some jurisdictions may make additional rules about how it is done. If the app suspects it has been incorrectly granted access, consider: informing the resource server owner, aborting the workflow without showing data to the current user, and looking to local jurisdictional policies for guidance.

Notes:

  • A user may grant access to their or another patient’s record (e.g., a family member or other patient for whom the user is an authorized representative).
  • Identifying the patient is a significant challenge - and safety issue, and the application should never take a correct match for granted. This step is an essential check if the client application is synchronizing its own copy of the patient record.
  • Jurisdictions may have applicable laws or regulations about displaying/checking this information in the application.

Fetching Patient Records

Once the patient identity is confirmed, the application can access the patient record by searching on a set of different resources, using this pattern:

GET [url]/Condition?[params]

or more generally,

GET [url]/[Resource]?[params]

Where “[Resource]” is the name of a resource taken from the table below, and the list of parameters includes the patient identifier. (See FHIR’s RESTful API for the details). Some of the lists returned from these calls will be relatively short, but some may be very long - potentially many thousands of resources for Observation and DocumentReference, for example.

Servers will generally use paging to manage requests for long lists of resources. Clients may use any of the search parameters documented below to narrow the scope of the search, and reduce the number of resources returned, except for the few search parameters documented clearly below, servers are not obliged to support search parameters. For this reason, clients should always check the self link on the search to see what parameters were processed (or consult the CapabilityStatement in advance to know which parameters are supported).

Note that servers may decline to perform some searches unless particular parameters are specified.

Retrieving $everything about a Patient (within authorized scope)

Implemented for trial use

POST: [base]/Patient/[id]/$everything

Use of the $everything operation has been proposed for use in combination with launch context on EMR systems to allow only a preselected subset of resources within the patient record as a Bundle of type searchset.

Open Questions:
  • Is $everything supported by existing EMR solutions / FHIR servers?
  • Is the ability for servers to limit $everything to a preselected list of resources feasible

    • Search for ServiceRequest.supportingInfo

    Proposed alternative

    GET: [base]/ServiceRequest?_include=ServiceRequest:supportingInfo

    As an alternative to above, it has been proposed that:

    • An EMR could associate relevant information selected by a user with a pending eReferral prior to launching an app.
    • Associate the corresponding FHIR resources with ServiceRequest.supportingInfo.
    • EMR passes the ServiceRequest.id as fhirContext in exchange for launch parameter when the access_token is retrieved by the app.
    • App uses RESTful search with _includes to return the ServiceRequest with all Resources referenced in .supportingInfo as a Bundle type SearchSet.

    Limitations:

    • FHIR does not provide a standard Search Parameter for ServiceRequest.supportingInfo.
    • Search parameters must be defined in this guide and deployed to the seerver.

    Supported Searches by Resource

    To be added