PAC: ONC-CMS Interoperability RFI

RFI: File:ONC-CMS Interoperability RFE.pdf

Potential Themes

From Hans Buitendijk

• Key sections with examples where HHS/CMS could provide incentives jumped out to me that we may want to specifically respond to (italic text copied from RFI):
  • HHS can collaborate in the development of new e-specified measures of care coordination that encourage electronic sharing of summary records following transitions in care. This could be incorporated into and aligned across multiple programs including the EHR Incentive Program, and other CMS quality reporting programs.
    • Potential feedback: HL7 is has standards and continues to improve on them to communicate e-definitions (HQMF) and quality reports (QRDA) consistently across providers and with government agencies. We continue to work with ONC and CMS stakeholders to ensure these standards meet the ever evolving quality measure standards. HL7 encourages definitions of e-measures that can be easily derived from existing data that is the natural by-product of clinical and administrative processes that HIT supports to avoid duplicative and/or cumbersome data collection to populate the necessary reports.
  • CMS could promote the use of BlueButton. The Blue Button provides easy electronic access to personal health information for consumers. To strengthen its success, ONC released guidelines for data holders and application developers that support the growth of an ecosystem of tools to help consumers manage their health. The Blue Button Plus guidelines include specifications for a structured data format (consistent with Meaningful Use Stage 2), and enable updates of the information contained in individual consumer’s health records to be sent automatically to the applications of their choice. Tools built on Blue Button Plus specifications could be made available to all CMS beneficiaries, and widely promoted by healthcare providers and via avenues such as the Medicare Handbook, Medicare.gov, and Medicare Advantage plans.
    • Potential feedback: HL7 supports the continued harmonization of the Blue Button payload, a document, with similar documents used for summary of care based on the C-CDA family of document types. This will reduce standards definition and implementation efforts to consistently exchange documentation between providers and patients, as well as across providers.
• Of the 9 questions specifically raised, only part of one jumped out where we may want to specifically respond:
  • What specific HHS policy changes would significantly increase standards based electronic exchange of laboratory results?
    • Potential answer: Through CLIA or related regulations adopt the same Laboratory Test Compendium, Orders, and Result implementation guides currently referenced in the 2014 Edition and upcoming editions as a certification of the laboratory to ensure consistent exchange between LIS and EHR.

From Dennis Giokas

• In my opinion the lack of interoperability is less about:

1. Standards (i.e. the version of HL7)
2. Transports

• It is more about (in no particular order):

1. Culture – clinician and vendor. Is there a culture to interoperate and share/exchange data. If not, as they say “culture eats strategy for breakfast”.
2. Application architecture and design. Older applications were never designed for an enterprise interoperability paradigm. (Which is very different than systems integration.)
3. Application functionality. An application can’t do an interoperability function if it cannot do the same or similar thing locally. For example, one cannot send/receive a structured, coded problem list of the application does not capture (i.e. in the user interface) and persist it that way locally.
4. Application workflow and screen flow. Where does the interoperability function fit in the app’s current state design? And what has to change? Interoperability could require extensive changes to the app.
5. Data – The information model, data types, vocab bindings. Some applications do not have the data or the data in the right form to interoperate per the specs, to send or receive.
6. Funding – if the end user is not asking for it, why should the vendor do it. In Canada we will pay the vendor 75% of the R&D cost to do the interoperability work. Then they have to pay the costs to maintain it. If it is a function that the user is not asking for nor enhances sales, then why take the money and do the work.
7. The specs. You cannot successfully implement from a standards specification. Variability in interpretation and understanding of the nuances lead to implementation variances.