Month: February 2022

DCE: Direct Contracting Entities

Recent risk-sharing payment model in Medicare, launched by CMS, to promote value-based and coordinated care.

It differs from ACOs in terms of the requirements and level of risk available (refer to Table 1). Also, CMS would offer monthly Total Care Capitation or Primary Care Capitation (capitated and risk-adjusted) under two models – Professional and Global.

Interoperability is imperative for a DCE to succeed, Why?

• A DCE should be able extract a cohort of patient records or access to patient-level data across a patient population
• Integration of an internal clinical system with an EHR
• Aggregating data from network of physicians/providers
• Combining claims and electronic health record data to calculate quality measures
• Building datasets to develop and tune machine-learning algorithms
• Federated data sharing networks
• Reporting performance metrics to CMS
• Transmission of Claim and Claim Line Feed Reports (CCLF) from CMS
• Alerting the DCE in real-time when their patient is admitted or discharged from an acute or post-acute care setting (monitoring of care path)
• Inclusion of patients in their own care delivery

TIMELINE

QHIN: Qualified Health Information network

Network of organizations working together to share data. QHINs will connect directly to each other to ensure interoperability between the networks they represent. By establishing a network of QHINs, TEFCA (Trusted Exchange Framework & Common Agreement) seeks to provide a single “on-ramp” for nationwide connectivity and ensure the integrity and security of data as it is delivered where and when needed.

Interoperability Play

• Connectivity Broker is a service provided by a Qualified HIN that provides all of the following functions with respect to all Permitted Purposes: master patient index (federated or centralized); Record Locator Service; Broadcast and Directed Queries, and EHI return to an authorized requesting Qualified HIN.
• A Participant is a person or entity that participates in the QHIN. Participants connect to each other through the QHIN, and they access organizations not included in their QHIN through QHIN-to-QHIN connectivity. Participants can be HINs, EHR vendors, and other types of organizations.
• An End User is an individual or organization using the services of a Participant to send and/or receive electronic health info

Further Info on QHINs

Examples of QHINs

How will TEFCA work

Policy mandate on Interoperability, Data Access, HIE

Policy Mandate

• Jun 2020: ONC published the Final Rule for the 21st Century Cures Act, establishing FHIR R4 as the standard required for Health IT Certification
• Jun 2020: The 21st Century Cures Act, the ONC Cures Act Final Rule, and the CMS Interoperability and Patient Access rule have accelerated the ability for an individual to access their personal health information via an application of their choice leveraging HL7® FHIR® APIs

The ONC Interoperability and Information Blocking Final Regulation focus on enforcing aspects of the 21st Century Cures Act (interoperability, data access, and exchange/electronic health information (EHI)) and addresses the consequences of information blocking.

High-level timeline on compliance with the ONC’s Cures Act Final Rule

These rules impact patients, clinicians/providers, payers, ACOs/DCEs, vendors, developers – everybody in a healthcare ecosystem

Patients

• Access all their EHI without charge

Payers

• Implement a patient access API and a provider directory API
• Facilitate data exchange between payers using data identified in USCDI
• Increase the frequency of federal/state data exchanges
• Expose claims data via FHIR so that if a patient changes their health plan, they will be able to move data between the payers

Providers

• Update their digital contact information (in the National Plan and Provider Enumeration System (NPPES)) and/or information blocking. Failure to do so will lead to public reporting, which will affect provider performance metrics
• Improve ADT event messaging to meet care coordination requirements, allowing providers identified by the patient to receive the necessary notifications for treatment and care coordination (although CMS and ONC have yet to identify a standard for content format or delivery)
• Providers will have to send entire patient medical records to patient’s current health plan

Further Details on the Ruling!

There are three main pieces to the Interoperability and Patient Access ruling:

Patient Access API (Required July 1, 2021) – CMS-regulated payers 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.

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.

Payer-to-Payer Data Exchange (Required January 1, 2022) – CMS-regulated payers are required to exchange certain patient clinical data at the patient’s request with other payers.

Influencers and community projects to promote Interoperability

Da Vinci Project

Da Vinci stakeholders are industry leaders and health IT technical experts who are working together to accelerate the adoption of HL7 FHIR as the standard to support and integrate value-based care (VBC) data exchange across communities

Gravity Project

To create and maintain a consensus-building community to expand available SDOH (Social Detrimental of Health) core data for interoperability and accelerate standards-based information exchange by using HL7® FHIR®

CARIN

CARIN is committed to working closely with government leaders to enable consumers and their authorized caregivers to access more of their digital health information with less friction

Argonaut Project

Private sector initiative to rapidly develop a first-generation FHIR-based API and Core Data Services specification to enable expanded information sharing for EHR and other HIT based on Internet standards and architectural patterns and styles.