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)[Buitendijk, Hans] Somewhat disagree. When using base standards, there is a lot of ambiguity creating mis-matches between systems that all claim to be standard. That is not only true for V2, but also V3. Key is that we have for specific use cases well defined implementation guides on top of those standards. Depending on realm and area you see more or less of that.
2. Transports[Buitendijk, Hans] Agreed.

• 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”. [Buitendijk, Hans] Agreed. Include in culture “incentives” and that is even more clear. If reimbursement is fee for service, the need to interoperate across providers is less so than if reimbursement is based on episodes of care or fully capitated (assuming all other factors don’t change).
2. Application architecture and design. Older applications were never designed for an enterprise interoperability paradigm. (Which is very different than systems integration.)[Buitendijk, Hans] Somewhat agree. Older systems were clearly more developed to be an island on themselves. Then they started to work better within one provider organization / enterprise with other systems, while now we are pushing them to interoperate across providers.
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.[Buitendijk, Hans] Agreed, but if one receives something structured and cannot deal with it locally at least one should be able to still view it. But I would argue that not every system needs to have the same functionality as the system it connects with. Is the purpose tight workflow management? View only? Analysis? Etc. So I don’t believe it needs to everything, nor does it need to use the same representation as the “interface” as long as I can understand it and recreate it.
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.[Buitendijk, Hans] Maybe, maybe not. This is a two way street where advances in functionality may require updated interoperability.
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.[Buitendijk, Hans] That’s indeed a problem!
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.[Buitendijk, Hans] Agreed. Back to incentives. If there is no need/drive to interoperate, there is no interest to build and hope they come. Although in the standards arena that happens a lot: build the standard and hope they are useful.
7. The specs. You cannot successfully implement from a standards specification. Variability in interpretation and understanding of the nuances lead to implementation variances.[Buitendijk, Hans] This is where we need to distinguish between base standard vs. implementation guide. For certain consistency we need flexible (thus ambiguous) base standards, but then we need to follow that up with clear implementation guides that remove the ambiguity. There are examples where that is done well, and where that is done so-so.