AU Core Implementation Guide
2.0.1-ci-build - CI Build AU

AU Core Implementation Guide, published by HL7 Australia. This guide is not an authorized publication; it is the continuous build for version 2.0.1-ci-build built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7au/au-fhir-core/ and changes regularly. See the Directory of published versions

## Comparison With Other National and International IGs

Page standards status: Informative

AU Core aligns to, and leverages, international standards and other national standards, in particular:

- International Patient Access 1.1.0
- International Patient Summary Implementation Guide 2.0.0
- US Core Implementation Guide 8.0.0

Relationships between AU Core, AUCDI, and the above key implementation guides is described in Relationship with other IGs.

International Patient Access (IPA) and International Patient Summary (IPS) are specifically referenced, as many of the profiles defined in AU Core are expected in future to be adopted in Australian localisations of these international standards.

Corresponding profiles, conformance requirements, and capability statements included in the key FHIR implementation guides were reviewed and considered during AU Core's development to ensure alignment, and to facilitate adoption of, this standard.

The below comparison evaluates AU Core conformance requirements with the key implementation guides identifying where compliance with AU Core satisfies the expectations established by the referenced implementation guide.

### Profile Comparison

As part of profile comparison, the requirements, constraints, and standards specified in a particular FHIR profile are evaluated. These requirements can include mandatory elements, Must Support elements, cardinality constraints, data types, terminology bindings, usage rules, extensions, and rules on missing or suppressed data.

The table below provides a profile only comparison from AU Core to profiles in key implementation guides. Compliance in the reverse direction is not guaranteed, i.e. a resource that is compliant with an IPA profile MAY NOT be compliant with AU Core.

The comparison considers SHALL and SHOULD requirements. MAY requirements are not compared.

Legend:

Compliant: An AU Core compliant resource meets all requirements of the compared profile.

Additional requirements: An AU Core compliant resource is compatible, but additional changes may be needed to meet all requirements of the compared profile. Where additional requirements are identified, more information is provided in the sections below.

Incompatible: An AU Core compliant resource is incompatible with the compared profile. A resource cannot be compliant to both. Where incompatible requirements are identified, more information is provided in the sections below.

No equivalent profile: No equivalent profile for comparison.

AU Core | IPA 1.1.0 | IPS 2.0.0 | US Core 8.0.0
--- | --- | --- | ---
AU Core AllergyIntolerance |  |  |
AU Core Blood Pressure |  |  |
AU Core Body Height |  |  |
AU Core Body Temperature |  |  |
AU Core Body Weight |  |  |
AU Core Condition |  |  |
AU Core Diagnostic Result Observation |  |  |
AU Core Encounter |  |  |
AU Core HealthcareService |  |  |
AU Core Heart Rate |  |  |
AU Core Immunization |  |  |
AU Core Location |  |  |
AU Core Medication |  |  |
AU Core MedicationRequest |  |  |
AU Core MedicationStatement |  |  |
AU Core Organization |  |  |
AU Core Pathology Result Observation |  |  |
AU Core Patient |  |  |
AU Core Practitioner |  |  |
AU Core PractitionerRole |  |  |
AU Core Procedure |  |  |
AU Core RelatedPerson |  |  |
AU Core Respiration Rate |  |  |
AU Core Smoking Status |  |  |
AU Core Waist Circumference |  |  |

#### IPA Profile Additional Requirements

The following IPA profile(s) contain additional requirements. Implementers are advised to note that some code changes may be required to support these profiles.

AU Core Profile | IPA 1.1.0 Profile | Element | IPA Profile Additional requirements
--- | --- | --- | ---
AU Core MedicationRequest | IPA-MedicationRequest | MedicationRequest.reported[x] | Element flagged as Must Support in IPA.
AU Core MedicationStatement | IPA-MedicationStatement | MedicationStatement.statusReason | Element flagged as Must Support in IPA.
MedicationStatement.context | Element flagged as Must Support in IPA.
MedicationStatement.informationSource | Element flagged as Must Support in IPA.
AU Core Patient | IPA-Patient | Patient.identifier | IPA requires all identifiers to have value (1..1), and at least one of system, type or assigner (ipa-pat-1).
Patient.identifier.value | Element flagged as Must Support in IPA.
Patient.name.text | Sub-element SHOULD be present (ipa-pat-3).
Patient.active | Element SHOULD be present if Patient.link is present (ipa-pat-4). Element flagged as Must Support in IPA.
Patient.link | Element flagged as Must Support in IPA.
AU Core Practitioner | IPA-Practitioner | Practitioner.name.text | Sub-element SHOULD be present (ipa-pract-1).

##### Missing Data

AU Core compliant resources are compliant with IPA requirements for Missing Data.

##### Suppressed Data

IPA does not include requirements for Suppressed Data.

##### Additional Profiles

This version of AU Core has no equivalent profile for the following IPA profiles:

- IPA-DocumentReference

#### IPS Profile Additional Requirements

The following IPS profile(s) contain additional requirements. Implementers are advised to note that some code changes may be required to support these profiles.

AU Core Profile | IPS 2.0.0 Profile | Element | IPS Profile Additional requirements
--- | --- | --- | ---
AU Core AllergyIntolerance | AllergyIntolerance (IPS) | AllergyIntolerance.patient.reference | IPS requires minimum of 1. Element flagged as Must Support in IPS.
AllergyIntolerance.type | Element flagged as Must Support in IPS.
AllergyIntolerance.clinicalStatus | Sub-elements of CodeableConceptIPS are flagged as Must Support.
AllergyIntolerance.code | Sub-elements of CodeableConceptIPS are flagged as Must Support.
AllergyIntolerance.reaction.manifestation | Sub-elements of CodeableConceptIPS are flagged as Must Support.
AU Core Condition | Condition (IPS) | Condition.subject.reference | IPS requires minimum of 1. Element flagged as Must Support in IPS.
Condition.clinicalStatus | Sub-elements of CodeableConceptIPS are flagged as Must Support.
Condition.verificationStatus | Sub-elements of CodeableConceptIPS are flagged as Must Support.
Condition.category | Sub-elements of CodeableConceptIPS are flagged as Must Support.
Condition.severity | Sub-elements of CodeableConceptIPS are flagged as Must Support.
Condition.code | Sub-elements of CodeableConceptIPS are flagged as Must Support.
AU Core Immunization | Immunization (IPS) | Immunization.vaccineCode | Sub-elements of CodeableConceptIPS are flagged as Must Support.
Immunization.patient.reference | IPS requires minimum of 1. Element flagged as Must Support in IPS.
AU Core Medication | Medication (IPS) | Medication.code | Sub-elements of CodeableConceptIPS are flagged as Must Support.
Medication.form | Sub-elements of CodeableConceptIPS are flagged as Must Support. Element flagged as Must Support in IPS.
Medication.ingredient | Element flagged as Must Support in IPS.
Medication.ingredient.item[x] | Sub-elements of CodeableConceptIPS are flagged as Must Support. Element flagged as Must Support in IPS.
Medication.ingredient.strength | Element flagged as Must Support in IPS.
AU Core MedicationRequest | MedicationRequest (IPS) | MedicationRequest.subject.reference | IPS requires minimum of 1. Element flagged as Must Support in IPS.
MedicationRequest.medication[x] | Sub-elements of CodeableConceptIPS are flagged as Must Support.
MedicationRequest.doNotPerform | IPS requires value 'false'.
MedicationRequest.dosageInstruction.timing | Element flagged as Must Support in IPS.
AU Core MedicationStatement | MedicationStatement (IPS) | MedicationStatement.medication[x] | Sub-elements of CodeableConceptIPS are flagged as Must Support.
MedicationStatement.subject.reference | IPS requires minimum of 1. Element flagged as Must Support in IPS.
MedicationStatement.effective[x] | IPS requires minimum of 1. Type choice dateTime is flagged as Must Support in IPS.
MedicationStatement.dosage.timing | Element flagged as Must Support in IPS.
AU Core Pathology Result Observation | Observation Results - Laboratory/Pathology (IPS) | Observation.status | IPS requires value from Results Status Codes - IPS.
Observation.subject.reference | IPS requires minimum of 1. Element flagged as Must Support in IPS.
Observation.effective[x] | IPS prohibits types Timing and instant. Type dateTime is flagged as Must Support in IPS.
Observation.performer | IPS requires minimum of 1.
Observation.category | Sub-elements of CodeableConceptIPS are flagged as Must Support.
Observation.code | Sub-elements of CodeableConceptIPS are flagged as Must Support.
Observation.value[x] | Types string, Quantity and CodeableConceptIPS are flagged as Must Support in IPS. IPS preferred additional binding to Results Coded Values Laboratory/Pathology - IPS.
AU Core Patient | Patient (IPS) | Patient.name | IPS does not allow Data Absent Reason extension (ips-pat-1).
Patient.generalPractitioner | Element flagged as Must Support in IPS.
AU Core Practitioner | Practitioner (IPS) | Practitioner.telecom | Element flagged as Must Support in IPS.
Practitioner.address | Element flagged as Must Support in IPS.
AU Core Procedure | Procedure (IPS) | Procedure.code | Sub-elements of CodeableConceptIPS are flagged as Must Support.
Procedure.subject.reference | IPS requires minimum of 1. Element flagged as Must Support in IPS.
Procedure.performed[x] | IPS requires minimum of 1.
AU Core Smoking Status | Observation Social History - Tobacco Use (IPS) | Observation.subject.reference | IPS requires minimum of 1. Element flagged as Must Support in IPS.
Observation.code | IPS requires LOINC code 72166-2. Sub-elements of CodeableConceptIPS are flagged as Must Support.
Observation.component | Element prohibited in IPS.

