You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this tutorial, we'll walk through setting up Azure API for FHIR to pass the [Touchstone](https://touchstone.aegis.net/touchstone/) tests for the [CARIN Implementation Guide for Blue Button](https://build.fhir.org/ig/HL7/carin-bb/index.html) (C4BB IG).
17
+
In this tutorial, we walk through setting up Azure API for FHIR® to pass the [Touchstone](https://touchstone.aegis.net/touchstone/) tests for the [CARIN Implementation Guide for Blue Button](https://build.fhir.org/ig/HL7/carin-bb/index.html) (C4BB IG).
18
18
19
19
## Touchstone capability statement
20
20
21
-
The first test that we'll focus on is testing Azure API for FHIR against the [C4BB IG capability statement](https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/CARIN/CARIN-4-BlueButton/00-Capability&activeOnly=false&contentEntry=TEST_SCRIPTS). If you run this test against Azure API for FHIR without any updates, the test will fail due to missing search parameters and missing profiles.
21
+
The first test we focus on is testing Azure API for FHIR against the [C4BB IG capability statement](https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/CARIN/CARIN-4-BlueButton/00-Capability&activeOnly=false&contentEntry=TEST_SCRIPTS). If you run this test against Azure API for FHIR without any updates, the test fails due to missing search parameters and profiles.
22
22
23
23
### Define search parameters
24
24
25
-
As part of the C4BB IG, you'll need to define three [new search parameters](how-to-do-custom-search.md) for the `ExplanationOfBenefit` resource. Two of these are tested in the capability statement (type and service-date), and one is needed for `_include` searches (insurer).
25
+
As part of the C4BB IG, you need to define three [new search parameters](how-to-do-custom-search.md) for the `ExplanationOfBenefit` resource. Two of these are tested in the capability statement (type and service-date), and one is needed for `_include` searches (insurer).
@@ -31,7 +31,7 @@ As part of the C4BB IG, you'll need to define three [new search parameters](how-
31
31
> [!NOTE]
32
32
> In the raw JSON for these search parameters, the name is set to `ExplanationOfBenefit_<SearchParameter Name>`. The Touchstone test is expecting that the name for these will be **type**, **service-date**, and **insurer**.
33
33
34
-
The rest of the search parameters needed for the C4BB IG are defined by the base specification and are already available in Azure API for FHIR without any additional updates.
34
+
The rest of the search parameters needed for the C4BB IG are defined by the base specification and are already available in Azure API for FHIR without additional updates.
35
35
36
36
### Store profiles
37
37
@@ -54,19 +54,19 @@ To assist with creation of these search parameters and profiles, we have a [samp
54
54
55
55
## Touchstone read test
56
56
57
-
After testing the capabilities statement, we'll test the [read capabilities](https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/CARIN/CARIN-4-BlueButton/01-Read&activeOnly=false&contentEntry=TEST_SCRIPTS) in Azure API for FHIR against the C4BB IG. This test is testing conformance against the eight profiles you loaded in the first test. You'll need to have resources loaded that conform to the profiles. The best path would be to test against resources that you already have in your database, but we also have an [http file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/C4BB/C4BB_Sample_Resources.http) available with sample resources pulled from the examples in the IG that you can use to create the resources and test against.
57
+
After testing the capabilities statement, we'll test the [read capabilities](https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/CARIN/CARIN-4-BlueButton/01-Read&activeOnly=false&contentEntry=TEST_SCRIPTS) in Azure API for FHIR against the C4BB IG. This is a test of conformance against the eight profiles you loaded in the first test. You'll need to have resources loaded that conform to the profiles. We recommend testing against resources that you already have in your database, but we also have an [http file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/C4BB/C4BB_Sample_Resources.http) available with sample resources pulled from the examples in the IG that you can use to create the resources and test against.
58
58
59
59
:::image type="content" source="media/cms-tutorials/test-execution-results-touchstone.png" alt-text="Touchstone read test execution results.":::
60
60
61
61
## Touchstone EOB query test
62
62
63
-
The next test we'll review is the [EOB query test](https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/CARIN/CARIN-4-BlueButton/02-EOBQuery&activeOnly=false&contentEntry=TEST_SCRIPTS). If you've already completed the read test, you have all the data loaded that you'll need. This test validates that you can search for specific `Patient` and `ExplanationOfBenefit` resources using various parameters.
63
+
The next test we'll review is the [EOB query test](https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/CARIN/CARIN-4-BlueButton/02-EOBQuery&activeOnly=false&contentEntry=TEST_SCRIPTS). If you've already completed the read test, you have all the data loaded that you need. This test validates that you can search for specific `Patient` and `ExplanationOfBenefit` resources using various parameters.
The final test we'll walk through is testing [error handling](https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/CARIN/CARIN-4-BlueButton/99-ErrorHandling&activeOnly=false&contentEntry=TEST_SCRIPTS). The only step you need to do is delete an ExplanationOfBenefit resource from your database and use the ID of the deleted `ExplanationOfBenefit` resource in the test.
69
+
The final test we walk through is testing [error handling](https://touchstone.aegis.net/touchstone/testdefinitions?selectedTestGrp=/FHIRSandbox/CARIN/CARIN-4-BlueButton/99-ErrorHandling&activeOnly=false&contentEntry=TEST_SCRIPTS). The only step you need to do is delete an ExplanationOfBenefit resource from your database and use the ID of the deleted `ExplanationOfBenefit` resource in the test.
In this series of tutorials, we'll cover a high-level summary of the Center for Medicare and Medicaid Services (CMS) Interoperability and Patient Access rule, and the technical requirements outlined in this rule. We'll walk through the various implementation guides referenced for this rule. We'll also provide details on how to configure the Azure API for FHIR to support these implementation guides.
17
+
In this series of tutorials, we cover a high-level summary of the Center for Medicare and Medicaid Services (CMS) Interoperability and Patient Access rule, and the technical requirements outlined in this rule. We walk through the various implementation guides referenced for this rule. We also provide details on how to configure the Azure API for FHIR® to support these implementation guides.
18
18
19
19
20
20
## Rule overview
@@ -25,17 +25,17 @@ In August 2020, CMS detailed how organizations can meet the mandate. To ensure t
25
25
26
26
There are three main pieces to the Interoperability and Patient Access ruling:
27
27
28
-
***Patient Access API (Required July 1, 2021)** – CMS-regulated payers (as defined above) are required to implement and maintain a secure, standards-based API that allows patients to easily access their claims and encounter information, including cost, as well as a defined subset of their clinical information through third-party applications of their choice.
28
+
***Patient Access API (Required July 1, 2021)** – CMS-regulated payers (as previously defined) are required to implement and maintain a secure, standards-based API that allows patients to easily access their claims and encounter information including cost, as well as a defined subset of their clinical information using third-party applications of their choice.
29
29
30
-
***Provider Directory API (Required July 1, 2021)** – CMS-regulated payers are required by this portion of the rule to make provider directory information publicly available via a standards-based API. Through making this information available, third-party application developers will be able to create services that help patients find providers for specific care needs and clinicians find other providers for care coordination.
30
+
***Provider Directory API (Required July 1, 2021)** – CMS-regulated payers are required by this portion of the rule to make provider directory information publicly available via a standards-based API. Through making this information available, third-party application developers are able to create services that help patients find providers for specific care needs and clinicians find other providers for care coordination.
31
31
32
-
***Payer-to-Payer Data Exchange (Originally required Jan 1, 2022 - [Currently Delayed](https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index))** – CMS-regulated payers are required to exchange certain patient clinical data at the patient’s requestwith other payers. While there's no requirement to follow any kind of standard, applying FHIR® to exchange this data is encouraged.
32
+
***Payer-to-Payer Data Exchange (Originally required Jan 1, 2022 - [Currently Delayed](https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index))** – CMS-regulated payers are, at the patient’s request, required to exchange with other payers certain patient clinical data. While there's no requirement to follow any kind of standard, applying FHIR® to exchange this data is encouraged.
33
33
34
34
## Key FHIR concepts
35
35
36
-
As mentioned above, FHIR R4 is required to meet this mandate. In addition, there have been several implementation guides developed that provide guidance for the rule. [Implementation guides](https://www.hl7.org/fhir/implementationguide.html) provide extra context on top of the base FHIR specification. This includes defining additional search parameters, profiles, extensions, operations, value sets, and code systems.
36
+
As previously mentioned, FHIR R4 is required to meet this mandate. In addition, there are several implementation guides that provide guidance for the rule. [Implementation guides](https://www.hl7.org/fhir/implementationguide.html) provide extra context on top of the base FHIR specification. This includes defining additional search parameters, profiles, extensions, operations, value sets, and code systems.
37
37
38
-
The Azure API for FHIR has the following capabilities to help you configure your database for the various implementation guides:
38
+
The Azure API for FHIR has the following capabilities to help you configure your database for the various implementation guides.
39
39
40
40
*[Support for RESTful interactions](fhir-features-supported.md)
41
41
*[Storing and validating profiles](validation-against-profiles.md)
@@ -47,26 +47,28 @@ The Azure API for FHIR has the following capabilities to help you configure your
47
47
The Patient Access API describes adherence to four FHIR implementation guides:
48
48
49
49
*[CARIN IG for Blue Button®](http://hl7.org/fhir/us/carin-bb/STU1/index.html): Payers are required to make patients' claims and encounters data available according to the CARIN IG for Blue Button Implementation Guide (C4BB IG). The C4BB IG provides a set of resources that payers can display to consumers via a FHIR API and includes the details required for claims data in the Interoperability and Patient Access API. This implementation guide uses the ExplanationOfBenefit (EOB) Resource as the main resource, pulling in other resources as they're referenced.
50
+
50
51
*[HL7 FHIR Da Vinci PDex IG](http://hl7.org/fhir/us/davinci-pdex/STU1/index.html): The Payer Data Exchange Implementation Guide (PDex IG) is focused on ensuring that payers provide all relevant patient clinical data to meet the requirements for the Patient Access API. This uses the US Core profiles on R4 Resources and includes (at a minimum) encounters, providers, organizations, locations, dates of service, diagnoses, procedures, and observations. While this data may be available in FHIR format, it may also come from other systems in the format of claims data, HL7 V2 messages, and C-CDA documents.
51
-
*[HL7 US Core IG](https://www.hl7.org/fhir/us/core/toc.html): The HL7 US Core Implementation Guide (US Core IG) is the backbone for the PDex IG described above. While the PDex IG limits some resources even further than the US Core IG, many resources just follow the standards in the US Core IG.
52
52
53
-
*[HL7 FHIR Da Vinci - PDex US Drug Formulary IG](http://hl7.org/fhir/us/Davinci-drug-formulary/index.html): Part D Medicare Advantage plans have to make formulary information available via the Patient API. They do this using the PDex US Drug Formulary Implementation Guide (USDF IG). The USDF IG defines a FHIR interface to a health insurer’s drug formulary information, which is a list of brand-name and generic prescription drugs that a health insurer agrees to pay for. The main use case of this is so that patients can understand if there are alternative drug available to one that has been prescribed to them and to compare drug costs.
53
+
*[HL7 US Core IG](https://www.hl7.org/fhir/us/core/toc.html): The HL7 US Core Implementation Guide (US Core IG) is the backbone for the PDex IG previously described. While the PDex IG limits some resources even further than the US Core IG, many resources follow the standards in the US Core IG.
54
+
55
+
*[HL7 FHIR Da Vinci - PDex US Drug Formulary IG](http://hl7.org/fhir/us/Davinci-drug-formulary/index.html): Part D Medicare Advantage plans have to make formulary information available via the Patient API. They do this using the PDex US Drug Formulary Implementation Guide (USDF IG). The USDF IG defines a FHIR interface to a health insurer’s drug formulary information, which is a list of brand-name and generic prescription drugs that a health insurer agrees to pay for. The main use case is so patients can understand if there are alternative drugs available to one that has been prescribed to them, and to compare drug costs.
54
56
55
57
## Provider Directory API Implementation Guide
56
58
57
-
The Provider Directory API describes adherence to one implementation guide:
59
+
The Provider Directory API describes adherence to one implementation guide.
58
60
59
61
*[HL7 Da Vinci PDex Plan Network IG](https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/): This implementation guide defines a FHIR interface to a health insurer’s insurance plans, their associated networks, and the organizations and providers that participate in these networks.
60
62
61
63
## Touchstone
62
64
63
-
To test adherence to the various implementation guides, [Touchstone](https://touchstone.aegis.net/touchstone/) is a great resource. Throughout the upcoming tutorials, we'll focus on ensuring that the Azure API for FHIR is configured to successfully pass various Touchstone tests. The Touchstone site has a great amount of documentation to help you get up and running.
65
+
To test adherence to the various implementation guides, [Touchstone](https://touchstone.aegis.net/touchstone/) is a great resource. Throughout the upcoming tutorials, we focus on ensuring that the Azure API for FHIR is configured to successfully pass various Touchstone tests. The Touchstone site has extensive documentation to help you get up and running.
64
66
65
67
## Next steps
66
68
67
-
Now that you have a basic understanding of the Interoperability and Patient Access rule, implementation guides, and available testing tool (Touchstone), we’ll walk through setting up the Azure API for FHIR for the CARIN IG for Blue Button.
69
+
Now that you have a basic understanding of the Interoperability and Patient Access rule, implementation guides, and an available testing tool (Touchstone), we walk through setting up the Azure API for FHIR for the CARIN IG for Blue Button.
68
70
69
71
>[!div class="nextstepaction"]
70
72
>[CARIN Implementation Guide for Blue Button](carin-implementation-guide-blue-button-tutorial.md)
71
73
72
-
FHIR® is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.
0 commit comments