IPA Patient Profile

Resource overview

Almost all overview tabs of any resource can be rendered in your Implementation Guide. StructureDefinitions have their own tree statement for this, other resources use the render statement.

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.

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 note about Patient Gender and Sex for discussion)
• 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:

GET [url]/Patient/[id]

The client application MAY use these search parameters that servers are required to support to access the patient record:

• _id
• identifier