Dynamic Health IT (DHIT) was in attendance for the Da Vinci
FHIR Connectathon hosted by GuideWell (parent company of Florida Blue) in
Jacksonville Florida. For those of you
not familiar, the Da Vinci Project is a collaboration of trail-blazers in the
healthcare space who are looking to revolutionize information sharing. It is a private sector initiative comprised
of experts from some of the largest and most prestigious payer, provider and
vendors in the healthcare marketplace.
Their goal is to accelerate the adoption of HL7® FHIR® as the standard
to support and integrate data exchange for value-based care (VBC) with a focus
on provider/payer data exchange.
FHIR Connectathon hosted by GuideWell (parent company of Florida Blue) in
Jacksonville Florida. For those of you
not familiar, the Da Vinci Project is a collaboration of trail-blazers in the
healthcare space who are looking to revolutionize information sharing. It is a private sector initiative comprised
of experts from some of the largest and most prestigious payer, provider and
vendors in the healthcare marketplace.
Their goal is to accelerate the adoption of HL7® FHIR® as the standard
to support and integrate data exchange for value-based care (VBC) with a focus
on provider/payer data exchange.
The Connectathon featured three different tracks. We participated in the Clinical Reasoning
Track, which focuses on exploring the use of FHIR to calculate Clinical Quality
Measures (CQMs). As we’ve contributed to this track, we’ve also increased our
understanding of issues related to migrating to FHIR-based CQMs. For DHIT, this
means the integration of separate products – Dynamic FHIR Server with
CQMsolution.
Track, which focuses on exploring the use of FHIR to calculate Clinical Quality
Measures (CQMs). As we’ve contributed to this track, we’ve also increased our
understanding of issues related to migrating to FHIR-based CQMs. For DHIT, this
means the integration of separate products – Dynamic FHIR Server with
CQMsolution.
As it stands today, FHIR data types are not used in the
calculation of eCQMs. (eCQMs are the Clinical Quality Measures generated
directly from EHR data with no intervening manual abstracting process). But Da
Vinci members are looking to obsolete the Quality Data Model (QDM) data
elements currently used for calculation and presentation in the QRDA Cat I
files and replace them with FHIR. A FHIR
Measure Report could replace the QRDA Cat I and QRDA Cat III files. FHIR also
offers new operations that instruct the FHIR server to perform measure
calculation. Tangentially, DHIT has
explored the use of the 2.1 CCDA as a data source for calculating eCQMs (more
on that later).
calculation of eCQMs. (eCQMs are the Clinical Quality Measures generated
directly from EHR data with no intervening manual abstracting process). But Da
Vinci members are looking to obsolete the Quality Data Model (QDM) data
elements currently used for calculation and presentation in the QRDA Cat I
files and replace them with FHIR. A FHIR
Measure Report could replace the QRDA Cat I and QRDA Cat III files. FHIR also
offers new operations that instruct the FHIR server to perform measure
calculation. Tangentially, DHIT has
explored the use of the 2.1 CCDA as a data source for calculating eCQMs (more
on that later).
The Clinical Reasoning Track is evolving as well. Previous
iterations used “normal” QDM-based eCQMs but relied on FHIR patient
data that was converted using QDM to QI Core Mappings. Developers have been
hard at work doing a trial run to populate existing eCQMs by using FHIR data
types. This will make it possible to run FHIR-based eCQMs against FHIR data
elements.
iterations used “normal” QDM-based eCQMs but relied on FHIR patient
data that was converted using QDM to QI Core Mappings. Developers have been
hard at work doing a trial run to populate existing eCQMs by using FHIR data
types. This will make it possible to run FHIR-based eCQMs against FHIR data
elements.
DaVinci has expanded this track include additional
operations related to submitting and collecting data. These include the
submission of data from the producer to the consumer. In this scenario, an EHR might submit data directly
to a Payer. Additionally, consumers can request data from the producer using a
“Collect Data” operation or subscribe to the producer’s Subscription Service to
be notified when CQM data becomes available. All of these operations limit the scope of
data collected to what is required by the measures.
operations related to submitting and collecting data. These include the
submission of data from the producer to the consumer. In this scenario, an EHR might submit data directly
to a Payer. Additionally, consumers can request data from the producer using a
“Collect Data” operation or subscribe to the producer’s Subscription Service to
be notified when CQM data becomes available. All of these operations limit the scope of
data collected to what is required by the measures.
During this Connectathon we focused on one CQM – Venous
Thromboembolism Prophylaxis (VTE-1). Some of the issues we faced were the sheer
scope of changes required to begin this process. For example, the version of the CQL language
itself differs between the current CMS version of the measure and the newly
released FHIR version of the measure. In
the end Dynamic Health IT was able to make considerable progress towards the
goal of the track.
Thromboembolism Prophylaxis (VTE-1). Some of the issues we faced were the sheer
scope of changes required to begin this process. For example, the version of the CQL language
itself differs between the current CMS version of the measure and the newly
released FHIR version of the measure. In
the end Dynamic Health IT was able to make considerable progress towards the
goal of the track.
Back to
the challenge of using the 2.1 CCDA as a data source for calculating
eCQMs: Based on our research to-date, many current eCQMs cannot be
accurately calculated from standard 2.1 CCDA data elements. NCQA offers an eCQM
certification process that involves calculating quality measures from CCDA
documents but it only includes a subset of the MIPS/QPP eCQMs and some are
older definitions. Why is this? We suspect it is because the remainder are
problematic to calculate from a CCDA.
the challenge of using the 2.1 CCDA as a data source for calculating
eCQMs: Based on our research to-date, many current eCQMs cannot be
accurately calculated from standard 2.1 CCDA data elements. NCQA offers an eCQM
certification process that involves calculating quality measures from CCDA
documents but it only includes a subset of the MIPS/QPP eCQMs and some are
older definitions. Why is this? We suspect it is because the remainder are
problematic to calculate from a CCDA.
There
are several reasons for this:
are several reasons for this:
- Many measures include exceptions and exclusions and these
are not captured in a standard CCDA. For
example, skipping a Breast Cancer screening for a woman with bi-lateral
mastectomies would be an exclusion. “Patient
refused to get a flu shot” would be an exception. Calculating eCQMs without exceptions and
exclusions is possible but will result in an inaccurate and lower score. - A typical 2015 Edition Certified 2.1 CCDA (the kind produced
by most EHRs) lacks a standard representation for the Adverse Event used
by CMS347v2 (Statin Therapy). - Some measures call for Assessments but there’s no standard way to convey the result of the Assessment in the CCDA.
DHIT’s
flagship product ConnectEHR is certified for CCDA creation. We are currently
working with HL7 to expand the CCDA data elements to accommodate more of the
eCQM measure requirements. Most current adjustment to CCDA is related to
negation. There are also other issues relate to using a CCDA as a data source, such
as values being provided as free-text, rather than being codified and different
EHR systems capturing the same clinical values/events in different ways. Despite these obstacles, we continue to
pursue the eCQM data capture challenge and look forward to participating
in the next Connectathon in Atlanta.
Hope to see you there!
flagship product ConnectEHR is certified for CCDA creation. We are currently
working with HL7 to expand the CCDA data elements to accommodate more of the
eCQM measure requirements. Most current adjustment to CCDA is related to
negation. There are also other issues relate to using a CCDA as a data source, such
as values being provided as free-text, rather than being codified and different
EHR systems capturing the same clinical values/events in different ways. Despite these obstacles, we continue to
pursue the eCQM data capture challenge and look forward to participating
in the next Connectathon in Atlanta.
Hope to see you there!
