Background

This topic provides background information for the Measure Calculation Tool prototype. The Measure Calculation Tool (MCT) is an open-source, end-to-end software system, designed to connect with eligible hospital and clinicians FHIR APIs, gather data across provider EMRs, validate the data received from a provider API, calculate measure score(s) and submit quality measure reports.

Prototype Capabilities

What use cases are covered by this prototype?

1. Request Calculation - A user uses the Reporting Client to Request a Calculation. In the simplest case this involves selecting a measure to be run and a patient to be evaluated.
2. Request Measure Artifacts - The Measure Calculation Tool requests the Measure Artifacts from the Knowledge Repository and uses them to determine the effective data requirements for the measure.
3. Terminology - The Measure Calculation Tool uses the effective data requirements for the measure to determine the appropriate value sets and associated versions and code system versions, and uses those to retrieve the appropriate value set expansions from the Measure Terminology Service.
4. Gather - The Measure Calculation Tool uses the effective data requirements and appropriate value set expansions to retrieve the relevant data for the measure from the Provider Site System Provider FHIR api
5. Evaluate - The Measure Calculation Tool uses the relevant data retrieved from the Provider Site System Provider FHIR api to calculate the Measure Score, producing a MeasureReport with the result and references to the relevant data used to calculate the measure.
6. Submit - The Measure Calculation Tool constructs a Bundle containing the MeasureReport and all the referenced relevant data and submits it to the Receiving System.
7. Response - The Measure Calculation Tool returns the MeasureReport bundle to the Reporting Client, which then displays the resulting measure score and relevant data to the user.

Prototype Scope

• Decision: For the prototype, the MCT will have bundles with the measure specifications and run the data requirements analysis itself, rather than rely upon a knowledge repository. While the knowledge repository is important to be discussed and will be noted in the architecture, it is out of scope for the prototype.
• Rationale: This addresses questions CMS has over who would potentially stand up/own the knowledge repository and addresses scope and budget concerns CMS raised over the knowledge repository in this option period. The specifications also don't have to be in a knowledge repository to function.
• Decision: For the prototype, we will have bundles that will include the value sets, rather than having a separate, terminology service.
• Rationale: There is significant effort in managing a terminology service, and a terminology service is not crucial for this prototype of the MCT to demonstrate the scoped functionalities we described.
• Decision: For the prototype, we assume we can get a group resource that tells us all the patients we would run the measure on, rather than actually attributing/selecting the patients that would be in that group.
• Rationale: There is significant variation in how patient attribution is determined across programs and quality reporting use cases. This use case along with other provider-related use cases for determining attribution has been documented in the DaVinci Attribution IG. The Data Exchange for Quality Measures IG makes use of the DaVinci attribution IG to support this use case, and so the Measure Calculation Tool prototype is designed to accept a Group resource to specify populations for quality measure reporting.
• Decision: The MCT will do the measure evaluation. Instead of using the receiving system to perform measure evaluation, the reporting client would call a $gather operation defined on the MCT to gather data, validate it, and perform measure calculation. This gather step is pulling all the data and getting it into the MCT for final calculation.
• Rationale: This is within the scope of work to demonstrate desired functionalities without doing extra steps that are not absolutely necessary for a prototype.

Assumptions and Considerations

Question 1

Question about policy in place for providers to publish FHIR endpoint?

ONC Standards-based Application programming Certification program requires, in "§ 170.315(g)(10) to implement the 21st Century Cures Act's requirement that developers of certified health IT publish APIs that can be used "without special effort.” This new certification criterion requires standardized API access for single patient and population services and is limited to API-enabled "read” services using the HL7® Fast Healthcare Interoperability Resources (FHIR®) standard. The FHIR standard, in addition to a set of adopted implementation specifications, provides known and consistent technical requirements for software developers." The MCT will leverage this policy

Question 2

Question about how to distinguish between hospitals?

We will use CCN or Certification number. This number does not change just because an institution has been sold, or has changed ownership or its form of business organization. If 2 or more pre-existing provider enterprises have merged, but continue to operate as separate facilities, each will have a separate provider agreement and will keep its original number. This is true even though the merged-but-separate facilities may adopt a common name. However, if the merged facilities operate as a single institution, it must submit a single cost report, which necessitates a single provider agreement/CCN. However, I do not see the CCN in the USCDI V3, Just encounter location. I do know that there was an issue with MITRE lantern project which assess the publicly available fhir endpoints, because vendors where not filing out the organization name or NPI ID . https://lantern.healthit.gov/?tab=organizations_tab. There are about 5299 entities they identified. Considering these include ACS and other institutions, its safe to say that's serious undercount. I am not sure about the walking of an NPI ID to a CCN Identifying patients

As of 2019 Experian announced every person in US had been assign a universal patient identifier UPI. And the US senate removed the ban that kept us from instituting it, October 22, 2021. See attachment for more information

Question 3

Question about security concerns?

Further research is required to determine if SMART-on-FHIR Backend suffices for the 21st Century Cures act security requirement or will we need further consideration?