##### Missing Data

AU Core compliant resources are compliant with IPS requirements for Missing Data.

##### Suppressed Data

IPS does not include requirements for Suppressed Data.

##### Additional Profiles

This version of AU Core has no equivalent profile for the following IPS profiles:

- Bundle (IPS)
- Composition (IPS)
- Device (IPS)
- Device - Performer or Observer (IPS)
- DeviceUseStatement (IPS)
- DiagnosticReport (IPS)
- Flag - Alert (IPS)
- ImagingStudy (IPS)
- Observation Pregnancy - Expected Delivery Date (IPS)
- Observation Pregnancy - Outcome (IPS)
- Observation Pregnancy- Status (IPS)
- Observation Results - Radiology (IPS)
- Observation Social History - Alcohol Use (IPS)
- Specimen (IPS)

#### US Core Profile Additional Requirements

The following US Core profile(s) contain additional requirements. Implementers are advised to note that some code changes may be required to support these profiles.

AU Core Profile | US Core 8.0.0 Profile | Element | US Core Profile Additional requirements
--- | --- | --- | ---
AU Core AllergyIntolerance | US Core AllergyIntolerance Profile | AllergyIntolerance.code | US Core extensible binding to Common substances for allergy and intolerance documentation including refutations.
AllergyIntolerance.manifestation | US Core extensible binding to SNOMED CT Clinical Findings.
AU Core Blood Pressure | US Core Blood Pressure Profile | Observation.performer | Element flagged as Must Support in US Core.
Observation.code | US Core extensible binding to Vital Sign Result Type.
Observation.value[x] | Type choice Quantity is flagged as Must Support in US Core.
AU Core Body Height | US Core Body Height Profile | Observation.performer | Element flagged as Must Support in US Core.
Observation.code | US Core extensible binding to Vital Sign Result Type.
Observation.component.code | US Core extensible binding to Vital Sign Result Type.
Observation.component.value[x] | Type choice Quantity is flagged as Must Support in US Core.
AU Core Body Temperature | US Core Body Temperature Profile | Observation.performer | Element flagged as Must Support in US Core.
Observation.code | US Core extensible binding to Vital Sign Result Type.
Observation.component.code | US Core extensible binding to Vital Sign Result Type.
Observation.component.value[x] | Type choice Quantity is flagged as Must Support in US Core.
AU Core Body Weight | US Core Body Weight Profile | Observation.performer | Element flagged as Must Support in US Core.
Observation.code | US Core extensible binding to Vital Sign Result Type.
Observation.component.code | US Core extensible binding to Vital Sign Result Type.
Observation.component.value[x] | Type choice Quantity is flagged as Must Support in US Core.
AU Core Condition | US Core Condition Problems and Health Concerns Profile | Condition.category | US Core requires category of 'problem-list-item' or 'health-concern'.
Condition.meta | Element flagged as Must Support in US Core.
Condition.meta.lastUpdated | Sub-element flagged as Must Support in US Core.
Condition.assertedDate | Element flagged as Must Support in US Core.
Condition.abatement[x] | Type choice dateTime is flagged as Must Support in US Core.
Condition.recordedDate | Element flagged as Must Support in US Core.
US Core Condition Encounter Diagnosis Profile | Condition.encounter | Element flagged as Must Support in US Core.
Condition.recordedDate | Element flagged as Must Support in US Core.
AU Core Diagnostic Result Observation | US Core Observation Clinical Result Profile | Observation.code | US Core extensible binding to LOINC Codes.
Observation.value[x] | US Core requires UCUM for coded quantity units (us-core-3). Type choices Quantity, CodeableConcept and string are flagged as Must Support in US Core.
Observation.encounter | Element flagged as Must Support in US Core.
Observation.effective[x] | Type choice dateTime is flagged as Must Support in US Core.
Observation.performer | Reference target Practitioner is flagged as Must Support in US Core.
AU Core Encounter | US Core Encounter Profile | Encounter.type | US Core requires minimum of 1. Element flagged as Must Support in US Core. US Core extensible binding to Encounter Type.
Encounter.meta | Element flagged as Must Support in US Core.
Encounter.meta.lastUpdated | Sub-element flagged as Must Support in US Core.
Encounter.identifier | US Core requires all identifiers to have system and value. Element flagged as Must Support in US Core.
Encounter.identifier.system | Sub-element flagged as Must Support in US Core.
Encounter.identifier.value | Sub-element flagged as Must Support in US Core.
Encounter.participant.period | Element flagged as Must Support in US Core.
Encounter.hospitalization | Element flagged as Must Support in US Core.
Encounter.hospitalization.dischargeDisposition | Element flagged as Must Support in US Core.
AU Core Heart Rate | US Core Heart Rate Profile | Observation.code | US Core extensible binding to Vital Sign Result Type.
Observation.performer | Element flagged as Must Support in US Core.
Observation.component.code | US Core extensible binding to Vital Sign Result Type.
Observation.component.value[x] | Sub-element flagged as Must Support in US Core.
AU Core Immunization | US Core Immunization Profile | Immunization.vaccineCode | US Core extensible binding to CVX Vaccines Administered Vaccine Set.
Immunization.statusReason | Element flagged as Must Support in US Core.
Immunization.encounter | Element flagged as Must Support in US Core.
Immunization.location | Element flagged as Must Support in US Core.
Immunization.performer | Element flagged as Must Support in US Core.
Immunization.performer.actor | Element flagged as Must Support in US Core. Reference target Practitioner is flagged as Must Support in US Core.
AU Core Location | US Core Location Profile | Location.name | US Core requires minimum of 1.
Location.identifier | Element flagged as Must Support in US Core.
Location.status | Element flagged as Must Support in US Core.
Location.type | US Core extensible additional bindings to Healthcare Service Location Type Combined and CMS Place of Service Codes (POS).
Location.type.coding | US Core requires minimum of 1 and each coding to have system and code. Sub-element flagged as Must Support in US Core.
Location.type.coding.system | Sub-element flagged as Must Support in US Core.
Location.type.coding.code | Sub-element flagged as Must Support in US Core.
Location.telecom | Element flagged as Must Support in US Core.
Location.address.line | Sub-element flagged as Must Support in US Core.
Location.address.city | Sub-element flagged as Must Support in US Core.
Location.address.state | US Core extensible binding to USPS Two Letter Alphabetic Codes. Sub-element flagged as Must Support in US Core.
Location.address.postalCode | Sub-element flagged as Must Support in US Core.
AU Core Medication | US Core Medication Profile | Medication.code | US Core extensible binding to Medication Clinical Drug.
AU Core MedicationRequest | US Core MedicationRequest Profile | MedicationRequest.medicationCodeableConcept | US Core extensible binding to Medication Clinical Drug.
MedicationRequest.category | Element flagged as Must Support in US Core.
MedicationRequest.reported[x] | Type choice boolean and reference target Practitioner are flagged as Must Support in US Core. Element flagged as Must Support in US Core.
MedicationRequest.requester | Reference target Practitioner is flagged as Must Support in US Core.
MedicationRequest.reasonCode | US Core extensible binding to US Core Condition Codes.
MedicationRequest.dosageInstruction.timing | Sub-element flagged as Must Support in US Core.
MedicationRequest.dosageInstruction.route | US Core extensible binding to Route of Administration of Therapeutic Agents. Sub-element flagged as Must Support in US Core.
MedicationRequest.dosageInstruction.doseAndRate | Sub-element flagged as Must Support in US Core.
MedicationRequest.dosageInstruction.doseAndRate.dose[x] | Type choice Quantity is flagged as Must Support in US Core. Sub-element flagged as Must Support in US Core.
MedicationRequest.dispenseRequest | Element flagged as Must Support in US Core.
MedicationRequest.dispenseRequest.numberOfRepeatsAllowed | Element flagged as Must Support in US Core.
MedicationRequest.dispenseRequest.quantity | Element flagged as Must Support in US Core.
AU Core Organization | US Core Organization Profile | Organization.active | US Core requires minimum of 1. Element flagged as Must Support in US Core.
Organization.identifier | Sub-elements flagged as Must Support in US Core.
Organization.address.line | US Core allows maximum of 4. Sub-element flagged as Must Support in US Core.
Organization.address.city | Sub-element flagged as Must Support in US Core.
Organization.address.state | US Core extensible binding to USPS Two Letter Alphabetic Codes. Sub-element flagged as Must Support in US Core.
Organization.address.postalCode | Sub-element flagged as Must Support in US Core.
Organization.address.country | Sub-element flagged as Must Support in US Core.
AU Core Pathology Result Observation | US Core Laboratory Result Observation Profile | Observation.code | US Core extensible binding to US Core Laboratory Test Codes.
Observation.referenceRange | US Core requires UCUM for coded quantity units (us-core-22).
Observation.meta | Element flagged as Must Support in US Core.
Observation.meta.lastUpdated | Sub-element flagged as Must Support in US Core.
Observation.encounter | Element flagged as Must Support in US Core.
Observation.performer | Reference target Practitioner is flagged as Must Support in US Core.
Observation.effective | Type choice dateTime flagged as Must Support in US Core.
Observation.value[x] | US Core requires UCUM for coded quantity units (us-core-3). Type choices Quantity, CodeableConcept and string are flagged as Must Support in US Core.
AU Core Patient | US Core Patient Profile | Patient.identifier | US Core requires all identifiers to have system and value.
Patient.identifier.system | Sub-element flagged as Must Support in US Core.
Patient.identifier.value | Sub-element flagged as Must Support in US Core.
Patient.name | US Core requires all name to have family or given or Data Absent Reason extension (us-core-6).
Patient.telecom | US Core requires all telecom to have system and value.
Patient.address.line | Sub-element flagged as Must Support in US Core.
Patient.address.city | Sub-element flagged as Must Support in US Core.
Patient.address.state | US Core extensible binding to USPS Two Letter Alphabetic Codes. Sub-element flagged as Must Support in US Core.
Patient.address.postalCode | Sub-element flagged as Must Support in US Core.
AU Core Practitioner | US Core Practitioner Profile | Practitioner.identifier | US Core requires minimum of 1, and all identifiers to have system and value.
Practitioner.identifier.system | Sub-element flagged as Must Support in US Core.
Practitioner.identifier.value | Sub-element flagged as Must Support in US Core.
Practitioner.telecom | Element flagged as Must Support in US Core.
Practitioner.telecom.system | Sub-element flagged as Must Support in US Core.
Practitioner.telecom.value | Sub-element flagged as Must Support in US Core.
Practitioner.address | Element flagged as Must Support in US Core.
Practitioner.address.line | US Core allows maximum of 4. Sub-element flagged as Must Support in US Core.
Practitioner.address.city | Sub-element flagged as Must Support in US Core.
Practitioner.address.state | US Core extensible binding to USPS Two Letter Alphabetic Codes. Sub-element flagged as Must Support in US Core.
Practitioner.address.postalCode | Sub-element flagged as Must Support in US Core.
Practitioner.address.country | Sub-element flagged as Must Support in US Core.
AU Core PractitionerRole | US Core PractitionerRole Profile | PractitionerRole.telecom, PractitionerRole.endpoint | US Core requires telecom or endpoint to be present (pd-1).
PractitionerRole.location | Element flagged as Must Support in US Core.
PractitionerRole.telecom | US Core requires all telecom to have system and value.
PractitionerRole.endpoint | Element flagged as Must Support in US Core.
PractitionerRole.code | US Core extensible binding to Care Team Member Function.
PractitionerRole.specialty | US Core extensible binding to Healthcare Provider Taxonomy.
AU Core RelatedPerson | US Core RelatedPerson Profile | RelatedPerson.active | US Core requires minimum of 1. Element flagged as Must Support in US Core.
AU Core Respiration Rate | US Core Respiratory Rate Profile | Observation.code | US Core extensible binding to Vital Sign Result Type.
Observation.performer | Element flagged as Must Support in US Core.
Observation.component.code | US Core extensible binding to Vital Sign Result Type.
Observation.component.value[x] | Sub-element flagged as Must Support in US Core.
AU Core Smoking Status | US Core Smoking Status Observation Profile | Observation.status | US Core requires status of 'final' or 'entered-in-error'.
Observation.code | US Core extensible binding to Smoking Status Type.
Observation.performer | Element flagged as Must Support in US Core. Reference target Practitioner is flagged as Must Support in US Core.
Observation.value[x] | US core requires minimum of 1.
Observation.value[x]:valueCodeableConcept | US Core extensible binding to Smoking status comprehensive.
Observation.value[x]:valueQuantity | This US Core profile supports capture of tobacco smoking consumption as well as smoking status; AU Core does not. An instantiation of Tobacco smoking consumption is considered an 'additional profile' not an additional requirement.
AU Core Waist Circumference | US Core Vital Signs Profile | Observation.performer | Element flagged as Must Support in US Core.
Observation.code | US Core extensible binding to Vital Sign Result Type.
Observation.component.value[x] | Type choice Quantity is flagged as Must Support in US Core.
Observation.component.code | US Core extensible binding to Vital Sign Result Type.

