This page is part of the International Patient Access (v0.1.0: STU 1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions
Note that the conformance verbs - SHALL, SHOULD, MAY - used in this guide are defined by the FHIR Conformance Rules.
This page defines how CapabilityStatements are used and the expectations for mandatory and must support elements. A system SHALL support the resources as profiled by IPA to represent clinical information (Profile Support) and the RESTful interactions defined for it (Profile Support + Interaction Support).
See: the RESTful API
The Artifacts page lists the IPA Profiles that have been 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 exactly the support expected for profile elements labeled Must Support. The sections below illustrate how these elements are displayed and define the rules for interpreting profile elements and subelements labeled Mandatory and Must Support for requesters and responders.
The Capability Statement page outlines conformance requirements and expectations for the IPA Servers as well as the specific profiles and RESTful transactions that need to be supported. Note that country-specific profiles must define terminology bindings and invariants.
Systems deploy, and support, the IPA Profiles to represent clinical information and the IPA RESTful interactions to access the information. Systems that implement both can claim conformance to IPA. This is done by implementing all of the IPA CapabilityStatement into their capabilities.
To claim conformance to an IPA Profile a server:
CapabilityStatement.instantiates
element: http://hl7.org/fhir/uv/ipa/CapabilityStatement/ipa-server
CapabilityStatement.rest.resource.supportedProfile
elementIn the context of IPA, Supported on any data element SHALL be interpreted to mean FHIR’s MustSupport and realm-specific implementation guides are expected to provide additional guidance as appropriate. Generally, implementations are expected to:
For example, a registration system may not have the technical capability to collect and store lab results and therefore is not expected to respond with lab results when queried.
In situations where 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.
NOTE: Responders who do not have the capability to 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.
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.