| Name | Source | Ver | Description |
| ADI CapabilityStatement | hl7.fhir.us.pacio-adi#current | R4 | This Section describes the expected capabilities of the PACIO Advance Directive Interoperability (ADI) Server actor which is responsible for providing responses to the queries submitted by the ADI Requestors. There are two primary vehicles in which Advance Directive Information can be conveyed: DocumentReference and Bundle. Through a DocumentReference, the ADI may be encoded inside directly as content data or referred to through a content reference (pointing to the ADI included in a resource like Binary) or reference a Bundle with the type=document for FHIR encoded data. The resources referred to by the Composition in the document bundle include Patient, Observation,Goal, ServiceRequest, Organization, RelatedPerson, Consent, List, and Provenance. |
| App State Server CapabilityStatement | hl7.fhir.uv.smart-app-launch#current | R4 | Required capabilities for App State Server |
| Argonaut Adaptive Questionnaire Service CapabilityStatement | fhir.argonaut.questionnaire#1.0.0 | R3 | This section outlines conformance requirements for the Argonaut Questionnaire Adaptive QuestionService. It is responsible for providing questions in response to requests and determining the next question and calculation of the score for an Adaptive Questionnaires. It supports the Argonaut Adaptive QuestionnaireResponse Profile and the transactions associated with the adaptive questionnaires. Note that the Argonaut Profile and next-question OperationDefinition identify the structural constraints, terminology bindings and invariants. |
| Argonaut Answerbank CapabilityStatement | fhir.argonaut.questionnaire#1.0.0 | R3 | This section outlines conformance requirements for the Argonaut Questionnaire Answer Bank Server. It is responsible for storing QuestionnairesResponses and providing responses to the requests submitted by the Provider EHRs. The Argonaut QuestionnaireResponse Profile and Argonaut Adaptive QuestionnaireResponse Profiles and the various interactions outlined in this guide are the RESTful artifacts and interactions that it supports. Note that the Argonaut Profiles identify the structural constraints, terminology bindings and invariants and the individual Argonaut SearchParameter resources define the definitions, comparators, modifiers and usage constraints. |
| Argonaut Argo Questionnaire Provider Ehr CapabilityStatement | fhir.argonaut.questionnaire#1.0.0 | R3 | This section outlines conformance requirements for the Argonaut Questionnaire Provider EHR. It may be responsible for retrieving, rendering and displaying both static and adaptive Questionnaires and QuestionnairesResponses. The Argonaut Questionnaire Profile, Argonaut QuestionnaireResponse Profile and Argonaut Adaptive QuestionnaireResponse Profiles and all the interactions outlined in this guide are the RESTful artifacts and interactions that it supports. Note that the Argonaut Profiles identify the structural constraints, terminology bindings and invariants and the individual Argonaut SearchParameter resources define the definitions, comparators, modifiers and usage constraints. |
| Argonaut Assessmentbank CapabilityStatement | fhir.argonaut.questionnaire#1.0.0 | R3 | This section outlines conformance requirements for the Argonaut Questionnaire Assessment-Bank Server. It is responsible for storing Questionnaires and providing responses to the requests submitted by the Form Author/Editor and Provider EHRs. The Argonaut Questionnaire Profile and the various interactions outlined in this guide are the RESTful artifacts and interactions that it supports. Note that the Argonaut Profiles identify the structural constraints, terminology bindings and invariants and the individual Argonaut SearchParameter resources define the definitions, comparators, modifiers and usage constraints. |
| Argonaut Clinical Notes CapabilityStatement | fhir.argonaut.clinicalnotes#1.0.0 | R3 | This profile defines the expected capabilities of an Argonaut Data Query server when conforming to the Argonaut Data Query Clinical Notes IG. The CapabilityStatement resource includes the complete list of actual Clinical Notes profiles, RESTful operations, and search parameters supported by Argonaut Data Query Servers. Servers have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Argonaut Clinical Notes Client CapabilityStatement | fhir.argonaut.clinicalnotes#1.0.0 | R3 | This profile defines the expected capabilities of an Argonaut Data Query Client when conforming to the Argonaut Clinical Notes IG. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Argonaut Servers are defined in the Capability Statements for Server. |
| Argonaut Provider Directory Client | fhir.argonaut.pd#1.0.0 | R3 | This profile defines the expected capabilities of a client when conforming to the Argonaut Provider Directory Implementation Guide. |
| Argonaut Provider Directory Server | fhir.argonaut.pd#1.0.0 | R3 | This profile defines the expected capabilities of a server when conforming to the Argonaut Provider Directory Implementation Guide. |
| Argonaut Scheduling Client CapabilityStatement | fhir.argonaut.scheduling#1.0.0 | R3 | The Argonaut Scheduling Client CapabilityStatement provides a for a complete list of supported RESTful interactions for the Argonaut Scheduling Implementation Guide |
| Argonaut Scheduling Server CapabilityStatement | fhir.argonaut.scheduling#1.0.0 | R3 | The Argonaut Scheduling Server CapabilityStatement provides a for a complete list of supported RESTful interactions for the Argonaut Scheduling Implementation Guide |
| AU Core Client CapabilityStatement | hl7.fhir.au.core#current | R4 | This CapabilityStatement describes the basic rules for the AU Core server actor that is responsible for providing responses to queries submitted by AU Core clients. The complete list of FHIR profiles, RESTful operations, and search parameters supported by AU Core servers are defined in this CapabilityStatement. |
| AU Core Server CapabilityStatement | hl7.fhir.au.core#current | R4 | This CapabilityStatement describes the basic rules for the AU Core server actor that is responsible for providing responses to queries submitted by AU Core clients. The complete list of FHIR profiles, RESTful operations, and search parameters supported by AU Core servers are defined in this CapabilityStatement. |
| BackportSubscriptionCapabilityStatement | hl7.fhir.uv.subscriptions-backport.r4b#1.1.0 | R4B | CapabilityStatement describing the required and optional capabilities of a FHIR Server supporting backported R5 Subscriptions in R4B. |
| BackportSubscriptionCapabilityStatementR4 | hl7.fhir.uv.subscriptions-backport.r4b#1.1.0 | R4B | CapabilityStatement describing the required and optional capabilities of a FHIR Server supporting backported R5 Subscriptions in R4. |
| Base AdverseEvent Clinical Research Profile Capability Statement | hl7.fhir.uv.ae-research-backport-ig#current | R4 | This is a starting point requirements capability statement for the AdverseEvent Clinical Research Profile. It is expected that specific use cases will lead to further specification in derived IGs. |
| Base AdverseEvent Clinical Research Profile Capability Statement | hl7.fhir.uv.ae-research-ig#current | R5 | This is a starting point requirements capability statement for the AdverseEvent Clinical Research Profile. It is expected that specific use cases will lead to further specification in derived IGs. |
| Behandelplan | hl7.fhir.nl.zorgviewer#current | R3 | Deze CapabilityStatement beschrijft de minimale requirements voor het Behandelplan Bouwblok. |
| C4BB CapabilityStatement | hl7.fhir.us.carin-bb#current | R4 | This Section describes the expected capabilities of the C4BB Server actor which is responsible for providing responses to the queries submitted by the C4BB Requestors. The EOB Resource is the focal Consumer-Directed Payer Data Exchange (CDPDE) Resource. Several Reference Resources are defined directly/indirectly from the EOB: Coverage, Patient, Organization (Payer ID), Practioner, and Organization (Facility). The Coverage Reference Resource SHALL be returned with data that was effective as of the date of service of the claim; for example, the data will reflect the employer name in effect at that time. However, for other reference resources, payers MAY decide to provide either the data that was in effect as of the date of service or the current data. All reference resources within the EOB will have meta.lastUpdated flagged as must support. Payers SHALL provide the last time the data was updated or the date of creation in the payers system of record, whichever comes last. Apps will use the meta.lastUpdated values to determine if the reference resources are as of the current date or date of service. |
| C4DIC CapabilityStatement | hl7.fhir.us.insurance-card#current | R4 | This Section describes the expected capabilities of the C4DIC Server actor which is responsible for providing responses to the queries submitted by the C4DIC Requestors. |
| Capability Statement Basic Federated Endpoint Server | hl7.fhir.us.directory-query#current | R4 | Capabilities for a basic Query Server for Health Services where Endpoint search capabilities are met |
| Capability Statement Basic Federated Expanded Server | hl7.fhir.us.directory-query#current | R4 | Capabilities for a Basic Federated Query Server for where expanded search capabilities are met |
| Capability Statement BSeR | hl7.fhir.us.bser#current | R4 | This resource defines the expected capabilities for both client and server participating in BSeR exchange |
| Capability Statement eCR | hl7.fhir.us.ecr#current | R4 | This resource defines the expected capabilities for both client and server participating in eCR exchange. |
| Capability Statement eRSD Client | hl7.fhir.us.ecr#current | R4 | This section describes the expected capabilities of a client consuming eRSD resources including the Reportable Conditions Trigger Codes (RCTC). #### Conformance requirements for an eRSD Client The eRSD Client **SHALL**: - Support fetching the eRSD Bundle using the supported RESTful interactions. - Support processing PlanDefinition and ValueSet resources that are included in the Bundle. The eRSD Client **MAY**: - Support fetching and reading a Person resource. - Support fetching and reading Subscription resources associated with a Person. |
| Capability Statement Health or Human Services Federated Endpoint Server | hl7.fhir.us.directory-query#current | R4 | Capabilities for a Federated Query Server for Health or Human Services where endpoint search capabilities are met |
| Capability Statement Health or Human Services Federated Expanded Server | hl7.fhir.us.directory-query#current | R4 | Capabilities for a Federated Query Server for Health or Human Services where expanded search capabilities are met |
| Capability Statement Human Services Federated Endpoint Server | hl7.fhir.us.directory-query#current | R4 | Capabilities for a Federated Query Server for Health Services where endpoint search capabilities are met |
| Capability Statement Human Services Federated expanded Server | hl7.fhir.us.directory-query#current | R4 | Capabilities for a Federated Query Server for Health Services where expanded search capabilities are met |
| Capability Statement National Directory | hl7.fhir.us.directory-exchange#current | R4 | Capabilities for a validated national directory server |
| Capability Statement Provider Federated Endpoint Server | hl7.fhir.us.directory-query#current | R4 | Capabilities for a Federated Query Server for a Provider where endpoint search capabilities are met |
| Capability Statement Provider Federated Expanded Server | hl7.fhir.us.directory-query#current | R4 | Capabilities for a Federated Query Server for a Provider where minimum search capabilities are met |
| CapabilityStatement - Birth and Fetal Death | hl7.fhir.us.bfdr#current | R4 | This section describes the expected capabilities of a BFDR Document producer actor who is responsible for producing clinical documents and a BFDR Document consumer who receives and consumes the clinical documents. |
| CapabilityStatement - Electronic Death Reporting System (EDRS) Server | hl7.fhir.us.mdi#current | R4 | This resource describes the expected capabilities of the Electronic Death Registration System (EDRS) Server actor, which is responsible for providing responses to the queries submitted by the EDRS Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by EDRS Servers are defined. EDRS Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| CapabilityStatement - Forensic Toxicology Laboratory Server | hl7.fhir.us.mdi#current | R4 | This resource describes the expected capabilities of the toxicology lab Server actor which is responsible for providing responses to the queries submitted by toxicology lab Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by toxicology lab Servers are defined. toxicology lab Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| CapabilityStatement - MDI CMS Server | hl7.fhir.us.mdi#current | R4 | This resource describes expected capabilities of an MDI CMS Server which is responsible for providing responses to the queries submitted by a Client. It lists FHIR profiles and search parameters that, at a minimum, should be supported by MDI CMS Servers. MDI CMS Clients have the option of choosing from this list to access necessary data. |
| CapabilityStatement - Medical Examiner/Coroner Server | hl7.fhir.us.mdi#current | R4 | This resource describes the expected capabilities of an MDI CMS Server actor which is responsible for providing responses to the queries submitted by the MDI CMS Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by MDI CMS Servers are defined. MDI CMS Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| CapabilityStatement for custodian of catalog of laboratory in vitro diagnostic services | hl7.fhir.uv.order-catalog#current | R5 | This Section describes the expected capabilities of the Custodian of a catalog of laboratory in vitro diagnostic services. This role is responsible for providing responses to the queries submitted by the catalog consumers. The PlanDefinition Resource is the focal Resource for describing a laboratory in vitro diagnostic service in the catalog. |
| CapabilityStatement for custodian of catalog of medical devices | hl7.fhir.uv.order-catalog#current | R5 | This Section describes the expected capabilities of the Custodian of a catalog of medical devices. This role is responsible for providing responses to the queries submitted by the catalog consumers. The DeviceDefinition Resource is the focal Resource describing a model of device in the catalog. |
| CapabilityStatement for custodian of catalog of medications | hl7.fhir.uv.order-catalog#current | R5 | This Section describes the expected capabilities of the Custodian of a catalog of medications. This role is responsible for providing responses to the queries submitted by the catalog consumers. The MedicationKnowledge Resource is the focal Resource gathering all knowledge and information details about a medication in the catalog. |
| CapabilityStatement Lower Extremity Skin Wound Assessment - Client | hl7.fhir.us.lower-extremity-skin-wound-assessment#current | R4 | This resource defines the expected capabilities of a FHIR client system that implements the Lower Extremity Skin Wound Assessment Implementation Guide. (This CapabilityStatement is incomplete and pending completion once trial implementations and testing have been done.) |
| CapabilityStatement Lower Extremity Skin Wound Assessment - Server | hl7.fhir.us.lower-extremity-skin-wound-assessment#current | R4 | This resource defines the expected capabilities of a FHIR server system that implements the Lower Extremity Skin Wound Assessment Implementation Guide. (This CapabilityStatement is incomplete and pending completion once trial implementations and testing have been done.) |
| CCDA on FHIR Client | hl7.fhir.us.ccda#current | R4 | This section describes the expected capabilities of the C-CDA on FHIR Document Consumer (aka client) actor which is responsible for creating and initiating the queries for clinical documents provided by a C-CDA on FHIR Document Source (aka server) actors. This CapabilityStatement imports and extends the [us-core-client CapabilityStatement](https://www.hl7.org/fhir/us/core/CapabilityStatement-us-core-client.html) |
| CCDA on FHIR Server | hl7.fhir.us.ccda#current | R4 | This section describes the expected capabilities of the C-CDA on FHIR Document Source (aka server) actor which is responsible for responding to the queries for clinical documents provided by a C-CDA on FHIR Document Consumer (aka client) actor. This CapabilityStatement imports and extends the [us-core-server CapabilityStatement](https://www.hl7.org/fhir/us/core/CapabilityStatement-us-core-server.html) |
| Cdmh EHR Capability Statement | hl7.fhir.us.cdmh#current | R4 | This profile defines the expected capabilities of the ''EHR'' actor when conforming to the CDMH IG. This role is responsible for allowing creation and retrieval of ResearchStudy, and Group resources, along with retrieval of clinical data using the Group/$export operation. |
| Central Cancer Registry Reporting EHR Capability Statement | hl7.fhir.us.central-cancer-registry-reporting#current | R4 | This profile defines the expected capabilities of the ''EHR'' actor when conforming to the Central Cancer Registry Reporting Content IG. This role is responsible for allowing creation, modification and deletion of Subscriptions and allows searching and retrieval of resources using US Core APIs. |
| Central Cancer Registry Reporting Pathology EHR Capability Statement | hl7.fhir.us.cancer-reporting#current | R4 | This profile defines the expected capabilities of the ''EHR'' actor when conforming to the Cancer Pathology Data Sharing IG. This role is responsible for allowing creation, modification and deletion of ServiceRequests that represent the request for Pathological analysis (and associated reports), and allows searching and retrieval of resources using US Core APIs. |
| Client | hl7.fhir.uv.immds#0.2.0 | R4 | This resource defines the expected capabilities of an Immunization Decision Support Forecast client. |
| CodeX RT Server CapabilityStatement | hl7.fhir.us.codex-radiation-therapy#current | R4 | CodeX RT Server CapabilityStatement |
| Consumer Client CapabilityStatement | hl7.fhir.us.davinci-deqm#current | R4 | This profile defines the expected capabilities of a Da Vinci DEQM Consumer Client when conforming to the Da Vinci DEQM Implementation Guide. Consumers include systems that are primary consumers of patient healthcare information and systems that consume data from Producers. This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci DEQM profiles and RESTful operations that a Da Vinci DEQM Consumer Client could support. Clients have the option of choosing from this list based on their local use cases and other contextual requirements. |
| Consumer Server CapabilityStatement | hl7.fhir.us.davinci-deqm#current | R4 | This profile defines the expected capabilities of a Da Vinci DEQM Consumer Server when conforming to the Da Vinci DEQM Implementation Guide. Consumers include systems that are primary consumers of patient healthcare information and systems that consume data from Producers. This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci DEQM profiles and RESTful operations that a Da Vinci DEQM Consumer Server could support. Servers have the option of choosing from this list based on their local use cases and other contextual requirements. |
| CPG Common Patient Registry | hl7.fhir.uv.cpg#current | R4 | Describes the expected set of functionality required for a patient registry service that supports the common registration process defined in this implementation guide. |
| CQF Measures Authoring Measure Repository Capability Statement | hl7.fhir.us.cqfmeasures#current | R4 | Capability statement for a repository service supporting additional authoring and content workflow capabilities for FHIR-based measure specifications above the basic ShareableMeasureRepository. |
| CQF Measures Authoring Measure Repository Capability Statement | hl7.fhir.uv.cmi#current | R4 | Capability statement for a repository service supporting additional authoring and content workflow capabilities for FHIR-based measure specifications above the basic ShareableMeasureRepository. |
| CQF Measures Publishable Measure Repository Capability Statement | hl7.fhir.us.cqfmeasures#current | R4 | Capability statement for a repository service supporting additional publishing capabilities for FHIR-based measure specifications above the basic ShareableMeasureRepository. |
| CQF Measures Publishable Measure Repository Capability Statement | hl7.fhir.uv.cmi#current | R4 | Capability statement for a repository service supporting additional publishing capabilities for FHIR-based measure specifications above the basic ShareableMeasureRepository. |
| CQF Measures Shareable Measure Repository Capability Statement | hl7.fhir.uv.cmi#current | R4 | Capability statement for a repository service supporting minimum required capabilities to share FHIR-based measure specifications. See the Publishable and Authoring Measure Repository capability statements for more comprehensive support for publishing and authoring workflows. |
| CQF Measures Shareable Measure Repository Capability Statement | hl7.fhir.us.cqfmeasures#current | R4 | Capability statement for a repository service supporting minimum required capabilities to share FHIR-based measure specifications. See the Publishable and Authoring Measure Repository capability statements for more comprehensive support for publishing and authoring workflows. |
| CRD Client | hl7.fhir.us.davinci-crd#current | R4 | This statement defines the expected capabilities of systems wishing to conform to the ''CRD Client'' role. This role is responsible for initiating CDS Hooks calls and consuming received decision support. It is *also* responsible for returning data requested by the CRD Server needed to provide that decision support. This capability statement doesn't define the CDS Hooks capabilities as there is no standard way to do that as yet. Instead, it focuses on the 'server' capabilities needed to respond to CRD Server queries. These capabilities are based on US Core. In addition to the U.S. core expectations, the CRD Client **SHALL** support all 'SHOULD' 'read' and 'search' capabilities listed below for resources referenced in supported hooks and order types if it does not support returning the associated resources as part of CDS Hooks pre-fetch. The CRD Client **SHALL** also support 'update' functionality for all resources listed below where the client allows invoking hooks based on the resource. |
| CRD Server | hl7.fhir.us.davinci-crd#current | R4 | This statement defines the expected capabilities of systems wishing to conform to the ''CRD Server'' role. This role is responsible for responding to CDS Hooks calls and responding with appropriate decision support. Much of its interactions will be with payer back-end systems over non-FHIR protocols. This CapabilityStatement does not describe these 'server <-> payer' interactions. Instead, it focuses on the ability of the CRD service to interact with the CRD client's FHIR endpoint to retrieve additional data. All such interactions are optional, as their necessity is dependent on what types of information is needed to support payer rules, the types of coverage the payer offers, and the degree of sophistication of the decision support offered by the CRD server. All resources and search parameters supported by US Core are fair game, though [[CapabilityStatement-crd-client|client endpoints]] might vary in which resources they support. |
| CRMI Artifact Terminology Service | hl7.fhir.uv.crmi#current | R4 | Capability statement for a terminology service supporting artifact authoring and evaulation use cases. A server can support more functionality than defined here, but this defines the minimum expectations. |
| CRMI Authoring Artifact Repository | hl7.fhir.uv.crmi#current | R4 | Capability statement for a repository service supporting additional authoring and content workflow capabilities for FHIR-based knowledge artifacts above the basic ShareableArtifactRepository. |
| CRMI Publishable Artifact Repository | hl7.fhir.uv.crmi#current | R4 | Capability statement for a repository service supporting additional publishing capabilities for FHIR-based knowledge artifacts above the basic ShareableArtifactRepository. |
| CRMI Shareable Artifact Repository | hl7.fhir.uv.crmi#current | R4 | Capability statement for a repository service supporting minimum required capabilities to share FHIR-based artifact specifications. See the Publishable and Authoring Artifact Repository capability statements for more comprehensive support for publishing and authoring workflows. |
| Data Consumer Client CapabilityStatement | hl7.fhir.us.davinci-cdex#current | R4 | This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Consumer in *Client* mode when requesting clinical data from the Data Source during clinical data exchange. The capabilities include one or more of the following interactions: 1. Requesting and Fetching Clinical Data using a FHIR RESTful query 2. Requesting and Fetching Clinical Data using a Task-based query including: - Polling or Subscribing for Task update notifications 3. Requesting Attachments - Requesting Attachments Using Attachments Codes - Requesting Attachments Using Questionnaires |
| Data Consumer Server CapabilityStatement | hl7.fhir.us.davinci-cdex#current | R4 | This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Consumer in *Server* mode when responding to a Data Source or one of its proxies during clinical data exchange. The capabilities include one or more of the following interactions: 1. Responding to a query for authorization information represented by a CommunicationRequest or ServiceRequest 1. Responding to the `$submit-attachment` operation. |
| Data Mart | hl7.fhir.us.daf#2.0.0 | R3 | This profile defines the expected capabilities of the Data Mart actor when conforming to the DAF-Research IG. |
| Data Source | hl7.fhir.us.daf#2.0.0 | R3 | This profile defines the expected capabilities of the Data Source actor when conforming to the DAF-Research IG. |
| Data Source Client CapabilityStatement | hl7.fhir.us.davinci-cdex#current | R4 | This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Source in *Client* mode during clinical data exchange with a Data Consumer. The capabilities include one or more of the following interactions: 1. Post the `$submit-attachment` operation to a Data Consumer endpoint. 2. Launch Da Vinci DTR. 3. Query for Authorization information represented by a CommunicationRequest or ServiceRequest. 4. Post a subscription notification to a Data Consumer endpoint updating the status of a task. |
| Data Source implementing the Compute Measure transaction. | hl7.fhir.uv.saner#current | R4 | Defines the requirements for the Data Source implementing the Compute Measure transaction. |
| Data Source Server CapabilityStatement | hl7.fhir.us.davinci-cdex#current | R4 | This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Source in *Server* mode when responding to a Data Consumer during clinical data exchange. The capabilities include one or more of the following interactions: 1. Responding to a FHIR RestFul Query for Clinical Data 2. Responding to a Task-based query request for clinical data including: - Polling or Subscription requests for Task update notifications 1. Responding to - Requesting Attachments Using Attachments Codes - Requesting Attachments Using Questionnaires |
| Data Source. | hl7.fhir.uv.saner#current | R4 | Defines the requirements for the Data Source. |
| DaVinci ATR Consumer | hl7.fhir.us.davinci-atr#current | R4 | This profile defines the expected capabilities of the ''Consumer'' role when conforming to the DaVinci Risk Based Contracts Member Attribution List Implementation Guide. This role is responsible for retrieving and using the Member Attribution List for DaVinci use cases such as CDex, PDex. The Member Attribution List can be used for other purposes also. |
| DaVinci ATR Producer | hl7.fhir.us.davinci-atr#current | R4 | This profile defines the expected capabilities of the ''Producer'' role when conforming to the DaVinci Risk Based Contracts Member Attribution List Implementation Guide. This role is responsible for creating and publishing the Member Attribution List for usage by Consumers based on specific Risk Based Contracts. |
| Dental Data Exchange Client | hl7.fhir.us.dental-data-exchange#current | R4 | This section describes the expected capabilities of the Dental Data Exchange Document Consumer (aka client) actor which is responsible for creating and initiating the queries for clinical documents provided by a Dental Data Exchange Document Source (aka server) actors. This CapabilityStatement imports and extends [CCDAonFHIR-client CapabilityStatement](http://hl7.org/fhir/us/ccda/CapabilityStatement-CcdaOnFhirClient.html)CCDAonFHIR client CapabilityStatement, which imports and extends the [us-core-client CapabilityStatement](https://www.hl7.org/fhir/us/core/CapabilityStatement-us-core-client.html) |
| Dental Data Exchange Server | hl7.fhir.us.dental-data-exchange#current | R4 | This section describes the expected capabilities of the Dental Data Exchange Document Source (aka server) actor which is responsible for responding to queries for clinical documents provided by Dental Data Exchange Document Consumer (aka client) actors. This CapabilityStatement imports and extends [CCDAonFHIR-server CapabilityStatement](http://hl7.org/fhir/us/ccda/CapabilityStatement-CcdaOnFhirServer.html), which imports and extends the [us-core-server CapabilityStatement](https://www.hl7.org/fhir/us/core/CapabilityStatement-us-core-server.html) |
| Document Recipient implementing Simplified Publish Option | ch.fhir.ig.ch-elm#current | R4 | Document Recipient implementing Simplified Publish |
| Dossier Farmaceutico - Consumer (client) | hl7.fhir.it.dossierpharma#current | R4 | CapabilityStatement per il Consumer definito nelle specifiche del Dossier Farmaceutico |
| Dossier Farmaceutico - Receiver (server) | hl7.fhir.it.dossierpharma#current | R4 | CapabilityStatement per il Receiver definito nelle specifiche del Dossier Farmaceutico |
| Dossier Farmaceutico - Sender (client) | hl7.fhir.it.dossierpharma#current | R4 | CapabilityStatement per il Sender definito nelle specifiche del Dossier Farmaceutico |
| DTR Payer Service | hl7.fhir.us.davinci-dtr#current | R4 | This statement defines the expected capabilities of payer systems that provide questionnaires to DTR clients. Such systems need only support server capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations. |
| DTR SMART on FHIR Client | hl7.fhir.us.davinci-dtr#current | R4 | This statement defines the expected capabilities of DTR SMART on FHIR applications. Such apps require client support for retrieving and editing QuestionnaireResponse resources and related resources, as well as client support for the Questionnaire Package, ValueSet Expand, and Next Question operations. |
| EHR PAS Capabilities | hl7.fhir.us.davinci-pas#current | R4 | Capabilities required for an EHR participating in a PAS Exchange. |
| EHRS Functional Model - Record Lifecycle Events - Capability Statement | hl7.fhir.uv.ehrs-rle#current | R5 | This profile defines the expected capabilities of an ''Electronic Health Record System'' when conforming to the EHRS functional model's Record Lifecycle specification. |
| eLTSS Client | hl7.fhir.us.eltss#current | R4 | This profile defines the expected capabilities of the eLTSS Client. |
| eLTSS Server | hl7.fhir.us.eltss#current | R4 | This profile defines the expected capabilities of the eLTSS Server. Any system which will send (i.e. be the target of a Read or Search) eLTSS data, or from which other systems will access or modify data (write), is considered a server. The CapabilityStatement indicates implementation of several other implementation guides, reflecting the nature of eLTSS data. The core data item addressed in this guide is the CarePlan. |
| ePI FHIR Capability Statement (draft 1) | hl7.fhir.uv.vulcan-eproduct-info#current | R5 | This section describes a minumum expected capabilities of an ePI FHIR Server which is responsible for providing responses to the queries submitted by the ePI clients. Please refer to the XML or JSON versions of this specification for details on which elements search is to be enabled on. A compliant server SHALL adhere to the requirements listed in this resource, and implement the RESTful behavior according to the FHIR specification. |
| Example Data Receiver Capability Statement | hl7.fhir.us.medmorph#current | R4 | This example CapabilityStatement defines the expected capabilities of the Data Receiver actor when conforming to the MedMorph RA IG. The actor is responsible for defining Knowledge Artifacts, receiving reports, and submitting responses back to health care organizations. The specific knowlege artifacts, reports and responses to be supported by the Data Receiver will be defined by the Content IGs. |
| Example MedMorph Data Source CapabilityStatement | hl7.fhir.us.medmorph#current | R4 | This is an example CapabilityStatement that defines the expected capabilities of the Data Source actor. This CapabilityStatement is an example for Content IG creators on how to create a capability statement for a Data Source actor. |
| Exchange Routing Destination Server Capability Statement | hl7.fhir.us.exchange-routing#current | R4 | This CapabilityStatement describes the expected capabilities of an destination FHIR server that conforms to the conventions of the Hybrid / Intermediary Exchange FHIR implementation guide. |
| Exchange Routing Intermediary Capability Statement | hl7.fhir.us.exchange-routing#current | R4 | This CapabilityStatement describes the expected capabilities of an intermediary server that conforms to the conventions of the Hybrid / Intermediary Exchange FHIR implementation guide. |
| FHIR Bulk Data Access Implementation Guide | hl7.fhir.uv.bulkdata#current | R4 | The expected capabilities of a Bulk Data Provider actor (e.g., EHR systems, data warehouses, and other clinical and administrative systems that aim to interoperate by sharing large FHIR datasets) which is responsible for providing responses to the queries submitted by a FHIR Bulk Data Client actor. Systems implementing this capability statement should meet the requirements set by the Bulk Data Access Implementation Guide. A FHIR Bulk Data Client has the option of choosing from this list to access necessary data based on use cases and other contextual requirements. |
| FHIR Server supporting FHIR operations in order to interact with RDSC Actor | hl7.fhir.uv.radiation-dose-summary#current | R4 | Defines the operations requirements for FHIR server interacting with RDSC actor |
| FHIR Server supporting FHIR operations in order to interact with RDSC and RDSP Actors | hl7.fhir.uv.radiation-dose-summary#current | R4 | Defines the operations requirement for FHIR server actor |
| FHIR Server supporting FHIR operations in order to interact with RDSP Actor | hl7.fhir.uv.radiation-dose-summary#current | R4 | Defines the operations requirement for FHIR server interacting with RDSP actor |
| Finnish SMART Server Capability Statement | hl7.fhir.fi.smart#current | R4 | This CapabilityStatement describes the basic rules for a server actor providing SMART App Launch in Finland. |
| Full DTR EHR | hl7.fhir.us.davinci-dtr#current | R4 | This statement defines the expected capabilities of EHRs that manage the form filling functions of DTR internally. Such EHRs need only support client capabilities for the Questionnaire Package, ValueSet Expand, and Next Question operations. |
| Gaps In Care Client CapabilityStatement | hl7.fhir.us.davinci-deqm#current | R4 | This profile defines the expected capabilities of a Da Vinci DEQM Gaps In Care Client when conforming to the Da Vinci DEQM Implementation Guide for interactions between Clients and Servers to exchange the Gaps in Care Reports for a measure. Clients are the actors requesting the gaps in care results of quality measure(s). This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci DEQM profiles and RESTful operations that a Da Vinci DEQM Gaps In Care Client could support. Clients have the option of choosing from this list based on their local use cases and other contextual requirements. |
| Gaps In Care Server CapabilityStatement | hl7.fhir.us.davinci-deqm#current | R4 | This profile defines the expected capabilities of a Da Vinci DEQM Gaps In Care Server when conforming to the Da Vinci DEQM Implementation Guide for interactions between Clients and Servers to exchange the Gaps in Care Reports for a measure. Servers are the actors receiving the request for Gaps in Care Reports for quality measure(s). This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci DEQM profiles and RESTful operations that a Gaps In Care Server could support. Servers have the option of choosing from this list based on their local use cases and other contextual requirements. |
| HAI LTCF Capability Statement - Server | hl7.fhir.us.hai-ltcf#current | R4 | This resource defines the expected capabilities for servers reporting to NHSN from LTCF. |
| Health Care Surveys EHR Capability Statement | hl7.fhir.us.health-care-surveys-reporting#current | R4 | This profile defines the expected capabilities of the ''EHR'' actor when conforming to the Health Care Surveys Content Implementation Guide. This role is responsible for allowing creation, modification and deletion of Subscriptions and allows searching and retrieval of resources using US Core APIs. |
| Health Data Exchange App (HDEA) Client Application - (MedMorph backend services app) | hl7.fhir.us.medmorph#current | R4 | This CapabilityStatement defines the expected capabilities of the HDEA actor when conforming to the MedMorph RA IG and playing the role of a client initiating the interactions with both Data Sources and Data Receivers/TTP. |
| Health Data Exchange App (HDEA) Server Application - (MedMorph backend services app) | hl7.fhir.us.medmorph#current | R4 | This CapabilityStatement defines the expected capabilities of the HDEA actor when conforming to the MedMorph RA IG and playing the role of a server that receives messages from Data Receivers using FHIR Messaging. |
| Human Services Directory Capability Statement | hl7.fhir.us.hsds#current | R4 | Describes the expected capabilities of the Human Services Directory Server actor responsible for providing responses to the queries submitted by the Human Services Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Human Services Directory (HSD) Servers are defined. |
| Intermediary PAS Capabilities | hl7.fhir.us.davinci-pas#current | R4 | Capabilities required for an Intermediary participating in a PAS Exchange. |
| International Patient Access Client CapabilityStatement | hl7.fhir.uv.ipa#current | R4 | 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. |
| International Patient Access Server CapabilityStatement | hl7.fhir.uv.ipa#current | R4 | This CapabilityStatement describes the basic rules for the International Patient Access server actor that is responsible for providing responses to queries submitted by International Patient Access requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by International Patient Access servers are defined in this CapabilityStatement. |
| IPS Server Capability Statement | hl7.fhir.uv.ips#current | R4 | This section describes the expected capabilities of the IPS Server actor which is responsible for providing responses to the queries submitted for IPS documents. The list of FHIR profiles and operations supported by IPS Servers are defined. |
| Knowledge Artifact Repository | hl7.fhir.us.medmorph#current | R4 | This CapabilityStatement defines the expected capabilities of the Knowledge Artifact Repository actor when conforming to the MedMorph RA IG. This actor is responsible for allowing creation, modification, and hosting of the Knowledge Artifacts. |
| Light DTR EHR | hl7.fhir.us.davinci-dtr#current | R4 | This statement defines the expected capabilities of EHRs that rely on a SMART on FHIR application to handle the form filling function of DTR. This requires the server to provide access to the specified resources to allow such an app to retrieve and edit QuestionnaireResponses and related resources. |
| Logging | hl7.fhir.nl.zorgviewer#current | R3 | Deze CapabilityStatement beschrijft de minimale requirements voor het Logging Bouwblok. |
| Long Term Care Capability Statement - Client | hl7.fhir.us.hai-ltcf#current | R4 | This resource defines the expected capabilities for clients reporting to NHSN from LTCF. |
| MCC Client CapabilityStatement | hl7.fhir.us.mcc#current | R4 | This Section describes the expected capabilities of the MCC Client actor. See [http://hl7.org/fhir/us/core/CapabilityStatement-us-core-client.html](http://hl7.org/fhir/us/core/CapabilityStatement-us-core-client.html) for specifics. Additionally, support for the extension 'Pertains to Goal' is indicated in the StructureDefinitions of [MCC eCare Plan Implementation Guide](http://hl7.org/fhir/us/mcc/ImplementationGuide/hl7.fhir.us.mcc), as well as other conformance artifacts of the MCC eCare Plan Implementation Guide |
| MCC Server CapabilityStatement | hl7.fhir.us.mcc#current | R4 | This Section describes the expected capabilities of the MCC Server actor which is responsible for providing responses to the queries submitted by the MCC Requesters. See [http://hl7.org/fhir/us/core/CapabilityStatement-us-core-server.html](http://hl7.org/fhir/us/core/CapabilityStatement-us-core-server.html) for specifics. Additionally, support for the extension 'Pertains to Goal' is indicated in the StructureDefinitions of [MCC eCare Plan Implementation Guide](http://hl7.org/fhir/us/mcc/ImplementationGuide/hl7.fhir.us.mcc), as well as other conformance artifacts of the MCC eCare Plan Implementation Guide. |
| mCODE Data Receiver CapabilityStatement: Get in-scope patients (and associated Conditions) using _include | hl7.fhir.us.mcode#current | R4 | Uses `_include` to retrieve a Bundle of Condition resources with a code in mCODE's cancer condition value set, along with the associated Patient resources. Use ONLY when reverse chaining is not available on the system. |
| mCODE Data Receiver CapabilityStatement: Get in-scope patients using reverse chaining | hl7.fhir.us.mcode#current | R4 | Uses reverse chaining to retrieve a Bundle of Patient resources with a condition code in mCODE's cancer condition value set. |
| mCODE Data Receiver: Get Bundle for a Patient | hl7.fhir.us.mcode#current | R4 | Gets an [mCODE Patient Bundle](StructureDefinition-mcode-patient-bundle.html) for a specific patient that contains all of that patient's resources that conform to mCODE Profiles. |
| mCODE Data Receiver: Get Conditions then Patients | hl7.fhir.us.mcode#current | R4 | Retrieves a Bundle of Condition resources with a code in mCODE's cancer condition value set, and allows for associated Patient resources to be retrieved in a subsequent request. Use ONLY when reverse chaining AND `_include` are not available on the system. |
| mCODE Data Receiver: Get Patients in Group | hl7.fhir.us.mcode#current | R4 | Capabilities for an mCODE Data Receiver where not all cancer patients conform to mCODE. Retrieves a Group of references to Patient resources that conform to mCODE, and allows for the full Patient resources to be retrieved in a subsequent request. |
| mCODE Data Sender CapabilityStatement: Get in-scope patients (and associated Conditions) using _include | hl7.fhir.us.mcode#current | R4 | Uses `_include` to retrieve a Bundle of Condition resources with a code in mCODE's cancer condition value set, along with the associated Patient resources. Use ONLY when reverse chaining is not available on the system. |
| mCODE Data Sender CapabilityStatement: Get in-scope patients using reverse chaining | hl7.fhir.us.mcode#current | R4 | Uses reverse chaining to retrieve a Bundle of Patient resources with a condition code in mCODE's cancer condition value set. |
| mCODE Data Sender: Get Bundle for a Patient | hl7.fhir.us.mcode#current | R4 | Retrieves a Bundle of Condition resources with a code in mCODE's cancer condition value set, and allows for associated Patient resources to be retrieved in a subsequent request. Use ONLY when reverse chaining AND `_include` are not available on the system. |
| mCODE Data Sender: Get Conditions then Patients | hl7.fhir.us.mcode#current | R4 | Retrieves a Bundle of Condition resources with a code in mCODE's cancer condition value set, and allows for associated Patient resources to be retrieved in a subsequent request. Use ONLY when reverse chaining AND `_include` are not available on the system. |
| mCODE Data Sender: Get Patients in Group | hl7.fhir.us.mcode#current | R4 | Capabilities for an mCODE Data Sender where not all cancer patients conform to mCODE. Retrieves a Group of references to Patient resources that conform to mCODE, and allows for the full Patient resources to be retrieved in a subsequent request. |
| mCSD Care Services Selective Consumer (client) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for Client Actor in the IHE IT Infrastructure Technical Framework Supplement IHE mCSD. |
| mCSD Care Services Selective Supplier (server) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for Server Actor in the IHE IT Infrastructure Technical Framework Supplement IHE mCSD. |
| Measure Computer | hl7.fhir.uv.saner#current | R4 | Defines the requirements for the Measure Computer. |
| Measure Computer implementing the Compute Measure transaction. | hl7.fhir.uv.saner#current | R4 | Defines the requirements for the Measure Computer implementing the Compute Measure transaction. |
| Measure Consumer implementing the Aggregate Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the Aggregate Option. |
| Measure Consumer implementing the CSV Option and the Pull Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the CSV Option and the Pull Option. |
| Measure Consumer implementing the CSV Option and the Push Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the CSV Option and the Push Option. |
| Measure Consumer implementing the Produce Measure transaction with the CSV Option and the Push Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the Produce Measure transaction with the CSV Option and the Push Option. |
| Measure Consumer implementing the Produce Measure transaction with the Push Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the Produce Measure transaction with the Push Option. |
| Measure Consumer implementing the Produce Measure transaction with the Supplemental Data Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the Produce Measure transaction with the Supplemental Data Option. |
| Measure Consumer implementing the Pull Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the Pull Option. |
| Measure Consumer implementing the Push Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the Push Option. |
| Measure Consumer implementing the Query Measure transaction with the CSV Option and the Pull Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the Query Measure transaction with the CSV Option and the Pull Option. |
| Measure Consumer implementing the Query Measure transaction with the Pull Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the Query Measure transaction with the Pull Option. |
| Measure Consumer implementing the Supplemental Data Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Consumer implementing the Supplemental Data Option. |
| Measure Definition Consumer implementing the Query Measure Definition transaction. | hl7.fhir.uv.saner#current | R4 | Defines the requirements for the Measure Definition Consumer implementing the Query Measure Definition transaction. |
| Measure Definition Consumer. | hl7.fhir.uv.saner#current | R4 | Defines the requirements for the Measure Definition Consumer. |
| Measure Definition Source implementing the Query Measure Definition transaction. | hl7.fhir.uv.saner#current | R4 | Defines the requirements for the Measure Definition Source implementing the Query Measure Definition transaction. |
| Measure Definition Source. | hl7.fhir.uv.saner#current | R4 | Defines the requirements for the Measure Definition Source. |
| Measure Source implementing the Aggregate Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the Aggregate Option. |
| Measure Source implementing the CSV Option and the Pull Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the CSV Option and the Pull Option. |
| Measure Source implementing the CSV Option and the Push Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the CSV Option and the Push Option. |
| Measure Source implementing the Produce Measure transaction with the CSV Option and the Push Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the Produce Measure transaction with the CSV Option and the Push Option. |
| Measure Source implementing the Produce Measure transaction with the Push Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the Produce Measure transaction with the Push Option. |
| Measure Source implementing the Produce Measure transaction with the Supplemental Data Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the Produce Measure transaction with the Supplemental Data Option. |
| Measure Source implementing the Pull Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the Pull Option. |
| Measure Source implementing the Push Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the Push Option. |
| Measure Source implementing the Query Measure transaction with the CSV Option and the Pull Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the Query Measure transaction with the CSV Option and the Pull Option. |
| Measure Source implementing the Query Measure transaction with the Pull Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the Query Measure transaction with the Pull Option. |
| Measure Source implementing the Supplemental Data Option. | hl7.fhir.uv.saner#current | R4 | Defines the additional requirements for the Measure Source implementing the Supplemental Data Option. |
| Measure Terminology Service Capability Statement | hl7.fhir.us.cqfmeasures#current | R4 | Capability statement for a terminology service supporting measure authoring and evaulation use cases. A server can support more functionality than defined here, but this defines the minimum expectations. |
| Measure Terminology Service Capability Statement | hl7.fhir.uv.cmi#current | R4 | Capability statement for a terminology service supporting measure authoring and evaulation use cases. A server can support more functionality than defined here, but this defines the minimum expectations. |
| MedMorph Research Data Exchange EHR Capability Statement | hl7.fhir.us.medmorph-research-dex#current | R4 | This profile defines the expected capabilities of the ''EHR'' actor when conforming to the MedMorph Research Data Exchange IG. This role is responsible for allowing creation and retrieval of Group resources, along with retrieval of clinical data using the Group/$export operation. |
| MHD Document Consumer (client) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for Actor MHD Document Consumer (client). |
| MHD Document Recipient (server) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for Actor MHD Document Recipient (server). |
| MHD Document Responder (server) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for Actor MHD Document Responder (server). |
| MHD Document Source (client) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for Actor MHD Document Source (client). |
| mHealth: API (server) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for mHealth API (server). |
| mHealth: App (client) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for mHealth App (client). |
| NatlDir CapabilityStatement | hl7.fhir.us.directory-attestation#current | R4 | This Section describes the expected capabilities of the NatlDir Server actor which is responsible for providing responses to the queries submitted by the NatlDir Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by NatlDir Servers are defined. Systems implementing this capability statement should meet the CMS FInal Rule requirement for provider directory access. NatlDir Clients can use the required capabilities to access necessary data based on their local use cases and other contextual requirements. |
| NDH Attestation Server Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the NDH Attestation Server which is responsible for receiving information from attestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by NDH Attestation Servers are defined. |
| NDH Exchange Base Expanded Server Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the NDH Server actor which is responsible for providing responses to the queries submitted by the NDH Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by NDH Servers are defined. NDH Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| NDH Exchange Base Server Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the NDH Server actor which is responsible for providing responses to the queries submitted by the NDH Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by NDH Servers are defined. NDH Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| NDH Exchange Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the NDH Server actor which is responsible for providing responses to the queries submitted by the NDH Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by NDH Servers are defined. NDH Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| NDH Verification Server Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the NDH Verification Server which is responsible for receiving information from primary source. The complete list of FHIR profiles, RESTful operations, and search parameters supported by NDH Verification Servers are defined. |
| Notification Forwarder CapabilityStatement | hl7.fhir.us.davinci-alerts#current | R4 | This CapabilityStatement describes the expected capabilities of a Da Vinci Intermediary when forwarding Unsolicited Notifications transacted with the `$process-message` in the client mode. |
| Notification Receiver CapabilityStatement | hl7.fhir.us.davinci-alerts#current | R4 | This CapabilityStatement describes the expected capabilities of a server that is capable of receiving a Da Vinci Unsolicited Notification transacted with the `$process-message` operation. |
| Notification Sender CapabilityStatement | hl7.fhir.us.davinci-alerts#current | R4 | This CapabilityStatement describes the expected capabilities of a Da Vinci Sender when sending Unsolicited Notifications transacted with the `$process-message` in the client mode. |
| Ontsluiten Bronsysteem | hl7.fhir.nl.zorgviewer#current | R3 | Deze CapabilityStatement beschrijft de minimale requirements voor het Ontsluiten Bronsysteem Bouwblok. |
| PA Care Manager | hl7.fhir.us.physical-activity#current | R4 | Describes the expected capabilities of a system that is responsible for managing issues related to the physical activity level of a patient. |
| PA Patient Engagement | hl7.fhir.us.physical-activity#current | R4 | Describes the expected capabilities of a system intended for use by patients and caregivers of patients who are working to enhance or maintain their levels of physical activity. These will typically be web-based or mobile applications. |
| PA Service Provider (Full) | hl7.fhir.us.physical-activity#current | R4 | Describes the expected capabilities of a system used by a personal trainer, community fitness organization, or other entity that delivers services that help a patient to improve or maintain their level of physical activity. This set of capabilities is appropriate for service providers that CAN expose their own FHIR server and that store Tasks, reports and other resources locally and expose them for query by [Care Managers](CapabilityStatement-pa-care-manager.html) and [Patient Engagement systems](CapabilityStatement-pa-patient-engagement.html). |
| PA Service Provider (Light) | hl7.fhir.us.physical-activity#current | R4 | Describes the expected capabilities of a system used by a personal trainer, community fitness organization, or other entity that delivers services that help a patient to improve or maintain their level of physical activity. This set of capabilities is appropriate for service providers that CANNOT expose their own FHIR server and that rely on the Care Manager to store Tasks, reports and other resources. |
| PACIO Cognitive Status Capability Statement | hl7.fhir.us.pacio-cs#current | R4 | This Capability Statement defines the expected capabilities of a PACIO Cognitive Status FHIR server conforming to the PACIO Cognitive Status Implementation Guide. |
| PACIO Functional Status Capability Statement | hl7.fhir.us.pacio-fs#current | R4 | This Capability Statement defines the expected capabilities of a PACIO Functional Status FHIR server conforming to the PACIO functional Status Implementation Guide. |
| PADI CapabilityStatement | hl7.fhir.us.pacio-adi#current | R4 | This Section describes the expected capabilities of the PACIO Advance Directive Interoperability (ADI) Server actor which is responsible for providing responses to the queries submitted by the ADI Requestors. There are two primary vehicles in which Advance Directive Information can be conveyed: DocumentReference and Bundle. Through a DocumentReference, the ADI may be encoded inside directly as content data or referred to through a content reference (pointing to the ADI included in a resource like Binary) or reference a Bundle with the type=document for FHIR encoded data. The resources referred to by the Composition in the document bundle include Patient, Observation,Goal, ServiceRequest, Organization, RelatedPerson, Consent, List, and Provenance. |
| Pathology Laboratory Information System | hl7.fhir.us.cancer-reporting#current | R4 | This profile defines the expected capabilities of the ''LIS'' actor when conforming to the Cancer Pathology Data Sharing Guide. This role is responsible for allowing creation, modification and deletion of DiagnosticReports and allows searching and retrieval of resources using US Core APIs. |
| Patient Cost Transparency Implementation Guide Capability Statement | hl7.fhir.us.davinci-pct#current | R4 | Capability statement for the Da Vinci Patient Cost Transparency Implementation Guide |
| Patient Request for Corrections Capability Statement | hl7.fhir.uv.patient-corrections#current | R4 | Describes the capabilities for a FHIR server to support patient requests for corrections. |
| PDEX Server CapabilityStatement | hl7.fhir.us.davinci-pdex#current | R4 | This Section describes the expected capabilities of the PDex Server actor which is responsible for providing responses to the queries submitted by the PDex Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by PDex Servers are defined. PDex Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| PDMP_Client | hl7.fhir.us.pdmp#current | R4 | This resource defines the expected capabilities of the PDMP Client actor when conforming to the PDMP IG and It is expected that it will be used in conjuction with the US Core CapabilityStatement. Together they describe the complete list of actual profiles, RESTful operations, and search parameters supported by PDMP Clients. |
| PDMP_Server | hl7.fhir.us.pdmp#current | R4 | This resource defines the expected capabilities of the PDMP Server actor when conforming to the PDMP IG and It is expected that it will be used in conjuction with the US Core CapabilityStatement. Together they describe the complete list of actual profiles, RESTful operations, and search parameters supported by PDMP Servers. PDMP Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| PDQm Consumer (client) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for Client Actor in the IHE IT Infrastructure Technical Framework Supplement IHE PDQm. |
| PDQm Supplier (server) | ch.fhir.ig.ch-epr-mhealth#current | R4 | CapabilityStatement for Server Actor in the IHE IT Infrastructure Technical Framework Supplement IHE PDQm. |
| Personal Functioning and Engagement Capability Statement | hl7.fhir.us.pacio-pfe#current | R4 | This Capability Statement defines the expected capabilities of a Personal Functioning and Engagement FHIR server conforming to the Personal Functioning and Engagement Implementation Guide. |
| Pharmacist Care Plan Client | hl7.fhir.us.phcp#1.0.0 | R4 | This section describes the expected capabilities of the Pharmacist Care Plan Consumer (aka client) actor which is responsible for creating and initiating the queries for clinical documents compliant with this specification. This CapabilityStatement imports and extends [CCDAonFHIR-client CapabilityStatement](http://hl7.org/fhir/us/ccda/CapabilityStatement-CcdaOnFhirClient.html)CCDAonFHIR client CapabilityStatement, which imports and extends the [us-core-client CapabilityStatement](https://www.hl7.org/fhir/us/core/CapabilityStatement-us-core-client.html) |
| Pharmacist Care Plan Server | hl7.fhir.us.phcp#1.0.0 | R4 | This section describes the expected capabilities of the Pharmacist Care Plan Consumer (aka server) actor which is responsible for creating and initiating the queries for clinical documents compliant with this specification. This CapabilityStatement imports and extends [CCDAonFHIR-server CapabilityStatement](http://hl7.org/fhir/us/ccda/CapabilityStatement-CcdaOnFhirServer.html)CCDAonFHIR server CapabilityStatement, which imports and extends the [us-core-server CapabilityStatement](https://www.hl7.org/fhir/us/core/CapabilityStatement-us-core-server.html) |
| PIXm Patient Identifier Cross-Reference Consumer (client) | ch.fhir.ig.ch-epr-mhealth#current | R4 | The Patient Identifier Cross-reference Consumer Actor CapabililtyStatement expresses the requirements that can be utilized while being compliant. - using FHIR R4 - using json or xml encoding - query the $ihe-pix operation |
| PIXm Patient Identifier Cross-reference Manager (server) | ch.fhir.ig.ch-epr-mhealth#current | R4 | The Patient Identifier Cross-reference Manager CapabililtyStatement expresses the requirements that shall be provided. - using FHIR R4 - using json and xml encoding - support the $ihe-pix operation - support conditional update for [ITI-104] - support conditional delete for [ITI-104] if Remove Patient Option is supported - used with IHE-IUA |
| PIXm Patient Identity Source (client) | ch.fhir.ig.ch-epr-mhealth#current | R4 | The Patient Identity Source Actor CapabililtyStatement expresses the requirements that can be utilized while being compliant. - using FHIR R4 - using json or xml encoding - using conditional update for [ITI-104] - provide supported Patient profile for crosss-referencing for [ITI-104] |
| Plan-Net CapabilityStatement | hl7.fhir.us.davinci-pdex-plan-net#current | R4 | This Section describes the expected capabilities of the Plan-Net Server actor which is responsible for providing responses to the queries submitted by the Plan-Net Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Plan-Net Servers are defined. Systems implementing this capability statement should meet the CMS FInal Rule requirement for provider directory access. Plan-Net Clients can use the required capabilities to access necessary data based on their local use cases and other contextual requirements. |
| Producer Client CapabilityStatement | hl7.fhir.us.davinci-deqm#current | R4 | This profile defines the expected capabilities of a Da Vinci DEQM Producer Client when conforming to the Da Vinci DEQM Implementation Guide. Producers include systems that are primary producers of patient healthcare information. This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci DEQM profiles and RESTful operations that are Da Vinci DEQM Producer Client could support. Clients have the option of choosing from this list based on their local use cases and other contextual requirements. |
| Producer Server CapabilityStatement | hl7.fhir.us.davinci-deqm#current | R4 | This profile defines the expected capabilities of a Da Vinci DEQM Producer Server when conforming to the Da Vinci DEQM Implementation Guide. Producers include systems that are primary producers of patient healthcare information. This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci DEQM profiles and RESTful operations that a Da Vinci DEQM Producer Server could support. Servers have the option of choosing from this list based on their local use cases and other contextual requirements. |
| RDSC Actor requirements | hl7.fhir.uv.radiation-dose-summary#current | R4 | Defines the operations requirements for RDSC actor |
| RDSP Actor minimal requirements | hl7.fhir.uv.radiation-dose-summary#current | R4 | Defines the operation requirement for RDSP actor |
| Re-Assessment Timepoints Capability Statement | hl7.fhir.us.pacio-rt#current | R4 | The Re-Assessment Timepoints IG describes a means to break up extended Post-Acute admissions into consumable blocks that can reflect the evolution of care over time for an encounter or episode of care. On average, Post-Acute Admissions extend over much longer periods of time than encounters in the Acute and Ambulatory Care Settings, often spanning several months or even years. Over the course of these time periods, the patient condition and therefore the care provided is changing constantly. For example, in Home Health the goal is rehabilitation; Care Plans, Medications, and Orders all likely are changing throughout an admission that could last several months. Already in existence within post-acute care settings are periods of time structured by a variety of stakeholders, some more rigid than others, such as regulations and conditions of participation, payer and revenue cycle requirements, and provider specific processes and protocols. In settings like Home Health and Skilled Nursing Facilities (SNF), there are Medicare assessment instruments that providers must complete at specified intervals thatvary by care setting; the results of these assessments drive the Care Plan until a subsequent assessment. If a patient has a pain management Care Plan and their pain levels improve, then they may have their Opioid drug dosages reduced or eliminated. If a patient’s ambulation is improving, then the care team may focus interventions on more complex exercises. These periods of time, defined by many different drivers, have direct impact on how data is made available outside of an EMR. Without a structure in place to hold this information, a connecting application or patient would have to sift through months of information, rather than focusing on a given period or periods most relevant to the needs of the application, patient, or other entity. |
| Receiver Server CapabilityStatement | hl7.fhir.us.davinci-deqm#current | R4 | This profile defines the expected capabilities of a Da Vinci DEQM Receiver Server when conforming to the Da Vinci DEQM Implementation Guide. Receivers include systems that are primary receivers of Measure data such as payers as well as public health and other healthcare-related agencies. This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci DEQM profiles and RESTful operations that a Da Vinci DEQM Receiver Server could support. Servers have the option of choosing from this list based on their local use cases and other contextual requirements. |
| Reporter Client CapabilityStatement | hl7.fhir.us.davinci-deqm#current | R4 | This profile defines the expected capabilities of a Da Vinci DEQM Reporter Client when conforming to the Da Vinci DEQM Implementation Guide. Reporters include systems that are primary reporters of patient healthcare information and systems that consume data from Producers. This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci DEQM profiles and RESTful operations that a Da Vinci DEQM Reporter Client could support. Clients have the option of choosing from this list based on their local use cases and other contextual requirements. |
| Research Query Requester | hl7.fhir.us.daf#2.0.0 | R3 | This profile defines the expected capabilities of the Research Query Requester actor when conforming to the DAF-Research IG. |
| Research Query Responder | hl7.fhir.us.daf#2.0.0 | R3 | This profile defines the expected capabilities of the Research Query Responder actor when conforming to the DAF-Research IG. |
| Risk Adjustment Remediation Client Capability Statement | hl7.fhir.us.davinci-ra#current | R4 | This profile defines the expected capabilities of a Da Vinci Risk Adjustment Remediation Client when conforming to the Da Vinci Risk Adjustment Implementation Guide for interactions between Remediation Clients and Remediation Servers. Clients are the actors making the request for remediating Risk Adjustment coding gaps for Risk Adjustment Coding Gap Reports of patient(s) that are available on the Server. |
| Risk Adjustment Remediation Server Capability Statement | hl7.fhir.us.davinci-ra#current | R4 | This profile defines the expected capabilities of a Da Vinci Risk Adjustment Remediation Server when conforming to the Da Vinci Risk Adjustment Implementation Guide for interactions between Clients and Servers. Servers are the actors receiving the request for Risk Adjustment coding gaps remediation for Risk Adjustment Coding Gap Reports of patients that are available on the Server. |
| Risk Adjustment Reporting Client Capability Statement | hl7.fhir.us.davinci-ra#current | R4 | This profile defines the expected capabilities of a Da Vinci Risk Adjustment Reporting Client when conforming to the Da Vinci Risk Adjustment Implementation Guide for interactions between Reporting Clients and Reporting Servers. Clients are the actors making the request for Risk Adjustment Coding Gap Reports for patient(s) and for Risk Adjustmenet Models that are available on the Server. This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci Risk Adjustment profiles and RESTful operations that a Risk Adjustment Reporting Client could support. Clients have the option of choosing from this list based on their local use cases and other contextual requirements. |
| Risk Adjustment Reporting Server Capability Statement | hl7.fhir.us.davinci-ra#current | R4 | This profile defines the expected capabilities of a Da Vinci Risk Adjustment Reporting Server when conforming to the Da Vinci Risk Adjustment Implementation Guide for interactions between Reporting Clients and Reporting Servers. Servers are the actors receiving the request for Risk Adjustment Coding Gap Reports for patient(s) and for Risk Adjustmenet Models that are available on the Server. This CapabilityStatement resource includes the complete list of the *recommended* Da Vinci Risk Adjustment profiles and RESTful operations that a Risk Adjustment Reporting Server could support. Servers have the option of choosing from this list based on their local use cases and other contextual requirements. |
| RTPBC Requester Capability Statement | hl7.fhir.us.carin-rtpbc#1.0.0 | R4 | This CapabilityStatement describes the expected capabilities of a client system submitting a Real-time Pharmacy Benefit Check (RTPBC) request using the `$process-message` operation. |
| RTPBC Responder Capability Statement | hl7.fhir.us.carin-rtpbc#1.0.0 | R4 | This CapabilityStatement describes the expected capabilities of a server that is capable of responding to a Real-time Pharmacy Benefit Check (RTPBC) request transacted with the `$process-message` operation. |
| SDC Form Archiver | hl7.fhir.uv.sdc.r4#3.0.0 | R4 | This profile defines the expected capabilities of the ''SDC Form Archiver'' role when conforming to the S&I Framework's [[index.html|Structured Data Capture FHIR implementation guide]]. This role is responsible for persisting (archiving) completed or partially completed forms ([[QuestionnaireResponse]] resource instances). These instances may be submitted individually or in a bundle together with [[Provenance]] information providing details about the completion of the questionnaire response. In some cases [[Binary]] or [[DocumentReference]] resources might also be submitted to convey source information used in the population of the questionnaire response.<br/>The purpose of this role is to capture "work in progress" for archival reasons. There is no expectation that submitted form data is subsequently made available for retrieval (at least not in the same format), though it might be made available through out-of-band mechanisms. |
| SDC Form Designer | hl7.fhir.uv.sdc.r4#3.0.0 | R4 | This profile defines the expected capabilities of the ''SDC Form Designer'' role when conforming to the S&I Framework's [[index.html|Structured Data Capture FHIR implementation guide]]. This role is responsible for defining forms ([[Questionnaire]] resource instances) that include references to [[StructureDefinition]] resouces containing data elements that define the meaning of particular questions and can be used to aid in pre-populating and auto-populating forms. |
| SDC Form Filler | hl7.fhir.uv.sdc.r4#3.0.0 | R4 | This profile defines the expected capabilities of the ''SDC Form Filler'' role when conforming to the S&I Framework's [[index.html|Structured Data Capture FHIR implementation guide]]. This role is responsible for retrieving pre-defined forms, requesting pre-population of forms and/or auto-populating forms, guiding the user through verifying populated data and submitting completed or partially-completed forms.<br/>Note that Form Fillers may also take on the role of [[CapabilityStatement-sdc-form-archiver.html|Form Archiver]] if they have a requirement to retain the completed version of a form (and potentially the source data that was used to complete it). |
| SDC Form Manager | hl7.fhir.uv.sdc.r4#3.0.0 | R4 | This profile defines the expected capabilities of the ''SDC Form Manager'' role when conforming to the S&I Framework's [[index.html|Structured Data Capture FHIR implementation guide]]. This role is responsible for maintaining a repository of form definitions and also of performing pre-population of form data. |
| SDC Form Receiver | hl7.fhir.uv.sdc.r4#3.0.0 | R4 | This profile defines the expected capabilities of the ''SDC Form Receiver'' role when conforming to the S&I Framework's [[index.html|Structured Data Capture FHIR implementation guide]]. This role is responsible for accepting and processing completed and partially-completed forms. It only exposes a single operation endpoint - the one needed to 'process' a completed QuestionnaireResponse |
| SDC Form Response Manager | hl7.fhir.uv.sdc.r4#3.0.0 | R4 | This profile defines the expected capabilities of the ''SDC Form Response Manager'' role when conforming to the S&I Framework's [[index.html|Structured Data Capture FHIR implementation guide]]. This role is responsible for providing read/write access to QuestionnaireResponses. This is typically to support light-weight clients that want to be able to complete forms but do not have local storage to save work in progress. |
| SDOHCC Coordination Platform | hl7.fhir.us.sdoh-clinicalcare#current | R4 | This resource describes the required and desired behavior of systems acting as SDOH clinical care 'coordination platforms' (CPs). |
| SDOHCC Patient Application | hl7.fhir.us.sdoh-clinicalcare#current | R4 | This resource describes the required and desired behavior of systems acting as apps for patients and care-givers who need to monitor progress on SDOH referrals and may need to take actions such as filling out forms, booking appointments, etc. |
| SDOHCC Referral Recipient | hl7.fhir.us.sdoh-clinicalcare#current | R4 | This resource describes the required and desired behavior of systems acting as SDOH clinical care 'referral recipients'. These are typically community-based organizations that can provide services such as food bank access, housing remediation, etc. |
| SDOHCC Referral Recipient - Light | hl7.fhir.us.sdoh-clinicalcare#current | R4 | This resource describes the required and desired behavior of systems acting as 'light-weight' SDOH clinical care 'referral recipients'. |
| SDOHCC Referral Source | hl7.fhir.us.sdoh-clinicalcare#current | R4 | This resource describes the required and desired behavior of systems acting as SDOH clinical care 'referral sources'. These are typically EHR or Payer systems that initiate the process of identifying patients with SDOH needs and requesting appropriate services. |
| Server | hl7.fhir.uv.immds#0.2.0 | R4 | This resource defines the expected capabilities of an Immunization Decision Support Forecast server. |
| Server | hl7.fhir.us.patient-reported-outcomes#0.2.0 | R4 | This resource defines the expected capabilities |
| Server | hl7.fhir.uv.cdisc-lab#1.0.0 | R4 | This resource defines the expected capabilities |
| Server | hl7.fhir.us.womens-health-registries#0.2.0 | R4 | This resource defines the expected capabilities |
| Server capability requirements | hl7.fhir.uv.pocd#current | R4 | CapabilityStatement that describes the expected capabilities of a server processing data from Point-of-Care devices. |
| sIRB Client Capability Statement | hl7.fhir.us.sirb#current | R4 | This resource describes the required and desired behavior of software clients for use and exchange of the single Institutional Review Board (sIRB) forms. |
| sIRB Server Capability Statement | hl7.fhir.us.sirb#current | R4 | This resource describes the required and desired behavior of FHIR servers for use and exchange of the single Institutional Review Board (sIRB) forms. |
| Specialty Rx CapabilityStatement - Data Consumer - Messaging | hl7.fhir.us.specialty-rx#current | R4 | This CapabilityStatement describes the expected capabilities of a system that is capable of retrieving patient information using Specialty Rx Query messaging. |
| Specialty Rx CapabilityStatement - Data Consumer - RESTful | hl7.fhir.us.specialty-rx#current | R4 | This CapabilityStatement describes the expected capabilities of a system that is capable of executing RESTful operations to retrieve patient information from a RESTful FHIR server. |
| Specialty Rx CapabilityStatement - Data Source - Messaging | hl7.fhir.us.specialty-rx#current | R4 | This CapabilityStatement describes the expected capabilities of a server that is capable of providing patient information using Specialty Rx Query messaging. |
| Specialty Rx CapabilityStatement - Data Source - RESTful | hl7.fhir.us.specialty-rx#current | R4 | This CapabilityStatement describes the expected capabilities of a server that is capable of responding to RESTful requests for patient information. |
| Terminologie | hl7.fhir.nl.zorgviewer#current | R3 | Deze CapabilityStatement beschrijft de minimale requirements voor het Terminologie Bouwblok. |
| Toestemming | hl7.fhir.nl.zorgviewer#current | R3 | Deze CapabilityStatement beschrijft de minimale requirements voor het Toestemming en Adressering Bouwblok. |
| Trust Service Provider | hl7.fhir.us.medmorph#current | R4 | This CapabilityStatement defines the expected capabilities of the Trust Service Provider actor when conforming to the MedMorph RA IG. This actor is responsible for providing trust services. (e.g., Pseudonymization, Anonymization, De-identification, Re-identification). |
| Trusted Third Party (TTP) | hl7.fhir.us.medmorph#current | R4 | This CapabilityStatement defines the expected capabilities of the TTP actor when conforming to the MedMorph RA IG. This actor is responsible for receiving messages and forwarding messages from health care organizations to a public health authority (PHA) or Research Organization (RO) and send responses back from PHA/RO to health care organizations. |
| US Core Client CapabilityStatement | hl7.fhir.us.core#current | R4 | This Section 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 [Conformance Requirements for Server](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. |
| US Core Server CapabilityStatement | hl7.fhir.us.core#current | R4 | This Section describes the expected capabilities of the US Core Server actor which is responsible for providing responses to the queries submitted by the US Core Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Core Servers are defined. Systems implementing this capability statement should meet the ONC 2015 Common Clinical Data Set (CCDS) access requirement for Patient Selection 170.315(g)(7) and Application Access - Data Category Request 170.315(g)(8) and the ONC [U.S. Core Data for Interoperability (USCDI) Version 3 July 2022](https://www.healthit.gov/isa/sites/isa/files/2022-07/USCDI-Version-3-July-2022-Final.pdf). 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. |
| US Meds Client | hl7.fhir.us.meds#1.2.0 | R3 | This resource defines the expected capabilities of the US Meds Client actor when conforming to the US Meds IG and It is expected that it will be used in conjuction with the US Core CapabilityStatement. Together they describe the complete list of actual profiles, RESTful operations, and search parameters supported by US Meds Clients. |
| US Meds Server | hl7.fhir.us.meds#1.2.0 | R3 | This resource defines the expected capabilities of the US Meds Server actor when conforming to the US Meds IG and It is expected that it will be used in conjuction with the US Core CapabilityStatement. Together they describe the complete list of actual profiles, RESTful operations, and search parameters supported by US Meds Servers. US Meds Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| usdf-server CapabilityStatement | hl7.fhir.us.Davinci-drug-formulary#2.0.0 | R4 | This Section describes the expected capabilities of the US Drug Formulary Server actor which is responsible for providing responses to the queries submitted by the US Drug Formulary Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Drug Formulary Server are defined. |
| Validated Healthcare Directory Server Capability Statement | hl7.fhir.uv.vhdir#current | R4 | This Capability Statement defines the expected capabilities of a validated healthcare directory FHIR server conforming to the Validated Healthcare Directory Implementation Guide. |
| VBP Reporting Client Capability Statement | hl7.fhir.us.davinci-vbpr#current | R4 | This profile defines the expected capabilities of the Value-Based Performance (VBP) Reporting Client actor, when request and consume value-based performance MeasureReports from a Value-Based Performance Reporting Server. The complete list of FHIR profiles that a VBP Reporting Server could support are defined. VBP Reporting Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| VBP Reporting Server Capability Statement | hl7.fhir.us.davinci-vbpr#current | R4 | This profile defines the expected capabilities of the Value-Based Performance (VBP) Reporting Server actor which is responsible for producing value-based performance MeasureReports to be consumed by a Value-Based Performance Reporting Client. The complete list of FHIR profiles and search parameters that a VBP Reporting Server could support are defined. VBP Reporting Servers have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Workflow Directory Server Endpoint Basic Query Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the Distributed Workflow Directory Server which is responsible for providing responses to the queries submitted by the Distributed Workflow Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Distributed Workflow Directory Servers are defined. Distributed Workflow Directory Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Workflow Directory Server Endpoint Expanded Query Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the Distributed Workflow Directory Server which is responsible for providing responses to the queries submitted by the Distributed Workflow Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Distributed Workflow Directory Servers are defined. Distributed Workflow Directory Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Workflow Directory Server Health And Human Service Basic Query Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the Distributed Workflow Directory Server which is responsible for providing responses to the queries submitted by the Distributed Workflow Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Distributed Workflow Directory Servers are defined. Distributed Workflow Directory Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Workflow Directory Server Health And Human Service Expanded Query Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the Distributed Workflow Directory Server which is responsible for providing responses to the queries submitted by the Distributed Workflow Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Distributed Workflow Directory Servers are defined. Distributed Workflow Directory Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Workflow Directory Server Human Service Basic Query Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the Distributed Workflow Directory Server which is responsible for providing responses to the queries submitted by the Distributed Workflow Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Distributed Workflow Directory Servers are defined. Distributed Workflow Directory Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Workflow Directory Server Human Service Expanded Query Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the Distributed Workflow Directory Server which is responsible for providing responses to the queries submitted by the Distributed Workflow Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Distributed Workflow Directory Servers are defined. Distributed Workflow Directory Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Workflow Directory Server Payer Provider Network Query Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the Distributed Workflow Directory Server which is responsible for providing responses to the queries submitted by the Distributed Workflow Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Distributed Workflow Directory Servers are defined. Distributed Workflow Directory Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Workflow Directory Server Provider Basic Query Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the Distributed Workflow Directory Server which is responsible for providing responses to the queries submitted by the Distributed Workflow Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Distributed Workflow Directory Servers are defined. Distributed Workflow Directory Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Workflow Directory Server Provider Expanded Query Capability Statement | hl7.fhir.us.ndh#current | R4 | This Section describes the expected capabilities of the Distributed Workflow Directory Server which is responsible for providing responses to the queries submitted by the Distributed Workflow Directory Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by Distributed Workflow Directory Servers are defined. Distributed Workflow Directory Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. |
| Zorgviewer Host | hl7.fhir.nl.zorgviewer#current | R3 | Deze CapabilityStatement beschrijft de minimale requirements voor het Zorgviewer Host Bouwblok. |
Produced 08 Sep 2023