##### Missing Data

AU Core compliant resources are compliant with US Core requirements for Missing Data.

##### Suppressed Data

AU Core compliant resources are compliant with US Core requirements for Suppressed Data.

##### Additional Profiles

This version of AU Core has no equivalent profile for the following US Core profiles:

- US Core CarePlan Profile
- US Core CareTeam Profile
- US Core Coverage Profile
- US Core Implantable Device Profile
- US Core DiagnosticReport Profile for Laboratory Results Reporting Profile
- US Core DiagnosticReport Profile for Report and Note Exchange Profile
- US Core ADI DocumentReference Profile
- US Core DocumentReference Profile
- US Core Goal Profile
- US Core MedicationDispense Profile
- US Core Average Blood Pressure Profile
- US Core BMI Profile
- US Core Care Experience Preference Profile
- US Core Observation ADI Document Profile
- US Core Observation Occupation Profile
- US Core Observation Pregnancy Intent Profile
- US Core Observation Pregnancy Status Profile
- US Core Observation Screening Assessment Profile
- US Core Observation Sexual Orientation Profile
- US Core Pediatric BMI for Age Observation Profile
- US Core Pediatric Head Occipital Frontal Circumference Percentile Profile
- US Core Pediatric Weight for Height Observation Profile
- US Core Pulse Oximetry Profile
- US Core Simple Observation Profile
- US Core Treatment Intervention Preference Profile
- US Core Provenance Profile
- US Core QuestionnaireResponse Profile
- US Core ServiceRequest Profile
- US Core Specimen Profile

### Capability Statement Comparison

As part of the comparison, both system and resource level capabilities are compared, including FHIR version, supported formats and guides, conformance expectations, RESTful interactions, security, resource types and profiles, search parameters, reference handling, and operations.

#### CapabilityStatement Mapping

AU Core defines capability statements that describe the conformance requirements and expectations of a corresponding AU Core system actor:

- AU Core Requester - a system that creates and initiates a data access request to retrieve core digital health and administrative information
- AU Core Responder - a system that receives and responds to data access requests from AU Core Requesters

The table below provides a mapping of AU Core capability statements to capability statements in IPA, IPS, or US Core. A capability statement is considered mapped where the corresponding actor serves a similar role and purpose.

Legend:

No similar capability statement: No similar actor in terms of role and purpose is defined.

AU Core | IPA 1.1.0 | IPS 2.0.0 | US Core 8.0.0
--- | --- | --- | ---
AU Core Requester | IPA Client |  | US Core Client
AU Core Responder | IPA Server | 1 (IPS Server) | US Core Server

1The IPS Server CapabilityStatement is not directly comparable as the role and purpose is inexact; the IPS server actor overlaps with the AU Core Responder actor, but actors cover additional meaning.

#### CapabilityStatement Comparison

