| 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. |
| 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 |
| 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 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. |
| 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. |
| 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 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 |
| 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) |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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 |
| 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. |
| 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) |
| 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. |
| 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. |
| 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.us.womens-health-registries#0.2.0 | R4 | This resource defines the expected capabilities |
| 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. |
| 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. |
Produced 08 Sep 2023