This page is part of the International Patient Access (v1.0.0: STU 1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Security and Privacy

Servers and clients SHALL follow the security requirements and SHOULD follow the security best practices as outlined in FHIR Security and elsewhere.

Patient Privacy

This specification depends on Smart App Launch which profiles an OAuth 2.0 authorization process, such that the user decides what access to grant to the application that they are using.

The application asks for the access it requires based on SMART App Launch Patient Scopes, either when the OAuth process is initiated, or when the application is registered. Other additional information may be collected during whatever registration process applies for the application.

Once a client launches the OAuth process, the Authorization server considers rules such as:

• Applicable laws and regulations
• Institutional policies and agreements
• Existing Patient consent agreements
• Application access request

Once the authorization server has determined what information the user has a right to access, it prompts the user to choose a subset of that the information they wish to share with the client application.

The Authorization server then returns a set of scopes to the application that describes what access the user has authorized. Clients need to be aware that the Authorization server cannot fully describe the access rules in the scopes and SHALL be prepared to handle failure gracefully.

• Servers are not required to support search functionality on Practitioner. If they do, it’s important to balance the privacy of healthcare workers with the patient’s access to information. Only information about the practitioners that relate to the patient is relevant.

• Servers MAY choose to inform a client when information is not available, but most servers will simply behave as if it doesn’t exist (see note in FHIR specification).

• This specification labels some elements as must-support. This does not override the patient’s right to decide whether to authorize an application to access their information.

Patient Safety

Accessing Patient records raises many questions about safety. Accessing the wrong patient records, missing correct records, displaying records incorrectly, or having non-authorized actors access records can potentially harm patients. The Implementer Safety Checklist page gathers clinical safety advice acquired from experience of accessing health records across FHIR APIs like this one. All implementers should carefully consider each of the items on the checklist. Getting these issues right is necessary, but more is needed to deliver safe patient applications.

Note that software can misinterpret health care records, potentially leading to dire consequences. However, this specification does not provide enough information about accessing records to support interpreting the content. Implementers must consult their country-specific guides for this.

Patient matching

When synchronizing a patient record, it’s important to match not just a pre-existing patient identifier but also patient demographics. Additional care should be taken for patient merge and un-merge scenarios.