The table below provides a capability statements comparison from AU Core to those in key implementation guides. Compliance in the reverse direction is not guaranteed, i.e. a system conforming to the IPA Client CapabilityStatement MAY NOT meet the conformance requirements of the AU Core Requester CapabilityStatement.

The comparison considers SHALL and SHOULD requirements. MAY requirements are not compared.

Legend:

Compliant: A system conforming to an AU Core CapabilityStatement requirements meets all of the equivalent requirements of the compared capability statement.

Additional requirements: A system conforming to an AU Core CapabilityStatement requirement is compatible with the compared capability statement but may require additional functionality to meet its stricter or broader requirements. Where additional requirements are identified, more information is provided in the sections below.

Incompatible: A system conforming to an AU Core CapabilityStatement is incompatible with the compared capability statement. A system cannot be compliant to both. Where incompatible requirements are identified, more information is provided in the sections below.

No equivalent capability statement or resource type: No equivalent CapabilityStatement mapped for comparison or no equivalent support for that resource type.

AU Core CapabilityStatement Requirement | AU Core Requester CapabilityStatement | AU Core Responder CapabilityStatement
--- | --- | ---
IPA 1.1.0 | IPS 2.0.0 | US Core 8.0.0 | IPA 1.1.0 | IPS 2.0.0 | US Core 8.0.0
FHIR RESTful Capabilities (system wide) | FHIR version |  |  |  |  |  |
Supported formats |  |  |  |  |  |
Supported patch formats |  |  |  |  |  |
Supported implementation guides |  |  |  |  |  |
FHIR capabilities |  |  |  |  |  |
FHIR resource support |  |  |  |  |  |
System wide interactions |  |  |  |  |  |
Security |  |  |  |  |  |
Capabilities by Resource/Profile | AllergyIntolerance |  |  |  |  |  |
Condition |  |  |  |  |  |
DiagnosticReport |  |  |  |  |  |
DocumentReference |  |  |  |  |  |
Encounter |  |  |  |  |  |
HealthcareService |  |  |  |  |  |
Immunization |  |  |  |  |  |
Location |  |  |  |  |  |
Medication |  |  |  |  |  |
MedicationRequest |  |  |  |  |  |
MedicationStatement |  |  |  |  |  |
Observation |  |  |  |  |  |
Organization |  |  |  |  |  |
Patient |  |  |  |  |  |
Practitioner |  |  |  |  |  |
PractitionerRole |  |  |  |  |  |
Procedure |  |  |  |  |  |
RelatedPerson |  |  |  |  |  |
Specimen |  |  |  |  |  |

#### IPA CapabilityStatement Additional Requirements

A system conforming to an AU Core CapabilityStatement aligns with IPA CapabilityStatements but will require additional functionality to meet its stricter or broader requirements. The table below identifies additional requirements included in IPA CapabilityStatements. Implementers are advised to note that some code changes may be required to ensure full compliance.

Legend:

Stronger: The CapabilityStatement strengthens a conformance requirement that is present in the AU Core CapabilityStatement (e.g. SHOULD to SHALL).

New: The CapabilityStatement includes a conformance requirement that is NOT present in the mapped AU Core CapabilityStatement.

AU Core CapabilityStatement requirement | IPA 1.1.0 Client CapabilityStatement additional requirements | IPA 1.1.0 Server CapabilityStatement additional requirements
--- | --- | ---
Supported implementation guides | SHALL support http://hl7.org/fhir/smart-app-launch/ImplementationGuide/hl7.fhir.uv.smart-app-launch. | SHALL support http://hl7.org/fhir/smart-app-launch/ImplementationGuide/hl7.fhir.uv.smart-app-launch.
FHIR capabilities | SHOULD specify the patient id when performing searches on other resources. |
FHIR resource support | SHALL support the IPA conformance expectations for the Patient profile and for each IPA resource type they support, see additional requirements below. | SHALL support the IPA conformance expectations for the Patient profile and for each IPA resource type they support, see additional requirements below.
Security | SHALL follow FHIR Security requirements. | SHALL follow FHIR Security requirements.
SHOULD follow the security best practices outlined in FHIR Security and elsewhere. | SHOULD follow the security best practices outlined in FHIR Security and elsewhere.
SHALL handle scope-based authorisation failures gracefully. | SHALL handle scope-based authorisation failures gracefully.
AllergyIntolerance | SHALL handle: `AllergyIntolerance.clinicalStatus`, `AllergyIntolerance.verificationStatus`, and `AllergyIntolerance.code`. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
Condition | SHALL handle: `Condition.clinicalStatus`, `Condition.verificationStatus`, and `Condition.code`. | SHOULD populate: `Condition.code.coding.display` and/or `Condition.code.text`.
SHALL NOT treat all Condition resources as entries in the current problem list. | SHOULD avoid leaving `Condition.clinicalStatus` and `Condition.verificationStatus` missing.
SHALL correctly process and display `Condition.clinicalStatus` and `Condition.verificationStatus`. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
SHALL continue to function safely when some expected search parameters are not supported.
Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
DocumentReference | SHALL meet the requirements of the IPA-DocumentReference profile. | SHALL meet the requirements of the IPA-DocumentReference profile.
SHALL support `read` and `search-type` interactions. | SHALL support `read` and `search-type` interactions.
SHALL support the `patient` search parameter. | SHALL support `_id`, `patient`,`patient+category`, `patient+category+date`, and `patient+type` search parameters and search parameter combinations.
SHALL handle: `DocumentReference.status`, `DocumentReference.type`, `DocumentReference.subject`, `DocumentReference.content`, `DocumentReference.content.attachment`, `DocumentReference.content.attachment.contentType`, `DocumentReference.content.attachment.data`, `DocumentReference.content.attachment.url`, `DocumentReference.format`, `DocumentReference.context`, `DocumentReference.context.encounter`, and `DocumentReference.context.period`. | SHALL populate-if-known: `DocumentReference.status`, `DocumentReference.type`, `DocumentReference.category`, `DocumentReference.subject`, `DocumentReference.date`, `DocumentReference.author`, `DocumentReference.content`, `DocumentReference.content.attachment`, `DocumentReference.content.attachment.contentType`, `DocumentReference.content.attachment.data`, `DocumentReference.content.attachment.url`, `DocumentReference.format`, `DocumentReference.context`, `DocumentReference.context.encounter`, and `DocumentReference.context.period`.
SHOULD handle: `DocumentReference.category` and `DocumentReference.author`. | SHALL support `$docref` operation.
SHOULD support `_id`, `patient+category`, `patient+category+date`, `patient+type`, `patient+contenttype`, `patient+status`, `patient+type+date`, and `patient+type+period` search parameter combinations. | SHOULD support `patient+contenttype`, `patient+status`, `patient+type+date`, and `patient+type+period` search parameters and search parameters combinations.
Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
SHOULD support `$docref` operation.
Immunization | SHALL meet the requirements of the IPA-Immunization profile which has additional requirements, see IPA profile additional requirements. | SHALL meet the requirements of the IPA-Immunization profile which has additional requirements, see IPA profile additional requirements.
SHALL handle: `Immunization.status`, `Immunization.vaccineCode`, `Immunization.patient` and `Immunization.occurence[x]`.
Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
Medication | SHALL handle `Medication.code`. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
MedicationRequest | SHALL meet the requirements of the IPA-MedicationRequest profile which has additional requirements, see IPA profile additional requirements. | SHALL meet the requirements of the IPA-MedicationRequest profile which has additional requirements, see IPA profile additional requirements.
SHALL query both MedicationRequest and MedicationStatement when fetching patient Medication information. | SHOULD use codings at the level of a clinical drug.
SHALL handle: `MedicationRequest.status`, `MedicationRequest.doNotPerform`, `MedicationRequest.medication[x]`, `MedicationRequest.subject`, `MedicationRequest.requester`, `MedicationRequest.dosageInstruction`, and `MedicationRequest.dosageInstruction.text`. | SHOULD populate `MedicationRequest.doNotPerform`.
SHOULD handle `MedicationRequest.reported[x]`. | SHALL populate-if-known `MedicationRequest.reported[x]`.
SHOULD support `category` and `code` search parameters. | SHOULD support `category` and `code` search parameters.
Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
MedicationStatement | SHALL meet the requirements of the IPA-MedicationStatement profile which has additional requirements, see IPA profile additional requirements. | SHALL meet the requirements of the IPA-MedicationStatement profile which has additional requirements, see IPA profile additional requirements.
SHALL query both MedicationRequest and MedicationStatement when fetching patient Medication information. | SHALL populate-if-known: `MedicationStatement.context` and `MedicationStatement.informationSource`.
SHALL handle: `MedicationStatement.status`, `MedicationStatement.medication[x]`, and `MedicationStatement.subject`. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
SHOULD handle: `MedicationStatement.effective[x]`, `MedicationStatement.dosage`, and `MedicationStatement.dosage.text`.
Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
Observation | SHALL support `patient` search parameter. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
SHALL handle: `Observation.status`, `Observation.code`, `Observation.subject`, `Observation.effective[x]`, `Observation.value[x]`, and `Observation.dataAbsentReason`.
SHOULD handle `Observation.category`.
Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
Patient | SHALL meet the requirements of the IPA-Patient profile which has additional requirements, see IPA profile additional requirements. | SHALL meet the requirements of the IPA-Patient profile which has additional requirements, see IPA profile additional requirements.
SHALL be able to follow `Patient.link` to other Patient resources and understand direction of the link. | SHALL use `Patient.link` cross-link multiple Patient resources for the same person in search Bundles.
SHALL understand the `Patient.link.type` code. | SHALL populate-if-known `Patient.identifier.value`, `Patient.active`, and `Patient.link`.
SHALL be aware of the linked Patient's `active` flag and that inactive patients may have relevant information. | SHALL have no more than one Patient with a status of active = "true" for the same patient on the server.
SHALL support `Patient.link` processing. | SHALL explain `Patient.identifier`.
SHALL handle: `Patient.identifier`, `Patient.gender`, `Patient.birthDate`, and `Patient.link`. | SHOULD support `given`, `birthdate`, and `gender` search parameters.
Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
SHOULD support `given`, `birthdate`, and `gender` search parameters.
Practitioner | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.
PractitionerRole | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351. | Conformance level SHOULD/MAY for `_revinclude=Provenance:target` is under discussion, see FHIR-50351.

