| Error | CapabilityStatement.url | Values for url differ: 'http://hl7.org/fhir/uv/ipa/CapabilityStatement/ipa-server' vs 'http://hl7.org/fhir/us/core/CapabilityStatement/us-core-server' |
| Error | CapabilityStatement.version | Values for version differ: '1.1.0' vs '9.0.0' |
| Information | CapabilityStatement.name | Values for name differ: 'InternationalPatientAccessAPI' vs 'UsCoreServerCapabilityStatement' |
| Information | CapabilityStatement.title | Values for title differ: 'International Patient Access Server CapabilityStatement' vs 'US Core Server CapabilityStatement' |
| Information | CapabilityStatement.date | Values for date differ: '2023-11-14' vs '2026-04-16' |
| Information | CapabilityStatement.publisher | Values for publisher differ: 'HL7 International / Patient Care' vs 'HL7 International / Cross-Group Projects' |
| 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='SERVER').documentation | Changed value for documentation: 'The IPA Server **SHALL**:
1. Support the IPA Patient resource profile.
1. Support at least one additional resource profile from the list of IPA Profiles.
1. Implement the RESTful behavior according to the FHIR specification.
1. Return the following response classes:
- (Status 400): invalid parameter
- (Status 401/4xx): unauthorized request
- (Status 403): insufficient scope
- (Status 404): unknown resource
1. Support JSON source formats for all IPA interactions.
1. Declare a CapabilityStatement identifying the list of profiles, operations, and search parameters supported.
The IPA Server **SHOULD**:
1. Support XML source formats for all IPA interactions.' vs 'The US Core Server **SHALL**:
1. Support the US Core Patient resource profile AND at least one additional resource profile from the list of US Core Profiles AND and all *Must Support* US Core Profiles and resources it references.
- A summary table listing all the *Must Support* references to other US Core Profiles and FHIR resources for each US Core Profile is located in the [Must Support - Resource References](must-support.html#must-support---resource-references) section of the guide.
1. Follow the narrative requirements documented in the:
- [Conformance](conformance.html) pages
- [Guidance](guidance.html) pages
- Profile Specific Implementation Guidance for each Profile that the US Core Server supports.
The [Server Requirements Table](requirements.html#server-requirements) and [US Core Server Requirements Resource](Requirements-us-core-server.html) and [US Core Certifying System Requirements Resource](Requirements-us-core-certifying-system.html) list the requirements defined in these pages and sections.
1. Return the following response classes:
- (Status 400): invalid parameter
- (Status 401/4xx): unauthorized request
- (Status 403): insufficient scopes
- (Status 404): unknown resource
1. Support JSON source formats for all US Core interactions.
The US Core Server **SHOULD**:
1. Follow the guidance documented in the [General Guidance](general-guidance.html) page
1. Support XML source formats for all US Core interactions.
1. Identify the US Core profiles supported as part of the FHIR `meta.profile` attribute for each instance.
> **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:
> - `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.security.security.description | Changed value for security.description: '1. See the [General Security Considerations](security.html) section for requirements and recommendations.
1. A server **SHALL** reject any unauthorized requests by returning an HTTP `401 Unauthorized`, `403 Forbidden`, or `404 Not Found` response code.' vs '1. See the [General Security Considerations](security.html) section for requirements and recommendations.
1. A server **SHALL** reject any unauthorized requests by returning an `HTTP 401` 'Unauthorized', `HTTP 403` 'Forbidden', or `HTTP 404` 'Not Found'' |
| 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: '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: '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 server **SHOULD** be capable of responding to a $docref operation and capable of returning at least a reference to a CDA document, if available. **MAY** provide references to other 'on-demand' and 'stable' documents (or 'delayed/deferred assembly') that meet the query parameters as well. If a context date range is supplied the server ** SHOULD** provide references to any document that falls within the date range If no date range is supplied, then the server **SHALL** provide references to last or current encounter. **SHOULD** document what resources, if any, are returned as included resources
`GET [base]/DocumentReference/$docref?patient=[id]`' vs 'A server **SHALL** be capable of responding to a $docref operation and capable of returning at least a reference to a generated CCD document, if available. **MAY** provide references to other 'on-demand' and 'stable' documents (or 'delayed/deferred assembly') that meet the query parameters as well. If a context date range is supplied the server ** SHOULD** provide references to any document that falls within the date range. If no date range is supplied, then the server **SHALL** provide references to last or current document(s). **SHOULD** document what resources, if any, are returned as included resources
`GET [base]/DocumentReference/$docref?patient=[id]`' |
| 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: '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: '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: '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.' |