CARIN Conformance
Starting with Version 2, released in 2021, the CMS Blue Button API began targeting conformance to the CARIN Alliance FHIR implementation guide: CARIN Consumer Directed Payer Data Exchange, commonly referred to as the "CARIN IG for Blue Button" or "C4BB". This document provides the following information relating to ongoing efforts to ensure conformance to the CARIN IG.
- Background on FHIR Conformance and CARIN
- Methodology
- Findings
- Next Steps
CMS is strongly committed to conforming to nationally recognized standards, recognizing that this kind of adherence is a critical aspect of streamlining and improving healthcare interoperability. Conformance to a specification, in simple terms, means that an implementation satisfies the requirements and criteria declared by the specification. In FHIR, conformance requirements and criteria are defined using things such as Cardinality, Terminology Bindings, Invariants (constraints) and a host of other mechanisms.
In practice, conforming to the base FHIR specification isn't really that useful. Since the base FHIR specification is incredibly broad, covering an almost infinite number of possible uses cases, it defines very few specific requirements. For example, in the Patient resource, the identifier attribute is not mandatory. In many data exchange use cases, this would be unacceptable in terms of conformance and validation. On the flip side, there are use cases where mandating a Patient identifier would be equally unacceptable.
The FHIR specification offers this description:
"the FHIR specification is a 'platform specification' - it creates a common platform or foundation on which a variety of different solutions are implemented. As a consequence, this specification usually requires further adaptation to particular contexts of use" (FHIR R4 Specification, Profiling FHIR)
Because Implementation Guides generally are focused on specific data exchange use cases, they will be much more precise and strict about expected behaviors. Subsequently, from an interoperability perspective, it is often more useful to claim conformance with an Implementation Guide than to declare conformance with the base FHIR specification.
This is where the CARIN alliances comes in. The CARIN Alliance is an HL7 FHIR Accelerator program which brings domain experts and implementers together to advance the use of HL7 FHIR standards in health care. The CARIN Alliance Health Plan Workgroup was organized to develop a specification for a FHIR-based API that...
- Targets the use case of consumer-directed payer data exchange
- Applies to the entire industry (e.g. public and private payers, not just Medicare)
- Can be implemented easily by consumer-facing applications.
Generally speaking there are three categories of conformance testing:
- Resource Validation: Validate that the resources being exchanged are conformant to the specification or IG
- Server Testing: Validate that the servers behavior is conformant to the specification or IG
- Client Testing: Testing and validating client application behavior
For the initial phase of this effort, the focus is on Resource Validation. Future efforts will likely incorporate Server Testing as well.
To perform Resource Validation, we employed the standard FHIR Validator against version 1.1.0 (STU1) of the CARIN Implementation Guide. For data input, we used a synthetic beneficiary, with a data set consisting of well-populated FHIR resources representing all Medicare claim types (Inpatient, Outpatient, Carrier, SNF, etc.). The FHIR validator assigns a severity of Error, Warning or Information for each line item result. Prioritizing the Errors, we carefully analyzed each result to determine cause and draft a proposed solution. We also categorized each result in terms of impact as illustrated below (the categories are loosely based on these definitions in the FHIR specification). Categorizing and analyzing the validation results in this way helps prioritize and incorporate solutions while preventing disruption to existing consumers of the Blue Button API.
| Category | Description |
|---|---|
| Substantive, Non-Breaking | The solution requires a substantive change but should NOT break existing applications |
| Breaking Change | The solution requires a change that will likely affect or break existing applications. This change should be targeted for a future major release (e.g. V3) |
| Breaking Change w/ Workaround | The solution requires a breaking change but there is a temporary/interim workaround solution available that can be considered within a minor release or service pack |
| CARIN | The cause and solution relates to a known or potential issue in the CARIN IG |
Overall, we identified 30 issues from the above mentioned process. For perspective, the Blue Button API maps over 1300 data elements that are sourced from the CMS Chronic Conditions Warehouse. The good news is that of the 30 issues, 40% are substantive, meaning that the resulting change should not break any existing consumers of the API. Conversely, 10% of the issues will require a breaking change to resolve - those cases will have to wait for a major release. Twenty three percent of the issues are items where we are actively working with CARIN.
The nature of the issues varies from relatively minor items, such as Meta.Profile requirements, to more significant issues relating to ValueSets, CodeSystems and Slice definitions.
An example of an issue is the CARIN requirement to supply the Name and Meta.lastUpdated attributes in the Organization resource, neither of which are currently populated in the Blue Button API. The Blue Button development team is working to address this issue. A mockup of the potential solution is illustrated below
"contained" : [ {
"resourceType" : "Organization",
"id" : "provider-org",
"name" : "ACME Org",
"meta" : {
"lastUpdated" : "2019-12-12T09:14:11+00:00",
"profile" : [ "http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-Organization" ]
},Note however that this case also provides an example where additional collaboration with CARIN is necessary. In Blue Button, the organization resource is a contained resource and the FHIR specification does not allow population of the Meta.lastUpdated attribute in a contained resource. So while the mockup above conforms to the CARIN IG, it still fails when run thru the FHIR validator due to the FHIR specification constraint. The Blue Button team brought this to CARIN and they are considering adapting their rule to only apply to non-contained resources.
Another example illustrates a ValueSet issue. For professional claims, the CARIN IG requires adjudication reasons (Eob.item.adjudication.reason) to be bound to an X12 ValueSet. As an example, in certain instances Blue Button currently provides adjustment reasons utilizing a CMS ValueSet called Carrier Line Reduced Payment Physician Assistant Code, which does not meet the CARIN requirements. A mockup of the potential solution is shown below. Note that while the X12 coding has been added, the original CMS coding is still supplied to support backwards compatibility. To get this change in production, the Blue Button development team is also working thru licensing and mapping issues with the X12 ValueSet.
"reason" : {
"coding" : [ {
"system" : "https://x12.org/codes/claim-adjustment-reason-codes",
"code" : "54",
"display" : "Multiple physicians/assistants are not covered in this case."
}, {
"system" : "https://bluebutton.cms.gov/resources/variables/carr_line_rdcd_pmt_phys_astn_c",
"code" : "0",
"display" : "N/A"
} ]
}Tickets have been created for all the issues found during the process described above, and the Blue Button development teams are actively working on development, testing and release for each item. More information will be posted in the CMS GitHub as this effort progresses. See also the API ChangeLog. We will also continue to work with the CARIN alliance, helping to refine and shape the CARIN IG as needed. The Blue Button team will also continue to test and validate against future versions of the CARIN IG including the soon to be released STU2 (1.2.0) version. And the Blue Button team will work towards expanding conformance testing, using tools such as Aegis Touchstone for server testing.