#### IPS CapabilityStatement Additional Requirements

A system conforming to an AU Core CapabilityStatement aligns with IPS CapabilityStatement but will require additional functionality to meet its stricter or broader requirements. The table below identifies additional requirements included in IPS CapabilityStatements. Implementers are advised to note that some code changes may be required to ensure full compliance.

Legend:

Stronger: The CapabilityStatement strengthens a conformance requirement that is present in the AU Core CapabilityStatement (e.g. SHOULD to SHALL).

New: The CapabilityStatement includes a conformance requirement that is NOT present in the mapped AU Core CapabilityStatement.

AU Core CapabilityStatement requirement | IPS 2.0.0 Server CapabilityStatement additional requirements
--- | ---
Bundle | SHALL support Bundle resource.
SHALL support Bundle (IPS) profile.
Composition | SHALL support Composition resource.
SHALL support Composition (IPS) profile.
Patient | SHALL support Patient (IPS) profile which has additional requirements, see IPS profile additional requirements.
SHOULD support `$summary` operation.
AllergyIntolerance | SHOULD support AllergyIntolerance (IPS) profile which has additional requirements, see IPS profile additional requirements. IPS sets this profile as a supported profile for the AllergyIntolerance resource, we interpret this as a conformance expectation of SHOULD.
Condition | SHOULD support Condition (IPS) profile which has additional requirements, see IPS profile additional requirements. IPS sets this profile as a supported profile for the Condition resource, we interpret this as a conformance expectation of SHOULD.
MedicationRequest | SHOULD support MedicationRequest (IPS) profile which has additional requirements, see IPS profile additional requirements. IPS sets this profile as a supported profile for the MedicationRequest resource, we interpret this as a conformance expectation of SHOULD.

#### US Core CapabilityStatement Additional Requirements

A system conforming to an AU Core CapabilityStatement aligns with US Core CapabilityStatements but will require additional functionality to meet its stricter or broader requirements. The table below identifies additional requirements included in US Core CapabilityStatements. Implementers are advised to note that some code changes may be required to ensure full compliance.

Legend:

Stronger: The CapabilityStatement strengthens a conformance requirement that is present in the AU Core CapabilityStatement (e.g. SHOULD to SHALL).

New: The CapabilityStatement includes a conformance requirement that is NOT present in the maped AU Core CapabilityStatement.

2Servers certified under the 21st Century Cures Act for accessing patient data apply additional requirements including requirements to support ALL resources defined in this capability statement with resource conformance SHALL. These additional requirements are excluded from comparison, i.e. with the exception of the Patient resource, resource conformance SHALL is considered SHOULD.

