This page is part of the International Patient Access (v1.0.0: STU 1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions
IPA conformant servers SHALL support:
This page documents how CapabilityStatements declare conformance to the IPA Profiles and their FHIR Interactions. It also defines the expectations for mandatory and must-support elements. The Gaining Access to a Patient Record page documents the SMART on FHIR obligations and capabilities.
Note that the FHIR Conformance Rules defines the conformance verbs - SHALL, SHOULD, MAY - used in this guide
The Artifacts page lists the IPA Profiles defined for this implementation guide. Core Profile StructureDefinitions defines the minimum elements, extensions, vocabularies, and value sets which SHALL be present when using the profile. Many Profile pages also contain additional guidance.
The Profile elements consist of both Mandatory and Must Support elements. Mandatory elements are elements with a minimum cardinality of 1 (min=1). The base FHIR Must Support guidance requires specifications to define the support expected for profile elements labeled Must Support. The sections below explain how these elements are displayed and define the rules for interpreting profile elements and sub-elements labeled Mandatory and Must Support for requesters and responders.
The International Patient Access Client CapabilityStatement outlines conformance requirements and expectations for the IPA Clients. This CapabilityStatement describes the basic rules for the International Patient Access client actor that initiates a data access request to and retrieves patient data from an IPA Responder. In addition, it lists the client conformance expectations for each resource type documented in IPA. These expectations include supported FHIR profiles, RESTful operations, and search parameters. International Patient Access clients define their capabilities by choosing from this list based on the resource types they need to access.
The International Patient Access Server CapabilityStatement outlines conformance requirements and expectations for the IPA Clients This CapabilityStatement describes the basic rules for the International Patient Access server actor that is responsible for providing responses to queries submitted by International Patient Access requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by International Patient Access servers are defined in this CapabilityStatement.
Note that country-specific profiles must define terminology bindings and invariants.
Servers that are conformant to the International Patient Access API declare conformance by:
The server hosts a capability statement at [url]/metadata that is available to both authenticated and unauthenticated clients and that declares that IPA is supported using CapabilityStatement.instantiates, as shown in the following fragment:
{
"resourceType": "CapabilityStatement",
...
"instantiates": [
"http://hl7.org/fhir/uv/ipa/CapabilityStatement/ipa"
],
...
"rest": [
{
"mode": "server",
...
}
]
}
Note that the CapabilityStatement may be different for authenticated and unauthenticated clients.
In FHIR, resources are exchanged in the following formats: JSON, XML, and Turtle. Due to the popularity of JavaScript-based apps and ease of usage with JSON, the most popular exchange format for REST-styled APIs is JSON. To increase certainty and the likelihood of interoperability, IPA mandates the support of JSON. IPA Servers are encouraged to support XML as well.
Systems deploy and support the IPA profiles to represent clinical information and the IPA RESTful interactions to access that information. Therefore, servers must implement and support IPA profiles and interactions to claim conformance to IPA.
Profile Support refers to the support of the IPA profiles, such that the system exposes FHIR resources that adhere to the IPA profiles’ content model. Specifically, a server with IPA Profile Support:
CapabilityStatement.instantiates
element: http://hl7.org/fhir/uv/ipa/CapabilityStatement/ipa-server
CapabilityStatement.rest.resource.supportedProfile
elementNote that each IPA Profile page contains that IPA Profile’s official or “canonical” URL.
Interaction Support refers to a system that supports the IPA RESTful interactions. Specifically, a server with IPA Interaction Support:
In the context of IPA, the “supported flag” on any data element SHALL be interpreted to mean FHIR’s MustSupport. Realm-specific implementation guides may provide additional guidance. However, they SHOULD identify and document these differences.
When information on a particular data element is not present, and the reason for absence is unknown, IPA Responders SHALL NOT include the data elements in the resource instance returned as part of the query results. Conversely, IPA Requestors SHALL be able to process resource instances containing data elements asserting missing information.
Must Support elements are treated differently between IPA responders and requestors.
Responders conforming to a profile in IPA SHALL return a Must Support element if that element is available.
There are a few potential reasons by a Must Support element may not be available, for example:
Note: Responders who cannot store or return a data element tagged as Supported in IPA profiles can still claim conformance to the IPA profiles per the IPA conformance resources.
There are situations when information on a particular data element is missing, and the source system does not know the reason for the absence of data.
If the responder does not have data for an element with a minimum cardinality = 0 (including elements labeled Must Support), the data element SHALL be omitted from the resource.
Note: an IPA responder may have no data to be included either because there are no data or because the data available are not pertinent.
If an IPA responder does not have data to be included, the reason for the absence has to be specified as follows:
Clients conforming to a profile in IPA SHALL be capable of processing resource instances containing must-support data elements, including elements with missing data, without generating an error or causing the application to fail. An element can be processed, for example, if the receiving application’s behavior can differ based on the element’s value.
For example, one possible value of the Observation.status element is entered-in-error
. This element is marked as Must Support because requestors must be capable of processing this value to handle the resource’s clinical data appropriately.
Note: Readers are advised to understand FHIR Terminology requirements, FHIR RESTful API based on the HTTP protocol, along with FHIR DataTypes, FHIR Search and FHIR Resource formats when implementing IPA requirements.
Some elements labeled as Must Support reference multiple resource types or profiles (e.g., DocumentReference.author
). IPA servers SHALL support at least one referenced resource or profile for each element listed in the table below. IPA client apps SHALL support all referenced resources or profiles listed in the table below.
IPA Profile Name | Must Support Reference Element | Must Support Reference |
---|---|---|
IPA-MedicationRequest | MedicationRequest.reported[x] | http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-patient, http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-practitioner, http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-practitionerrole |
IPA-MedicationRequest | MedicationRequest.requester | http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-practitioner, http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-practitionerrole, http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-patient |
IPA-DocumentReference | DocumentReference.author | http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-practitioner, http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-practitionerrole, http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-patient |
IPA-DocumentReference | DocumentReference.context.encounter | http://hl7.org/fhir/StructureDefinition/Encounter, http://hl7.org/fhir/StructureDefinition/EpisodeOfCare |
IPA-MedicationStatement | MedicationStatement.context | http://hl7.org/fhir/StructureDefinition/Encounter, http://hl7.org/fhir/StructureDefinition/EpisodeOfCare |
IPA-MedicationStatement | MedicationStatement.informationSource | http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-practitioner, http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-practitionerrole, http://hl7.org/fhir/uv/ipa/StructureDefinition/ipa-patient, http://hl7.org/fhir/StructureDefinition/Organization, http://hl7.org/fhir/StructureDefinition/RelatedPerson |
For example, when claiming conformance to the IPA DocumentReference Profile:
Some elements labeled as Must Support allow different data types (e.g., Observation.effective[x]
) for their content. IPA servers SHALL support at least one data type for each element listed in the table below. IPA client apps SHALL support all data types listed in the table below.
IPA Profile Name | Must Support Choice Element | Must Support Data Types |
---|---|---|
IPA-Immunization | Immunization.occurrence[x] | dateTime, string |
IPA-MedicationRequest | MedicationRequest.reported[x] | boolean, Reference |
IPA-MedicationRequest | MedicationRequest.medication[x] | CodeableConcept, Reference |
IPA-Observation | Observation.effective[x] | dateTime, Period |
IPA-Observation | Observation.value[x] | Quantity, CodeableConcept, string, boolean, integer, Range, time, dateTime, Period |
IPA-MedicationStatement | MedicationStatement.medication[x] | CodeableConcept, Reference |
IPA-MedicationStatement | MedicationStatement.effective[x] | dateTime, Period |
For example, when claiming conformance to the IPA Observation Profile:
Observation.effectiveDateTime
, Observation.effectivePeriod
, or both if the element is available.Observation.effectiveDateTime
and Observation.effectivePeriod
Systems MAY support populating and processing other choice elements not listed in the table (such as Observation.effectiveInstant
), but this is not a requirement.