| Error | CapabilityStatement.url | Values for url differ: 'http://hl7.org/fhir/uv/ipa/CapabilityStatement/ipa-client' vs 'http://hl7.org/fhir/us/core/CapabilityStatement/us-core-client' |
| Error | CapabilityStatement.version | Values for version differ: '1.1.0' vs '8.0.0' |
| Information | CapabilityStatement.name | Values for name differ: 'InternationalPatientAccessClientAPI' vs 'UsCoreClientCapabilityStatement' |
| Information | CapabilityStatement.title | Values for title differ: 'International Patient Access Client CapabilityStatement' vs 'US Core Client CapabilityStatement' |
| Information | CapabilityStatement.date | Values for date differ: '2023-11-14' vs '2025-05-28T12:25:37.725385-08:00' |
| Information | CapabilityStatement.publisher | Values for publisher differ: 'HL7 International / Patient Care' vs 'HL7 International / Cross-Group Projects' |
| Information | CapabilityStatement.copyright | Values for copyright differ: 'Used by permission of HL7 International all rights reserved Creative Commons License' vs 'Used by permission of HL7 International, all rights reserved Creative Commons License' |
| Information | CapabilityStatement.jurisdiction | Removed the item 'http://unstats.un.org/unsd/methods/m49/m49.htm#001' |
| Information | CapabilityStatement.jurisdiction | Added the item 'urn:iso:std:iso:3166#US' |
| Warning | CapabilityStatement.rest.where(mode='CLIENT').documentation | Changed value for documentation: 'The IPA Client **SHALL**:
1. Support the IPA conformance expectations for the Patient resource profile.
1. Support the IPA conformance expectations for each IPA resource type they support
1. Implement the RESTful behavior according to the FHIR specification.
1. Support JSON source formats for all IPA interactions.
The IPA Client **SHOULD**:
1. For the purposes of safety, specify the patient id when searching other resources.' vs 'The US Core Client **SHALL**:
1. 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.
1. Follow the requirements documented in the [General Requirements](general-requirements.html) and [Must Support](must-support.html) pages
**NOTE**: US Core SearchParameters referenced in this CapabilityStatement that are derived from standard FHIR SearchParameters are only defined to document Server and Client expectations. They specify additional expectations for the following SearchParameter elements:B7
- `multipleAnd`
- `multipleOr`
- `comparator`
- `modifier`
- `chain`
They **SHALL NOT** be interpreted as search parameters for search. Servers and Clients **SHOULD** use the standard FHIR SearchParameters.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'active | inactive | resolved' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values. The server **SHALL** support both.' vs 'The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'If the client supports the Condition resource, the client **SHALL** support the IPA profile and the conformance expectations for the Condition resource.
Client applications should be prepared to encounter codes they do not recognize and handle the records
accordingly. Servers SHOULD populate Condition.code.coding.display and/or Condition.code.text so that
clients can always at least display the condition even if they do not know the codes that are used. Clients should be careful making use of the ```code``` search parameter given that the codes used vary so much.
Safety Issues:
* Clients SHALL not treat all conditions as if they are part of the patient's current problem list
* Note that some Condition resources may not have these status codes - this is usually due to poor record keeping reflected in legacy data
* Servers SHOULD avoid leaving these status codes missing
* Clients SHALL pay attention to the ```clinicalStatus``` and ```verificationStatus``` and display and process them correctly * Clients SHALL still work safely when the server does not support all the search parameters listed here.' vs '* For Encounter Diagnosis use the *US Core Condition Encounter Diagnosis Profile*.
* When `Condition.category` is 'encounter-diagnosis' the encounter, **SHOULD** be referenced in `Condition.encounter`.
* For Problems and Health Concerns use the *US Core Condition Problems and Health Concerns Profile*.
* When `Condition.category` is a 'problems-list-item', the `Condition.clinicalStatus **SHOULD** be present.
* There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate Extension, `Condition.onsetDateTime`, or `Condition.recordedDate`.
* Although all three are marked as must support, the server is not required to support all.
* A server **SHALL** support `Condition.recordedDate`.
* A server **SHALL** support at least one of the assertedDate Extension and `Condition.onsetDateTime`. A server may support both, which means they support all three elements.
* The client application **SHALL** support all three elements.
* See the US Core General Guidance page for [Searching Using lastUpdated](general-guidance.html#searching-using-lastupdated). Updates to `Condition.meta.lastUpdated` **SHOULD** reflect:
* New problems and health concerns
* Changes in the clinical status or verifications status of problems or health concern' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The category of the condition' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The clinical status of the condition' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Code for the condition' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Date of onset for the condition' vs 'A client **SHALL** provide a value precise to the *second + time offset*.
A server **SHALL** support a value precise to the *second + time offset*.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values. The server **SHALL** support both.' vs 'The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'If the client supports the DocumentReference resource, the client **SHALL** support the IPA profile and the conformance expectations for the DocumentReference resource.' vs '* For Advance Directive Information (ADI) documents use the *US Core ADI DocumentReference Profile*.
* For other clinical documents use the *US Core DiagnosticReport Profile for Report and Note Exchange*.
* See the [Clinical Notes](clinical-notes.html) page for important definitions, requirements, and guidance on creating, using, and sharing Clinical Notes.
* The `DocumentReference.type` binding Must Support at a minimum the [10 Common Clinical Notes](ValueSet-us-core-clinical-note-type.html) and may extend to the full US Core DocumentReference Type Value Set
* The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using `DocumentReference.attachment.url` or the content as inline base64 encoded data using `DocumentReference.attachment.data`.
* Although both are marked as must support, the server system is not required to support an address, and inline base64 encoded data, but **SHALL** support at least one of these elements.
* The client application **SHALL** support both elements.
* The `content.attachment.url` may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or another endpoint.
* If there are multiple `DocumentReference.content` element repetitions, these **SHALL** all represent the same document in different format or attachment metadata. The content element **SHALL NOT** contain different versions of the same content. For version handling use multiple DocumentReferences with `DocumentReference.relatesTo`
* Every DocumentReference must have a responsible Organization. The organization responsible for the DocumentReference **SHALL** be present either in `DocumentReference.custodian` or accessible in the Provenance resource targeting the DocumentReference using `Provenance.agent.who` or `Provenance.agent.onBehalfOf`.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Categorization of document' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'When this document reference was created' vs 'A client **SHALL** provide a value precise to the *second + time offset*.
A server **SHALL** support a value precise to the *second + time offset*.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Time of service that is being documented' vs 'A client **SHALL** provide a value precise to the *second + time offset*.
A server **SHALL** support a value precise to the *second + time offset*.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'current | superseded | entered-in-error' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Kind of document (LOINC if possible)' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The client **SHALL** provide at least an id value and **MAY** provide both the Type and id values. The server **SHALL** support both.' vs 'The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'A client **SHOULD** be capable of transacting a $docref operation and capable of accessing the document using the using the link provided in the `DocumentReference.content.attachment.url` element.' vs 'A client **SHOULD** be capable of transacting a $docref operation and capable of receiving at least a reference to a generated CCD document, and **MAY** be able to receive other document types, if available. **SHOULD** be capable of receiving documents as included resources in response to the operation.
`GET [base]/DocumentReference/$docref?patient=[id]`' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'If the client supports the Immunization resource, the client **SHALL** support the IPA profile and the conformance expectations for the Immunization resource.' vs '* Based upon the ASTP U.S. Core Data for Interoperability (USCDI) requirements, CVX vaccine codes are required and the NDC vaccine codes **SHOULD** be supported as an additional code.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Vaccination (non)-Administration Date' vs 'A client **SHALL** provide a value precise to the *second + time offset*.
A server **SHALL** support a value precise to the *second + time offset*.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Immunization event status' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The client **SHALL** provide at least an id value and **MAY** provide both the Type and id values. The server **SHALL** support both.' vs 'The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'If the client supports the the MedicationStatement or MedicationRequest resource, the client **SHALL** support the IPA profile and the conformance expectations for the Medication resource.' vs '* The MedicationRequest resource can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationRequest, then the READ **SHALL** be supported.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'If the client supports the MedicationRequest resource, the client **SHALL** support the IPA profile and the conformance expectations for the MedicationStatement, MedicationRequest and Medication resource.
Clients SHALL query for both MedicationStatement and MedicationRequest when fetching patient Medication information.
The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be [contained](http://hl7.org/fhir/R4/references.html#contained) or an external resource. The server application **MAY** choose any one way or more than one method, but if an external reference to Medication is used, the server **SHALL** support the `_include` parameter for searching this element. The client application **SHALL** support all methods. For example, A server **SHALL** be capable of returning all medications for a patient using one of or both:
`GET /MedicationStatement?patient=[id]`
`GET
/MedicationStatement?patient=[id]&_include=MedicationStatement:medication`
When representing a prescribed medication, servers SHOULD use codings at the level of a clinical drug rather than ingredient or dose form (e.g. 'loratadine 10mg oral tablet', rather than a bare ingredient like 'loratadine' or a dose form like 'loratadine oral tablet').' vs '* This Profile can represent a medication using a code or reference a Medication resource.
* The Server systems are not required to support both a code and a reference, but **SHALL** support at least one of these methods.
* The Client application **SHALL** support all methods.
* Systems that primarily rely on NDC codes instead of RxNorm to represent medications can use the National Library of Medicine's (NLM) NDC to RxNorm mappings to aid in additional codings.
* When referencing a Medication resource in `.medicationReference`, the resource may be contained or an external resource. If an external reference to a Medication resource is used, the Server **SHALL** support the `_include` parameter for searching this element.
* The MedicationRequest resource can represent that information is from a secondary source using either a boolean flag or reference in `MedicationRequest.reportedBoolean`, or a reference using `MedicationRequest.reportedReference` to Practitioner or other resource.
* Although both are marked as must support, the server systems are not required to support both a boolean and a reference, but **SHALL** choose to support at least one of these elements.
* The client application **SHALL** support both elements.
* When recording “self-prescribed” medication, requester **SHOULD** be used to indicate the Patient or RelatedPerson as the prescriber. (See the Medication List section for guidance on accessing a patient medications including over the counter (OTC) medication and other substances taken for medical and recreational use.)
* The MedicationRequest resource can communicate the reason or indication for treatment using either a code in MedicationRequest.reasonCode or a reference using MedicationRequest.reasonReference.
* Although both `MedicationRequest.reasonCode` and `MedicationRequest.reasonReference` are marked as Additional USCDI Requirements. The certifying server system is not required to support both but **SHALL** support at least one of these elements. The certifying client application **SHALL** support both elements.
* when using MedicationRequest.reasonReference:
* Servers **SHALL** support at least one target resource in `MedicationRequest.reasonReference`. Clients **SHALL** support all target resources.
* The referenced resources **SHOULD** be a US Core Profile as documented in Referencing US Core Profiles.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Returns prescriptions written on this date' vs 'A client **SHALL** provide a value precise to the *second + time offset*.
A server **SHALL** support a value precise to the *second + time offset*.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Return prescriptions with this encounter identifier' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Status of the prescription' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The client **SHALL** provide at least an id value and **MAY** provide both the Type and id values. The server **SHALL** support both.' vs 'The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'If the client supports the Observation resource, the client **SHALL** support the IPA profile and the conformance expectations for the Observation resource.' vs '* Systems **SHOULD** support `Observation.effectivePeriod` to accurately represent tests that are collected over a period of time (for example, a 24-Hour Urine Collection test).
* An Observation without a value, **SHALL** include a reason why the data is absent unless there are component observations, or references to other Observations that are grouped within it
* Systems that never provide an observation without a value are not required to support `Observation.dataAbsentReason`
* An `Observation.component` without a value, **SHALL** include a reason why the data is absent.
* Systems that never provide an component observation without a component value are not required to support `Observation.component.dataAbsentReason`.
* There are multiple Observation profiles. Refer to the specific profile page for profile specific conformance rules and guidance ' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The classification of the type of observation' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The code of the observation type' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Obtained date/time. If the obtained element is a period, a date that falls in the period' vs 'A client **SHALL** provide a value precise to the *second + time offset*.
A server **SHALL** support a value precise to the *second + time offset*.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The status of the observation' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The client **SHALL** provide at least an id value and **MAY** provide both the Type and id values. The server **SHALL** support both.' vs 'The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'Client applications SHALL be able to access the patient record using the following API call:
`GET [url]/Patient/[id]`
Client application MAY use these search parameters that servers are required to support to access the patient record:
- `_id`
- `identifier`
Servers are not required to support any additional search parameters, and clients SHOULD not expect servers to do so.
Additional rules and guidance for supporting `Patient.link`:
- The server:
- SHALL have no more than one Patient with a status of active = 'true' *from the server being queried*
- MAY include inactive patients on the *same server*
- MAY include inactive or active patients from a *different server*
- When returning a [search Bundle](http://hl7.org/fhir/bundle.html) that contains more than one Patient record for the same patient, the Patient record(s) SHALL use the `Patient.link` attribute to cross-link the Patient resources.
- The client:
- SHALL be able to follow the link(s) to the other Patient resource(s) and understand the direction of the link (in other words, which Patient is linked to which other Patient)
- SHALL understand the `Patient.link.type` code which defines the type of link between this Patient resource and another Patient resource
- SHALL be aware of the linked Patient `active` flag and that inactive patients may have relevant information' vs '* The Patient's Social Security Numbers **SHOULD NOT** be used as a patient identifier in `Patient.identifier.value`.
* The Complex Extensions for Race and Ethnicity allow for one or more codes of which: Must Support at least one category code from the OMB Race and Ethnicity Category Value Sets that draw from the Race & Ethnicity - CDC (CDCREC] code system.
- **MAY** include additional codes from the detailed ethnicity and detailed race value sets drawn from the Race & Ethnicity - CDC (CDCREC) code system
- **SHALL** include a text description
* Although Patient.deceased[x] is marked as 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜, certifying systems are not required to support both choices, but **SHALL** support at least `Patient.deceasedDateTime`.
* Servers can use the US Core Interpreter Needed Extension on this profile or the US Core Encounter Profile to communicate whether a patient needs an interpreter. Although the extension is marked as an *Additional USCDI Requirement* on both US Core Patient and US Core Encounter Profiles, the certifying Server system is not required to support the extension on both profiles but **SHALL** support the extension on at least one. The certifying Client application **SHALL** support the extension on both profiles.
- Systems **SHOULD** designate the patient's preferred language in the `Patient.communication.preferred` element.
* Certifying systems **SHALL** and non-certifying systems **SHOULD** follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for `Patient.address.line` and `Patient.address.city` for new and updated records.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'A client **SHALL** provide a value precise to the *day*. A server **SHALL** support a value a value precise to the *day*.' vs 'A client **SHALL** provide a value precise to the *day*.
A server **SHALL** support a value a value precise to the *day*.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'The client **SHALL** provide both the system and code values. The server **SHALL NOT** support only code values.' vs 'The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.
The server **SHALL** support both.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'If the client supports the Practitioner resource, the client **SHALL** support the IPA profile and the conformance expectations for the Practitioner resource.' vs '* Servers that support only US Core Practitioner Profile and do not support the US Core PractitionerRole Profile **SHALL** provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.
* Although Practitioner.address is marked as Must Support, the server system is not required to support it if they support the US Core PractitionerRole Profile, but **SHALL** support it if they do not support the US Core PractitionerRole Profile. The client application **SHALL** support both.
* To balance the privacy of healthcare workers with the patient's right to access information. Only professional/work contact information about the practitioner **SHOULD** be available to the patient (such as a work address or office telephone number).
* Systems **SHOULD** follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for `Practitioner.address.line` and `Practitioner.address.city`.' |
| Information | CapabilityStatement.rest.resource.documentation | Changed value for documentation: 'If the client supports the PractitionerRole resource, the client **SHALL** support the IPA profile and the conformance expectations for the PractitionerRole resource.' vs '* Due to implementer feedback, some US Core Profiles reference the PractitionerRole resource instead of the US Core PractitionerRole Profile. However the US Core PractitionerRole Profile **SHOULD** be used as the default profile if referenced by another US Core profile.' |
copyright
format[0]
format[1]