AU Core CapabilityStatement requirement | US Core 8.0.0 Client CapabilityStatement additional requirements | US Core 8.0.0 Server CapabilityStatement additional requirements2
--- | --- | ---
FHIR resource support | SHALL support fetching and querying of one or more US Core profile(s), using the supported RESTful interactions and search parameters declared in the US Core Server CapabilityStatement, see additional requirements below. | SHALL support US Core Patient profile and at least one additional resource profile from the list of US Core Profiles and all Must Support US Core Profiles and resources it references, see additional requirements below.
Security | SHALL establish a risk analysis and management regime conforming with HIPAA security regulatory requirements. | SHALL establish a risk analysis and management regime conforming with HIPAA security regulatory requirements.
SHALL use a single time source for audit and logging. The selected time service SHOULD be documented in the Business Associate Agreement when available. | SHALL use a single time source for audit and logging. The selected time service SHOULD be documented in the Business Associate Agreement when available.
SHALL maintain audit logs of transactions. | SHALL maintain audit logs of transactions.
SHALL conform to FHIR Communications Security requirements. | SHALL conform to FHIR Communications Security requirements.
SHALL support SMART App Launch version 2.0.0. | SHALL support SMART App Launch version 2.0.0.
SHALL implement consent according to local, institutional, and legal policy. | SHALL implement consent according to local, institutional, and legal policy.
SHOULD define risk management and security/privacy controls in a Business Associate Agreement (BAA) when available. | SHOULD define risk management and security/privacy controls in a Business Associate Agreement (BAA) when available..
SHOULD provide Provenance statements using the US Core Provenance Profile. | SHOULD provide Provenance statements using the US Core Provenance Profile.
AllergyIntolerance | SHALL support the US Core AllergyIntolerance Profile which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core AllergyIntolerance Profile which has additional requirements, see US Core profile additional requirements.
SHOULD support `_revinclude: Provenance:target`. | SHALL support `_revinclude: Provenance:target`.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
CarePlan | SHOULD support CarePlan resource. | SHOULD2 support CarePlan resource.
SHALL support US Core CarePlan Profile. | SHALL support US Core CarePlan Profile.
SHALL support `read` and `search-type` interactions. | SHALL support `read` and `search-type` interactions.
SHALL support `patient+category` search parameter combination. | SHALL support `patient+category` search parameter combination.
SHALL be capable of fetching a CarePlan resource using: `GET [base]/CarePlan/[id]`. | SHALL be capable of returning a CarePlan resource using: `GET [base]/CarePlan/[id]`.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `patient+ category +status`, `patient+category+status+date`, and `patient+category+date` search parameter combinations. | SHOULD support `patient+ category +status`, `patient+category+status+date`, and `patient+category+date` search parameter combinations.
CareTeam | SHOULD support CareTeam resource. | SHOULD2 support CareTeam resource.
SHALL support US Core CareTeam Profile. | SHALL support US Core CareTeam Profile.
SHALL support `read` and `search-type` interactions. | SHALL support `read` and `search-type` interactions.
SHALL support `patient+category` search parameter combination. | SHALL support `patient+category` search parameter combination.
SHALL be capable of fetching a CareTeam resource using: `GET [base]/CareTeam/[id]`. | SHALL be capable of returning a CareTeam resource using: `GET [base]/CareTeam/[id]`.
SHALL support references to US Core Practitioner Profile, US Core PractitionerRole Profile, US Core Patient Profile, and US Core RelatedPerson Profile. | SHALL support references to at least one of US Core Practitioner Profile or US Core PractitionerRole Profile.
SHOULD reference US Core PractitionerRole Profile instead of US Core Practitioner Profile.
SHALL provide implementation-specific guidance for accessing provider location and contact information if only US Core Practitioner Profile is supported.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHALL support `patient+status` search parameter combination. | SHALL support `patient+status` search parameter combination.
SHOULD support `_include` parameters `CareTeam:participant:PractitionerRole`, `CareTeam:participant:Practitioner`, `CareTeam:participant:Patient`, and `CareTeam:participant:RelatedPerson`. | SHOULD support `_include` parameters `CareTeam:participant:PractitionerRole`, `CareTeam:participant:Practitioner`, `CareTeam:participant:Patient`, and `CareTeam:participant:RelatedPerson`.
SHOULD support `role` and `patient+role` search parameters and search parameter combinations. | SHOULD support `role` and `patient+role` search parameters and search parameter combinations.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
Condition | SHALL support US Core Condition Encounter Diagnosis Profile and US Core Condition Problems and Health Concerns Profile which have additional requirements, see US Core profile additional requirements. | SHALL support both US Core Condition Encounter Diagnosis Profile and US Core Condition Problems and Health Concerns Profile which have additional requirements, see US Core profile additional requirements.
SHALL support `assertedDate Extension` or `Condition.recordedDate` elements. | SHALL support `Condition.recordedDate` elements and at least one of the `assertedDate Extension` and `Condition.onsetDateTime`.
SHOULD support `_revinclude: Provenance:target`. | SHALL support `_revinclude: Provenance:target`.
SHOULD support `patient+abatement-date`, `patient+asserted-date`, `patient+category+encounter`, `patient+_lastUpdated`, and `patient+recorded-date` search parameters combination. | SHOULD support `patient+abatement-date`, `patient+asserted-date`, `patient+category+encounter`, `patient+_lastUpdated`, and `patient+recorded-date` search parameters combination.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
When `Condition.category` is a "problems-list-item", the `Condition.clinicalStatus` SHOULD be present. | When `Condition.category` is a "problems-list-item", the `Condition.clinicalStatus` SHOULD be present.
SHOULD reference encounter in `Condition.encounter` when category is "encounter-diagnosis". | SHOULD reference encounter in `Condition.encounter` when category is "encounter-diagnosis".
SHOULD update `Condition.meta.lastUpdated` to reflect new problems and health concerns, and changes in clinical status or verification status. | SHOULD update `Condition.meta.lastUpdated` to reflect new problems and health concerns, and changes in clinical status or verification status.
Coverage | SHOULD support Coverage resource. | SHOULD2 support Coverage resource.
SHALL support US Core Coverage Profile. | SHALL support US Core Coverage Profile.
SHALL support `read` and `search-type` interactions. | SHALL support `read` and `search-type` interactions.
SHALL be capable of fetching a Coverage resource using: `GET [base]/Coverage/[id]`. | SHALL be capable of returning a Coverage resource using: `GET [base]/Coverage/[id]`.
SHOULD support `_revinclude: Provenance:target`. | SHALL support `_revinclude: Provenance:target`.
SHALL support `patient` search parameter. | SHALL support `patient` search parameter.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
Device | SHOULD support Device resource. | SHOULD2 support Device resource.
SHALL support US Core Implantable Device Profile. | SHALL support US Core Implantable Device Profile.
SHALL support `read` and `search-type` interactions. | SHALL support `read` and `search-type` interactions.
SHALL be capable of fetching a Device resource using: `GET [base]/Device/[id]`. | SHALL be capable of returning a Device resource using: `GET [base]/Device/[id]`.
SHALL represent the UDI code in `Device.udiCarrier.carrierHRF` when UDI information is available. | SHALL represent the UDI code in `Device.udiCarrier.carrierHRF` when UDI information is available.
SHALL represent all UDI-PI elements present in the UDI code using the corresponding elements in the US Core Implantable Device Profile. | SHALL represent all UDI-PI elements present in the UDI code using the corresponding elements in the US Core Implantable Device Profile.
SHALL support `patient` search parameter. | SHALL support `patient` search parameter.
SHOULD include `Device.manufacturer` and/or `Device.model` when UDI is not present but manufacturer or model information is available. | SHOULD include `Device.manufacturer` and/or `Device.model` when UDI is not present but manufacturer or model information is available.
SHOULD support querying implantable devices by `Device.type`.
SHOULD support `_revinclude: Provenance:target`. | SHALL support `_revinclude: Provenance:target`.
SHOULD support `patient+status` and `patient+type` search parameter combinations. | SHOULD support `patient+status` and `patient+type` search parameter combinations.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
DiagnosticReport | SHALL support US Core DiagnosticReport Profile for Laboratory Results Reporting and US Core DiagnosticReport Profile for Report and Note Exchange profiles. | SHALL support US Core DiagnosticReport Profile for Laboratory Results Reporting and US Core DiagnosticReport Profile for Report and Note Exchange profiles.
SHALL be capable of fetching a DiagnosticReport resource using: `GET [base]/DiagnosticReport/[id]`. | SHALL be capable of returning a DiagnosticReport resource using: `GET [base]/DiagnosticReport/[id]`.
SHALL support `read` and `search-type` interactions. | SHALL support `read` and `search-type` interactions.
SHALL support `create` for the US Core DiagnosticReport Profile for Report and Note exchange profile. | SHALL support `create` for the US Core DiagnosticReport Profile for Report and Note exchange profile.
SHALL support `patient`, `patient+code`, `patient+category`, and `patient+category+date` search parameter and search parameter combinations. | SHALL support `patient`, `patient+code`, `patient+category`, and `patient+category+date` search parameter and search parameter combinations.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `patient+code+date`, `patient+status`, and `patient+category+_lastUpdated` search parameter combinations. | SHOULD support `patient+code+date`, `patient+status`, and `patient+category+_lastUpdated` search parameter combinations.
SHOULD use `DiagnosticReport.media.link` to suppport links to images | SHOULD use `DiagnosticReport.media.link` to suppport links to images
SHOULD use `DiagnosticReport.imagingStudy` to reference DICOM imaging studies. | SHOULD use `DiagnosticReport.imagingStudy` to reference DICOM imaging studies.
SHOULD update `DiagnosticReport.meta.lastUpdated` to reflect new laboratory reports, and changes in the status of laboratory report. | SHOULD update `DiagnosticReport.meta.lastUpdated` to reflect new laboratory reports, and changes in the status of laboratory report.
DocumentReference | SHALL support US Core DocumentReference Profile and US Core ADI DocumentReference Profile. | SHALL support US Core DocumentReference Profile.
SHALL support at minimum the ten Common Clinical Notes in the DocumentReference.type. | SHALL support at minimum the ten Common Clinical Notes in the DocumentReference.type.
SHALL support both `DocumentReference.content.attachment.url` and `DocumentReference.content.attachment.data`. | SHALL support at least one of `DocumentReference.content.attachment.url` and `DocumentReference.content.attachment.data`.
If there are multiple `DocumentReference.content` repetitions, these SHALL represent the same document in different formats or attachment metadata, and SHALL NOT represent different document versions. | If there are multiple `DocumentReference.content` repetitions, these SHALL represent the same document in different formats or attachment metadata, and SHALL NOT represent different document versions.
SHALL be capable of handling a responsible organisation, either direclty in `DocumentReference.custodian` or via `Provenance.agent.who` or `Provenance.agent.onBehalfOf`. | SHALL ansure that the responsible organisation is present either in `DocumentReference.custodian` or accesible via `Provenance.agent.who` or `Provenance.agent.onBehalfOf`.
SHALL be capable of fetching a DocumentReference resource using: `GET [base]/DocumentReference/[id]`. | SHALL be capable of returning a DocumentReference resource using: `GET [base]/DocumentReference/[id]`.
SHALL support `create`, `read` and `search-type` interactions. | SHALL support `create`, `read` and `search-type` interactions.
SHALL support `_id`, `patient`, `patient+type`, `patient+category`, and `patient+category+date` search parameters and search parameter combinations. | SHALL support `_id`, `patient`, `patient+type`, `patient+category`, and `patient+category+date` search parameters and search parameter combinations.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `$docref` operation. | SHALL support `$docref` operation.
SHOULD be capable of transacting the `$docref` operation. | SHALL be capable of responding to a `$docref` operation.
SHOULD be capable of receiving at least a reference to a CCD document. | SHALL return at least a reference to a CCD document, if available.
SHOULD be capable of receiving included resources returned in the operation response. | SHOULD document what resources (if any) are returned as included resources.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD support `patient+type+period` and `patient+status` search parameter combinations. | SHOULD support `patient+type+period` and `patient+status` search parameter combinations.
If a `period` parameter is supplied to the `$docref` operation, SHOULD return references to documents within the specified date range; if not supplied, SHALL return the most recent or current document(s).
Encounter | SHALL support the US Core Encounter profile which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core Encounter profile which has additional requirements, see US Core profile additional requirements.
SHALL support `_id` search parameter. | SHALL support `_id` search parameter.
SHALL support both `Encounter.location.location` and `Encounter.serviceProvider`. | SHALL support at least one of `Encounter.location.location` and `Encounter.serviceProvider`.
SHOULD support `identifier`, `patient+type`, `patient+_lastUpdated`, and `patient+discharge-disposition` search parameters and search parameter combinations. | SHOULD support `identifier`, `patient+type`, `patient+_lastUpdated`, and `patient+discharge-disposition` search parameters and search parameter combinations.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD conform to US Core Observation profile if `Encounter.reasonReference` points to an Observation. | SHOULD conform to US Core Observation profile if `Encounter.reasonReference` points to an Observation.
SHOULD be capable of representing the event facility or location directly when it differs from the location referenced in `Encounter.location`. | SHOULD be capable of representing the event facility or location directly when it differs from the location referenced in `Encounter.location`.
SHOULD update Encounter.meta.lastUpdated to reflect new encounters and changes in the status of encounters. | SHOULD update Encounter.meta.lastUpdated to reflect new encounters, and changes in the status of encounters.
Endpoint | SHOULD support Endpoint resource. | SHOULD2 support Endpoint resource.
SHOULD support `read` and `vread` interactions. | SHOULD support `read` and `vread` interactions.
SHOULD be capable of fetching an Endpoint resource using `GET [base]/Endpoint/[id]`. | SHOULD be capable of returning an Endpoint resource using `GET [base]/Endpoint/[id]`.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
Goal | SHOULD support Goal resource. | SHOULD2 support Goal resource.
SHALL support US Core Goal Profile. | SHALL support US Core Goal Profile.
SHALL support `search-type` and `read` interactions. | SHALL support `search-type` and `read` interactions.
SHALL support both `Goal.startDate` and `Goal.endDate`. | SHALL support at least one of `Goal.startDate` and `Goal.endDate`.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD be capable of fetching a Goal resource using `GET [base]/Goal/[id]`. | SHOULD be capable of returning a Goal resource using `GET [base]/Goal/[id]`.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHALL support `patient` search parameter. | SHALL support `patient` search parameter.
SHOULD support `patient+lifecycle-status`, `patient+description` and `patient+target-date` search parameter combinations. | SHOULD support `patient+lifecycle-status`, `patient+description` and `patient+target-date` search parameter combinations.
HealthcareService | SHOULD support `vread` interaction. | SHOULD support `vread` interaction.
Immunization | SHALL support the US Core Immunization Profile which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core Immunization Profile which has additional requirements, see US Core profile additional requirements.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support NDC vaccine codes as additional codes to CVX vaccine codes, which are required based on the ASTP U.S. Core Data for Interoperability (USCDI) requirements. | SHOULD support NDC vaccine codes as additional codes to CVX vaccine codes, which are required based on the ASTP U.S. Core Data for Interoperability (USCDI) requirements.
Location | SHALL support the US Core Location Profile which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core Location Profile which has additional requirements, see US Core profile additional requirements.
SHALL support the `address` search parameter. | SHALL support the `address` search parameter.
SHOULD support the `vread` and `history-instance` interactions. | SHOULD support the `vread` and `history-instance` interactions.
SHOULD format `Location.address.line` and `Location.address.city` according to the Project US@ Technical Specification for Patient Addresses Final Version 1.0. | SHOULD format `Location.address.line` and `Location.address.city` according to the Project US@ Technical Specification for Patient Addresses Final Version 1.0.
Media | SHOULD support Media resource. | SHOULD2 support Media resource.
SHOULD support `read` and `vread` interactions. | SHOULD support `read` and `vread` interactions.
SHOULD be capable of fetching a Media resource using `GET [base]/Media/[id]`. | SHOULD be capable of returning a Media resource using `GET [base]/Media/[id]`.
Medication | SHALL support the US Core Medication Profile which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core Medication Profile which has additional requirements, see US Core profile additional requirements.
SHOULD support the `vread` and `history-instance` interactions. | SHOULD support the `vread` and `history-instance` interactions.
MedicationDispense | SHOULD support MedicationDispense resource. | SHOULD2 support MedicationDispense resource.
SHALL support US Core MedicationDispense Profile. | SHALL support US Core MedicationDispense Profile.
SHALL support `search-type` and `read` interactions. | SHALL support `search-type` and `read` interactions.
SHALL support `patient` search parameter. | SHALL support `patient` search parameter.
SHALL support representing medication using a code and using a reference to a Medication resource. | SHALL support representing medication using at least one of a code or a reference to a Medication resource.
SHALL support `_include` parameter for `.medicationReference` when referencing an external Medication resource.
SHOULD support `_include=MedicationDispense:medication`. | SHOULD support `_include=MedicationDispense:medication`.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD be capable of fetching a MedicationDispense resource using `GET [base]/MedicationDispense/[id]`. | SHALL be capable of returning a MedicationDispense resource using `GET [base]/MedicationDispense/[id]`.
SHOULD support `patient+status+type` and `patient+status` search parameter combinations. | SHOULD support `patient+status+type` and `patient+status` search parameter combinations.
MedicationRequest | SHALL support the US Core MedicationRequest Profile which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core MedicationRequest Profile which has additional requirements, see US Core profile additional requirements.
SHALL support `patient+intent` and `patient+intent+status` search parameter combinations. | SHALL support `patient+intent` and `patient+intent+status` search parameter combinations.
SHALL support both `MedicationRequest.reportedBoolean` and `MedicationRequest.reportedReference`. | SHALL support at least one of `MedicationRequest.reportedBoolean` and `MedicationRequest.reportedReference`.
SHALL support at least one target resource type in `MedicationRequest.reasonReference`.
SHOULD conform referenced resources in `MedicationRequest.reasonReference` to appropriate US Core profiles. | SHOULD conform referenced resources in `MedicationRequest.reasonReference` to appropriate US Core profiles.
SHOULD interpret the use of `MedicationRequest.requester` with Patient or RelatedPerson indicates a self-prescribed medication. | SHOULD support `patient+intent+encounter` search parameter combination.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD support `patient+intent+encounter` search parameter combination.
Observation | SHOULD2 support Observation profiles, including profiles with additional requirements and additional profiles. | SHOULD2 support Observation profiles, including profiles with additional requirements and additional profiles.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `patient+category+_lastUpdated` search parameter combination. | SHOULD support `patient+category+_lastUpdated` search parameter combination.
SHOULD support `Observation.effectivePeriod` for time-based tests. | SHOULD support `Observation.effectivePeriod` for time-based tests.
Organization | SHALL support the US Core Organization Profile which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core Organization Profile which has additional requirements, see US Core profile additional requirements.
SHALL support `address` search parameter. | SHALL support `address` search parameter.
SHALL support National Provider Identifier (NPI) for organisations. | SHALL support National Provider Identifier (NPI) for organisations.
SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifier for organisations. | SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifier for organisations.
SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for populating Organization.address.line and Organization.address.city. | SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for populating Organization.address.line and Organization.address.city.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
Patient | SHALL support the US Core Patient Profile which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core Patient Profile which has additional requirements, see US Core profile additional requirements.
SHALL support `_id`, `name` and `birthdate+name` search parameter and search parameter combinations. | SHALL support `_id`, `name` and `birthdate+name` search parameter and search parameter combinations.
SHOULD support the `vread` and `history-instance` interactions. | SHOULD support the `vread` and `history-instance` interactions.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHALL support at least `Patient.deceasedDateTime` if supporting `Patient.deceased[x]`. | SHALL support at least `Patient.deceasedDateTime` if supporting `Patient.deceased[x]`.
SHOULD follow the Project US@ Technical Specification for Patient.address.line and Patient.address.city formatting. | SHOULD follow the Project US@ Technical Specification for Patient.address.line and Patient.address.city formatting.
SHOULD NOT use a Social Security Number in `Patient.identifier.value`. | SHOULD NOT use a Social Security Number in `Patient.identifier.value`.
SHALL include a text description when using the Race and Ethnicity complex extensions. | SHALL include a text description when using the Race and Ethnicity complex extensions.
Practitioner | SHALL support the US Core Practitioner which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core Practitioner which has additional requirements, see US Core profile additional requirements.
SHALL support `name` search parameter. | SHALL support `name` search parameter.
SHALL support `Practitioner.address`, regardless of whether the server supports the PractitionerRole resource. | SHALL support `Practitioner.address` if the server does not support the PractitionerRole resource.
SHOULD support `vread` and `history-instance` interactions. | SHALL provide implementation-specific guidance for accessing a provider's location and contact information when only the Practitioner resource is supported.
SHOULD follow the Project US@ Technical Specification for `Practitioner.address.line` and `Practitioner.address.city` formatting. | SHOULD follow the Project US@ Technical Specification for `Practitioner.address.line` and `Practitioner.address.city` formatting.
SHOULD support `vread` and `history-instance` interactions.
SHOULD expose only professional or work contact information to patients. | SHOULD expose only professional or work contact information to patients.
PractitionerRole | SHALL support the US Core PractitionerRole which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core PractitionerRole which has additional requirements, see US Core profile additional requirements.
SHALL support `specialty` search parameter. | SHALL support `specialty` search parameter.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `_include=PractitionerRole:endpoint`. | SHOULD support `_include=PractitionerRole:endpoint`.
SHOULD support `_revinclude=Provenance:target`. | SHOULD support `_revinclude=Provenance:target`.
Procedure | SHALL support both the US Core Procedure and US Core ServiceRequest profiles for communicating the reason for referral or consultation via `Procedure.basedOn`. | SHALL support at least one of target resource types in `Procedure.reasonReference`.
SHOULD ensure that referenced resources in `Procedure.reasonReference` conform to US Core profiles | SHOULD ensure that referenced resources in `Procedure.reasonReference` conform to US Core profiles.
SHALL support both the US Core Procedure and US Core ServiceRequest profiles for communicating the reason for referral or consultation via `Procedure.basedOn`.
SHOULD use `Procedure.focalDevice` with reference to the US Core Implantable Device Profile when applicable. | SHOULD use `Procedure.focalDevice` with reference to the US Core Implantable Device Profile when applicable.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD only use LOINC codes that reflect the actual procedures. | SHOULD only use LOINC codes that reflect the actual procedures.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
Provenance | SHOULD support Provenance resource. | SHOULD2 support Provenance resource.
SHALL support US Core Provenance Profile. | SHALL support US Core Provenance Profile.
SHALL support `read` interaction. | SHALL support `read` interaction.
SHALL support the US Core Provenance Profile for AllergyIntolerance, CarePlan, CareTeam, Condition, Coverage, Device, DiagnosticReport, DocumentReference, Encounter, Goal, Immunization, MedicationDispense, MedicationRequest, Observation, Patient, Procedure, QuestionnaireResponse, RelatedPerson, and ServiceRequest resources. | SHALL support the US Core Provenance Profile for AllergyIntolerance, CarePlan, CareTeam, Condition, Coverage, Device, DiagnosticReport, DocumentReference, Encounter, Goal, Immunization, MedicationDispense, MedicationRequest, Observation, Patient, Procedure, QuestionnaireResponse, RelatedPerson, and ServiceRequest resources.
SHALL provide the organisation as the source when a provider is received in `Provenance.agent.who` as free text. | SHALL provide the organisation as the source when a provider is received in `Provenance.agent.who` as free text.
SHOULD populate the activity when the system needs to know the activity has occurred. | SHOULD populate activity when the system needs to know the activity has occurred.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHALL be capable of fetching a Provenance resource using `GET [base]/Provenance/[id]`. | SHALL be capable of returning a Provenance resource using `GET [base]/Provenance/[id]`.
Questionnaire | SHOULD support Questionnaire resource. | SHOULD support Questionnaire resource.
SHALL support SDC Base Questionnaire Profile. | SHALL support US Core Observation Screening Assessment Profile.
SHOULD support SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile.
SHOULD support `read` and `vread` interactions. | SHOULD support `read` and `vread` interactions.
SHOULD be capable of fetching a Questionnaire resource using `GET [base]/Questionnaire/[id]`. | SHOULD be capable of returning a Questionnaire resource using `GET [base]/Questionnaire/[id]`.
QuestionnaireResponse | SHOULD support QuestionnaireResponse resource. | SHOULD support QuestionnaireResponse resource.
SHALL support US Core QuestionnaireResponse Profile. | SHALL support US Core Observation Screening Assessment Profile.
SHOULD support SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile.
SHOULD support `search-type`, `read`, `vread` and `history-instance` interactions. | SHOULD support `search-type`, `read`, `vread` and `history-instance` interactions.
SHOULD be capable of fetching a QuestionnaireResponse resource using `GET [base]/QuestionnaireResponse/[id]`. | SHOULD be capable of returning a QuestionnaireResponse resource using `GET [base]/QuestionnaireResponse/[id]`.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHALL support `_id` and `patient` search parameters. | SHALL support `_id` and `patient` search parameters.
SHOULD support `patient+authored`, `patient+status` and `patient+questionnaire` search parameter combinations. | SHOULD support `patient+authored`, `patient+status` and `patient+questionnaire` search parameter combinations.
RelatedPerson | SHALL support the US Core RelatedPerson Profile which has additional requirements, see US Core profile additional requirements. | SHALL support the US Core RelatedPerson Profile which has additional requirements, see US Core profile additional requirements.
SHALL support `_id` search parameter. | SHALL support `_id` search parameter.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHOULD support `name` search parameter. | SHOULD support `name` search parameter.
SHOULD follow the Project US@ Technical Specification for `RelatedPerson.address.line` and `RelatedPerson.address.city` formatting. | SHOULD follow the Project US@ Technical Specification for `RelatedPerson.address.line` and `RelatedPerson.address.city` formatting.
ServiceRequest | SHOULD support ServiceRequest resource. | SHOULD2 support ServiceRequest resource.
SHALL support US Core ServiceRequest Profile. | SHALL support US Core ServiceRequest Profile.
SHALL support `search-type` and `read` interactions. | SHALL support `read` interaction.
SHOULD be capable of fetching a ServiceRequest resource using: `GET [base]/ServiceRequest/[id]`. | SHALL be capable of returning a ServiceRequest resource using: `GET [base]/ServiceRequest/[id]`.
SHALL support `_id`, `patient`, `patient+category`, `patient+category+authored`, and `patient+code` search parameters and search parameter combinations. | SHALL support `_id`, `patient`, `patient+category`, `patient+category+authored`, and `patient+code` search parameters and search parameter combinations.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `_revinclude=Provenance:target`. | SHALL support `_revinclude=Provenance:target`.
SHALL support both US Core ServiceRequest and US Core Procedure Profiles for representing the reason for a referral. | SHALL support both US Core ServiceRequest and US Core Procedure Profiles for representing the reason for a referral.
SHALL support both `ServiceRequest.reasonCode` and `ServiceRequest.reasonReference`. | SHALL support at least one of `ServiceRequest.reasonCode` and `ServiceRequest.reasonReference`.
SHALL support all target resource types in `ServiceRequest.reasonReference`. | SHALL support at least one target resource type in `ServiceRequest.reasonReference`.
SHOULD support `patient+status` and `patient+code+authored` search parameter combinations. | SHOULD support `patient+status` and `patient+code+authored` search parameter combinations.
SHALL support querying by ServiceRequest.category. | SHALL support querying by ServiceRequest.category.
SHOULD use US Core Profiles as target references in `ServiceRequest.reasonReference`. | SHOULD use US Core Profiles as target references in `ServiceRequest.reasonReference`.
SHOULD use the corresponding category codes for the USCDI Data Element context, as listed in the US Core ServiceRequest Profile page. | SHOULD use the corresponding category codes for the USCDI Data Element context, as listed in the US Core ServiceRequest Profile page.
SHOULD constrain `ServiceRequest.code` to an appropriate subset for the use case or domain. | SHOULD constrain `ServiceRequest.code` to an appropriate subset for the use case or domain.
SHOULD conform to the value set bindings for `ServiceRequest.code` as listed for each USCDI Order context in the US Core ServiceRequest Profile page. | SHOULD conform to the value set bindings for `ServiceRequest.code` as listed for each USCDI Order context in the US Core ServiceRequest Profile page.
Specimen | SHALL support the US Core Specimen Profile. | SHALL support the US Core Specimen Profile.
SHALL be capable of fetching a Specimen resource using: `GET [base]/Specimen/[id]`. | SHALL be capable of returning a Specimen resource using: `GET [base]/Specimen/[id]`.
SHALL support both `Specimen.identifier` and `Specimen.accessionIdentifier`. | SHALL support at least one of `Specimen.identifier` and `Specimen.accessionIdentifier`.
SHALL support the `_id` search parameter. | SHALL support the `_id` search parameter.
SHALL support `read` interaction. | SHALL support `read` interaction.
SHOULD support `vread` and `history-instance` interactions. | SHOULD support `vread` and `history-instance` interactions.
SHOULD support `patient` search parameter. | SHOULD support `patient` search parameter.
ValueSet | SHOULD support the ValueSet resource. | SHOULD support the ValueSet resource.
SHOULD support the `$expand` operation. | SHOULD support the `$expand` operation.
SHOULD support the `context` and `contextdirection` parameters of the `$expand` operation when supporting DocumentReference for clinical notes.