Health IT Provisions Under ARRA:
Section 4: What Is a 'Certified or Qualified' Technology?
Do We Have the Standards to Achieve an Initial Set of Health Improvement Objectives? What Is the Role of Certification?
In recent years, much of the debate around health IT has focused on existing electronic health record (EHR) software or ambitions for regional health information exchanges (HIEs). However, such systems are not the only way to achieve the objectives of meaningful use. The definition of "certified or qualified EHR technology" should not be narrowly construed within these contexts.
A broader view of IT would seed innovation rather than lock in adoption of technology based on what is available today. Health information services and technologies need to innovate and evolve rapidly, as other sectors have transformed themselves by embracing and building upon the Internet.
The needs of a large, integrated delivery network will differ greatly from those of small ambulatory practices. More complex, comprehensive EHR systems must be able to co-exist alongside just-the-basics health IT systems, personal health records (PHRs), and other Internet-enabled technologies and networks, all of which could meet an initial set of requirements for secure transport of a core set of standard data types.
Medical practices and hospitals ready to install, support, and manage more complex EHR systems should do so and receive ARRA incentives for it. However, ARRA must also be an opportunity for smaller practices—which still account for the bulk of outpatient doctor visits in the United States—to benefit from market innovation, Web-enabled tools, and lighter-weight approaches that can be demonstrated to improve health and health care outcomes.
For example, ancillary providers, health plans, national laboratories and pharmacy networks each may collect encounter, medication, laboratory result and registration data. Internet-enabled technologies that can connect to these sources and feed and manage this information securely on behalf of providers and patients should be encouraged so long as they achieve the objectives of meaningful use. There should be opportunities for these kinds of solutions to be made available or supported by the Regional Extension Centers enacted by the law, or by other community resources, new market innovations, or other secure, Internet-enabled services.
The approaches to standards and certification described below do not take as a starting point everything documented to date by the HITSP standards-harmonization body, the CCHIT certification body, or the AHIC/NeHC. The enactment of ARRA creates new requirements and urgency that could not have been foreseen by these bodies. However, it is likely that particular aspects of work by these bodies can be leveraged or adapted to support the goals of "meaningful use" and "qualified or certified EHR technology."
Shortly before President Obama appointed him as national coordinator for health information technology, David Blumenthal, MD, MPP, wrote that some currently certified EHRs "are neither user-friendly nor designed to meet [ARRA's] ambitious goal of improving quality and efficiency in the health care system."
To support meaningful use, HHS should endorse a simple specification for a minimal set of open technical standards for secure transport as well as a core set of data types. By creating an obvious and achievable starting place, HHS will enable many options for clinicians and consumers to retrieve and use information to accomplish the meaningful use objectives.
The standards that need to be defined to arrive at a simple but workable basis for meaningful use fall into three broad categories. The first is transport, a set of standards for the secure communication of the data itself. The second is packaging, a set of message headers for packaging health information messages that pass from sender to receiver. The third is the content itself, the standards defining the description of the health information itself.
- The transport or communication layer: Focus on basic standards and protocols for secure communication. HHS should endorse a simple specification for a set of open standards necessary for secure transport of data, and for defining interfaces between applications exchanging this data over the Internet. In addition, HHS and other entities will have to define standard naming conventions and technical specifications for the use of these services by all participants in the system, in order to simplify the exchange of messages.
- The packaging layer (sometimes called the message envelope): Encourage standards for packaging of health information messages. In addition to data standards needed to transport data over the network, there is also a need for standard descriptive data for the information contained in such messages, explaining what kind of data is contained in the message, and describing the time and source of its transmission. (See "package" section of table in Appendix A.) There is high potential value for HHS to explore standard packages, expressed as XML, for describing priority data types, such as care summaries, laboratory results, and medication lists.
- The content layer: Raise the bar for data standards (i.e., the health information content itself) over time. It is important that the proposed work of 2009-2012 be achievable in this short timeframe. For that reason, the required content standards should be the simplest and most available at launch, focusing on priority information types. Over time, the bar should be gradually raised for increasing numbers of data types, expressed in increasing degrees of specificity, based on pockets of early adoption. Even as standards become more robust and detailed, there will always be lag times for implementation, and there will never be a time when health networking is "finished." There will be need for increased specification as well as innovation for the foreseeable future. Where no widely adopted open content standards exist, or where non-standard data is being transmitted, the messages should still be packaged with headers describing the nature of the contents, allowing for unstructured, semi-structured, and fully structured data to travel in the same information streams. The more that ARRA incentives motivate information sharing and use, the more likely that these content-packaging standards will tighten over time with adoption and use.
It is essential that HHS and the other bodies responsible for specifying those standards keep these transport standards separate from data standards, and separate from application functions. The approach must make independent the standards for sharing any basic information securely over the Internet (i.e., the transport layer) from the standards that define how to express the specific data being shared (i.e., the packaging and content layers). Similarly, standards for packaging and describing the data should not make assumptions about how the data are to be routed over the network, nor about the functions of receiving applications.
By way of analogy, the Postal Service delivers mail without reading the contents, and without the sender or the Postal Service knowing what kind of mailbox the receiver has. The well-understood standards for sharing information securely over the Internet are Hypertext Transfer Protocol Secure (HTTPS) for transport, using Secure Socket Layer (SSL) or Transport Security (TLS) to ensure that the data are encrypted in transit, and the formats for the medical data to be transported should start with a small core of working and application-insensitive standards, and expand over time, as described below. Of the entire stack of standards, the transport standards must be the most completely defined, aggressively enforced, and durable. This is because participants in a network who are not using the same basic communication (i.e., transport) standards will not be able to exchange any information, no matter how similar their use of other data standards may be.
Effective Standards Are in Use and Can Be Specified to Achieve the Meaningful Use Criteria
- There is already a stack of standards in use for expressing the content of laboratory results and medication data, including medication history lookup in the context of e-prescriptions. (See table in Appendix A for more information.) Given the heterogeneity of the health sector, the government's approach should be to specify the use of minimal but necessary standards. The computability of these standards, which is to say their expression in terms that both humans and computers can understand, will also open the door to innovation on novel uses of this data, from decision support to visualization to rapid composite analysis for research, quality, and public health.
- Progress under ARRA should not be tied to "harmonization" of these content standards. Nor should the definition of meaningful use or certified systems be tied to complex use cases. Open content standards for medications and lab results are already in use.
- The specifications and protocols for these standards can and should be tested, and over time be made more specific based on real-world use. ARRA establishes a role for the National Institute of Standards and Technology (NIST) to pilot test standards and help drive evolution of the implementation specifications and protocols toward greater and greater specificity over time as user adoption grows.
The Need for Certification Should Be Geared Toward the Objectives of Meaningful Use, and Not From Assumed or Existing Software Features
To protect taxpayers and clinicians against fraud or faulty products, there must be mechanisms to certify systems for capabilities to achieve meaningful use. The law is clear that incentives should not reward or pay for trivial displays of technology. There also must be mechanisms (including, but not limited to, certification) to ensure that systems and organizations comply with laws and regulations on information privacy and security. However, certification by itself is not sufficient to ensure compliance with privacy policies. Examples of other policy enforcement mechanisms may include strengthened enforcement of existing laws or new statutes (state or federal), procurement requirements and legal contracts, self-attestation with third-party validation, consumer or customer-ratings, enforcement of consumer-protection laws, etc.
Despite these needs, it is important to recognize that the government's approach to defining the terms "qualified" or "certified" can either help or hurt our ability to achieve the objectives of ARRA.
As with standards, we recommend a minimally necessary approach to certification of interoperability. This paper emphasizes that ARRA incentives should neither require nor reward the mere purchase of specific applications based solely on their features or functions. Rather, the incentives should reward the capability for the system to enable a user to achieve and demonstrate meaningful use and to securely share priority information, with expectations of data completeness and quality rising over time. The solution for certification should also follow this logic.
We therefore recommend that HHS' initial approach to interoperability certification take the following steps:
- Certification for interoperability: One key thrust of certification under ARRA should be to determine whether a system can share information to achieve meaningful use objectives, i.e., whether it can receive and send the priority classes of information, in standardized formats and using standard protocols for secure transport.
-
Developing criteria for meaningful use, privacy, and security:
- The requirements for "qualified or certified" technology should have the capabilities to allow a provider to achieve meaningful use, however defined by HHS. That is to say, "certified or qualified" technology should embed capabilities to achieve, measure, and report the meaningful use metrics without requiring undue extra work for the practice to show it merits health IT incentives under ARRA.
- For a technology to be qualified or certified, it also should meet the technical aspects of privacy and security requirements under HIPAA and ARRA (e.g., audit trails, data security, authentication of patients and providers).
- Processes for development of certification criteria must be open to public comment, and no single stakeholder group should be able to dominate the proceedings.
- Testing criteria and network interfaces: In order for a system to be certified, it would have to pass a testing regimen for the transport and security protocols, as well as the minimum protocols (patient identity management, location of patient records, authentication of system users, etc.) for interfacing to laboratory and medication data. These protocols are definable today, require no new standards or harmonization, and could be validated using Web-enabled testing environments.
- Pluralistic approach to applications: This certification testing step should be open to a broad range of applications (e.g., EHRs, PHRs, HIEs, e-prescribing, Web-browser-based applications, etc.) that are capable of achieving the goals of meaningful use.
- Pluralistic approach to certification testing: The method must be market-ready, low-cost, and nimble so that certification itself does not become a vehicle, intentionally or unintentionally, for unduly slowing innovation. As with the issuing of domain names or SSL Certificates for the Web, a single set of clear criteria for certification, could be clearly defined and then administered by multiple entities.
The government should publish minimum certification and testing criteria, and then identify any entities qualified to test and certify products meet the criteria. NIST or another appropriate agency could set the core criteria for certification of meaningful use functionality, and allow multiple entities, both public and private, to do the actual certification testing. So long as these testing services all work on the same definition, these entities can then compete on their ability to provide value-added services above the minimum requirements. Once the certification protocols are defined, the door should be left open to a plurality of private certification organizations, including ones like CCHIT, to compete for public and private sector business, as there are now for other IT products and services.
