## CapabilityStatement Comparison between http://hl7.org/fhir/uv/ipa/CapabilityStatement/ipa-client vs http://hl7.org/fhir/us/core/CapabilityStatement/us-core-client

### Messages

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 '9.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-12-19T19:16:08.871976-08:00'
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='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 narrative requirements documented in the: - [Conformance](conformance.html) pages - [Guidance](guidance.html) pages - Profile Specific Implementation Guidance for each Profile that the US Core Client supports. The [Client Requirements Table](requirements.html#client-requirements) and [US Core Client Requirements Resource](Requirements-us-core-client.html) list the requirements defined in these pages and sections. > **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.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 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 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: '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.'

### Metadata

Name | Value | Comments
--- | --- | ---
copyright | Used by permission of HL7 International all rights reserved Creative Commons License |  | Removed the item 'Used by permission of HL7 International all rights reserved Creative Commons License'
date | 2023-11-14 | 2025-12-19T19:16:08.871976-08:00 | Values Differ
description | This CapabilityStatement describes the basic rules for the International Patient Access client actor that initiates a data access request to and retrieves patient data from an IPA Responder. In addition, it lists the client conformance expectations for each resource type documented in IPA. These expectations include supported FHIR profiles, RESTful operations, and search parameters. International Patient Access clients define their capabilities by choosing from this list based on the resource types they need to access. | This CapabilityStatement describes the expected capabilities of the US Core Client which is responsible for creating and initiating the queries for information about an individual patient. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Core Servers are defined in the [US Core CapabilityStatement](CapabilityStatement-us-core-server.html). US Core Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. | Values Differ
experimental | false |
fhirVersion | 4.0.1 |
format |  |
format[0] | json |
format[1] | xml |
implementation.description |  |
implementation.url |  |
implementationGuide |  |
implementationGuide[0] | http://hl7.org/fhir/smart-app-launch/ImplementationGuide/hl7.fhir.uv.smart-app-launch |
imports |  |
instantiates |  |
jurisdiction |  |
jurisdiction[0] | http://unstats.un.org/unsd/methods/m49/m49.htm#001 |  | Removed the item 'http://unstats.un.org/unsd/methods/m49/m49.htm#001'
jurisdiction[1] |  | urn:iso:std:iso:3166#US | Added the item 'urn:iso:std:iso:3166#US'
kind | requirements |
name | InternationalPatientAccessClientAPI | UsCoreClientCapabilityStatement | Values Differ
patchFormat |  |
patchFormat[0] | application/json-patch+json |
publisher | HL7 International / Patient Care | HL7 International / Cross-Group Projects | Values Differ
purpose |  |
software.name |  |
software.releaseDate |  |
software.version |  |
status | active |
title | International Patient Access Client CapabilityStatement | US Core Client CapabilityStatement | Values Differ
url | http://hl7.org/fhir/uv/ipa/CapabilityStatement/ipa-client | http://hl7.org/fhir/us/core/CapabilityStatement/us-core-client | Values Differ
version | 1.1.0 | 9.0.0 | Values Differ

### Structure