Key to these rules, which lay the foundation for a post-Meaningful Use incentive-driven Health IT ecosystem, is the use of APIs – for the uninitiated, “application programming interfaces” – or simplified connectors that allow for easier transfer of data.
The Meaningful Use requirements have themselves been simplified — whittled down to eight high-level requirements, expressed as program goals or objectives:
- Protect Patient Health Information
- Electronic Prescribing
- Clinical Decision Support
- Computerized Provider Order Entry
- Patient Electronic Access to Health Information
- Coordination of Care through Patient Engagement
- Health Information Exchange (HIE)
- Public Health and Clinical Data Registry Reporting
The objectives and their associated measures are designed to
- Align with national health care quality improvement efforts.
- Promote interoperability and health information exchange.
- Focus on the 3-part aim of reducing cost, improving access, and improving
quality.
For most of the eight objectives, two out of three measures must be met. (Core and optional measures have been replaced with required objectives mixed with some flexibility in how to demonstrate compliance with the objectives.) The federales have done away with many measures, including those that have “topped out” (i.e., most, if not all, providers meet or exceed the requirements prescribed in Stage 1 or 2).
Significantly, the measures regarding access to information may be met either through existing pathways (e.g. the view/download/transmit measure of Stage 2), or through the use of APIs (e.g., if 80% of patients have been given the ability to access their data through an API then the measure has been satisfied). Obviously, the devil is in the details, and the federales have asked for comment on a whole host of them. The APIs need to be ONC-certified, and certification standards are proposed in the ONC rule out for public comment. (The certification rule envisions a broader range of things that might be certified, and describes certification standards that are intended to be more closely tailored to the functionality of specific health IT services or products that may be certified). In a significant comment, the regulators also say: “[W]e do not believe it would be appropriate for [providers] to charge patients a fee for accessing their information using an API.”
In addition to using APIs to get data to patients, the objectives encourage sharing of patient-generated data with providers (including through APIs), an issue that has long given rise to concerns by providers about being overwhelmed with information, about alarm fatigue. The key, of course, will be intelligent filtering of the data so that it may be presented to clinicians and patients as actionable information.
On the health information exchange front, the proposal is surprisingly limited and at the same time raises a lot of questions with respect to which the government is seeking input. ONC has been touting its roadmap to interoperability, yet the HIE measures are really just baby steps: (1) outbound — creation and transmission of a summary of care record; (2) inbound — incorporation of a summary of care document from a source outside the provider’s EHR and (3) clinical information reconciliation covering medications (including allergies) and a current problem list. In the real world, multiple providers care for patents with chronic illnesses in overlapping timelines. While these requirements can work in this context, they seem designed for sequential admissions and discharges.
The focus on APIs in other contexts highlights the absence of discussion of APIs with respect to communications between EHR systems. Tech not yet ready for prime time should not be mandated as part of Meaningful Use (see John Halamka on the Argonaut Project), but this sort of closer communication is clearly what needs to happen, and sooner rather than later. Patients and clinicians are demanding it, and the industry needs to respond.
Photo credit: Flickr CC USGSBIML