Resource Profile: IPA-Patient

Header Header Header
content content content
content content content

Minimum expectations for a Patient resource when accessed via a International Patient Access API. This profile describes how applications fetch the Patient resource to check the patient identity and access basic demographics and other administrative information about the patient.

Mandatory and Must Support Data Elements

The following data elements must always be present (in other words, mandatory resource properties where the minimum cardinality is 1) or must be supported ( Must Support definition). Servers cannot restrict access to mandatory elements when authorizing an application. However, servers may choose to provide additional information or may be required to do so by national or other profiles that apply to the server’s context.

STU Note


This specification is currently published as a Standard for Trial Use (STU). Feedback is welcome and may be submitted through the FHIR change tracker indicating "International Patient Access (FHIR)" as the specification. The publishers of the specification are seeking feedback on two elements in this Patient profile.
  1. Currently, the Patient.identifier element is identified as mandatory. The intent is that all servers must provide a unique patient identifier that can facilitate a federated approach to accessing patient information. Please provide any evidence for or against this decision.
  2. In the balloted version of this specification, the Patient.name element was identified as mandatory (meaning minimal cardinality of 1) and provided a rule that the use of the Data Absent Reason (DAR) extension was allowed. In this published version, Patient.name is not mandatory. It was expressed that having the minimal cardinality of 1 may not enable privacy preserving mechanisms, such as patients limiting client application access to their demographic information, including name, as part of the authorization process. Implementer feedback is requested on whether Patient.name should be a mandatory element.

ocean A link.

Each Patient SHALL have:

  • a patient identifier (e.g. MRN)

Applications must also support:

  • a patient name
  • an administrative gender (note: this is for administrative purposes; see link
  • an active flag (It SHALL be present if patients links are present)*
  • Birth date
  • Patient Link*
    *See guidance below

Profile Specific Implementation Rules and Guidance

During the Authorization process, the user and the Authorization service fixes the patient record to a single individual patient. For safety, client applications should specify the patient id when searching other resources.

The client application SHALL be capable of accessing the patient record using the following API call: