Things You Wanted to Know About the New HIT Standards But Were Too Afraid to Ask
In a previous post I discussed the interim final rule (IFR) that was recently promulgated by the Office of the National Coordinator for Health Information Technology (ONC). The previous post discussed two of the four categories of standards in the IFR. This post will look at the final two categories. In order to appreciate the purpose of the final two standards, it is worth recapitulating the basic framework upon which the IFR is based.
The ONC’s framework for the standards is to first start with the meaningful use objectives. From the broad objectives of meaningful use, the ONC establishes certification criteria for these objectives. Based on the certification criteria, the ONC has adopted standards that would allow for an objective determination of whether the criteria has been met.
An example will help: One of the meaningful use objectives is “the capability to exchange key clinical information among providers of care and patient authorized entities electronically.” To achieve this objective, “Certified EHRs” will have to meet the following criteria: “[The EHR system must] electronically receive a patient summary record, from other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, immunizations, and procedures and upon receipt of a patient summary record formatted in an alternative standard specified in Table 2A row 1, displaying it in human readable format.”
In order to guide EHR vendors (and purchasers) in fulfilling the above criteria–and likewise the larger meaningful use objective–the ONC has adopted a number of standards that EHRs must utilize in order to be certified. These standards fall into 4 general categories.
- Vocabulary Standards — The standardized nomenclatures and code sets used to describe clinical problems and procedures, medications and allergies.
- Content Exchange Standards – The standards used to share clinical information such as clinical summaries, prescriptions, and structured electronic documents.
- Transport Standards — The standards used to establish a common, predictable, secure communication protocol between systems.
- Privacy and Security Standards — Standards relating to authentication, access control, transmission security which relate to and span across all of the other types of standards.
My previous post provided a general overview of the first two standards, the first of which specifies the language of “EHR speak,” while the second specifies standards giving that EHR vocabulary a predictable organization so as to ensure that different EHR systems can interpret the data.
In the previous post I used the analogy of the Bluebook style of citation to explain the content exchange standard and vocabulary standard. As you can see, the following two citations share the same basic organization (e.g. case name in italics, followed by the reporter volume number, name of the reporter, starting page of case, etc).
Wilson v. Mar. Overseas Corp., 150 F.3d 1 (1st Cir. 1998)
Orange County Agric. Soc’y, Inc. v. Comm’r, 893 F.2d 529 (2d Cir. 1990).
The content exchange standard is analogous to the order of the different elements of the citation. Regardless of the case, all Bluebook citations to federal court of appeals cases have this same basic organization. The part that changes is the vocabulary. As you can see in the cases above, two different reporters (publishers) have been used: F.3d and F.2d. There are still only limited options for the vocabulary of court reporters. Likewise, even though the organization of a patient’s record will remain constant, it will obviously consist of different terms depending on, among other things, the patient’s diagnosis and test results. The possible terms within the chart are determined by the vocabulary standards.
Essentially, the signifier and syntax standards are meant to save us from constructing a costly high-tech Tower of Babel. A sign (word, letter, number, symbol) displayed in a particular way must have an agreed to and discernible meaning.
With these two standards in mind, a brief overview of the latter two standards is possible.
Transport Standards
Though the data is sitting on server A in a structured format–governed by the content exchange and vocabulary standards discussed above–there is more that needs to occur for the data to be useful. For example, Computer A must “know” how to send a request for that data in a way that Computer B can understand. Likewise, Computer B must “know” how to respond to Computer A’s request, i.e., how to structure the response it will give to Computer A. This is where the third category of “transport standards” becomes important.
Luckily for us, one of the transport standards (SOAP) adopted by the ONC is the same standard used by LexisNexis. This allows us to continue our analogy.
When I log onto LexisNexis, I have the opportunity to enter a citation. The citation must be entered in the same basic order that the Bluebook citation provides. Therefore, utilizing the first case cited above, I would type in:
150 F.3d 1
The name of the parties in the case is not necessary since only one case occurs at a given page (page 1) of a reporter’s (F.3d) volume (150). If I submit that citation and Lexis recognizes it, Lexis will then display the case. The beautiful thing about Lexis (and Westlaw) is that the case data, like the citations, has a specified organization–analogous to the organization specified by content exchange standards. One discrete element common to all Lexis cases is a field listing the parties’ counsel. Let’s say that I am an iPhone application developer and I want to create a simple application that would allow a user with a Lexis account to type in a citation like the one above, and in response the program would output the opposing counsel field (as opposed to the whole case). My application would need to know how to trigger Lexis’s server to go and find that information in the database. Likewise, the Lexis database must know how to package and send that data back to the client application. Thus, the fact that Lexis organizes data like citations and counsel into organized fields with specific vocabulary is not sufficient. Rather, there must be a standard governing the requests of specific information, as well as how that information should be formatted and transmitted. This is the role of the “transport standards.”
The ONC adopted two alternative standards–the SOAP standard and the REST standard–to govern requests and responses between client and server computers. As stated above, the SOAP standard is used by Lexis (and other Internet sites) to allow other applications and services to be able to interact with it. That Lexis uses the same standard as that adopted in the HIT interim final rule helps to illustrate the broad nature of transport standards. Unlike the content exchange and vocabulary standards that are unique to the practice of health care, the transport standards ensure that services wishing to interact with a server have an agreed upon framework by which to accomplish the interaction. As becomes obvious from this discussion, ensuring the proper implementation of the transport standards is critical to meeting the meaningful use objective described earlier that dealt with exchanging clinical information among providers. Additionally, having a specified standard for requesting and receiving the data is crucial for personal health record (PHR) services that seek to interface with the databases of health care providers in order to retrieve and display certain information to the consumer of the PHR.
Privacy and Security Standards
The fourth group of standards deals with privacy and security, and for the most part, this part of the IFR is straightforward. The reason for the straightforwardness is that the ONC has decided to model their privacy and security criteria off of HIPAA’s Privacy and Security Rules. Therefore, there are no real surprises. With that said, the HITECH Act does direct the various HIT committees as well as the ONC to look at capabilities beyond those specified in the HIPAA Security Rule. Thus, even though the IFR does not change the privacy and security landscape in any major way, there is no promise that things won’t change in the future.
Specifically, the ONC has adopted standards for certain aspects of HIPAA but not others. For example, standards have been adopted for the encryption of data, but not for “access control” measures that are used to prevent unauthorized access at computer terminals connected to EHR systems. The ONC’s rationale is that the methods of regulating access are evolving at a rapid pace, whereas there are industry best practices available for encrypting information. As a result, the ONC requires all certified EHR systems to be capable of encrypting their data. This is somewhat remarkable given that HIPAA and HITECH do not require all entities to use encryption. The ONC believes that this capability will spur the use of encryption by making it available to all consumers of certified EHR systems. Furthermore, the implementation of encryption by HIPAA covered entities is important because it acts as a safe harbor, relieving them of the responsibility of having to report a data breach.
As Table 2B shows, the ONC distinguishes between the general encryption of stored data on the one hand and the encryption of transmitted data on the other hand. Please click on the thumbnail below to enlarge the table.
Table 2B - Click to Enlarge
The ONC has stated numerous times that the IFR in no way changes the responsibilities of covered entities or business associates under HIPAA (and HITECH). Rather, it solely concerns the capabilities of certified EHR systems.
Electronic Medical Records: It’s Not too Late to Build the Tower on an Interoperable Platform
Tower of Babel by Sibeaster via Wikimedia Commons
Both the NY Times and the Boston Globe’s Health Blog, White Coat Notes , have recently run interesting articles on Electronic Medical Records (EMR). Both are based on articles published this last week in the New England Journal of Medicine. We’ve recently posted on the subject of EMR, and if you’d like some background information (as well as an introduction and a link to the pivotal work of Professors Sharona Hoffman and Andy Podgurski) you can find it here: Electronic Medical Records: How to Prevent the Creation of a Costly High-Tech Tower of Babel.
The first NEJM article, Use of Electronic Health Records in U.S. Hospitals, Ashish K. Jha, M.D., M.P.H., et al., was financed by the federal government and the Robert Wood Johnson Foundation and was based on a survey of nearly 3000 hospitals. The report, described by the Times as “the most definitive measure to date of the use of computerized patient records by hospitals,” shows that
…only 1.5% of U.S. hospitals have a comprehensive electronic-records system (i.e., present in all clinical units), and an additional 7.6% have a basic system (i.e., present in at least one clinical unit). Computerized provider-order entry for medications has been implemented in only 17% of hospitals. Larger hospitals, those located in urban areas, and teaching hospitals were more likely to have electronic-records systems.
A further breakdown of the components which constitute “comprehensive” and “basic” can be seen here.
Prior to this study, the numbers, based on what Steve Lohr of the NY Times described as “less rigorous studies,” were thought to be higher. The authors of Use of Electronic Health Records in U.S. Hospitals conclude that
The very low levels of adoption of electronic health records in U.S. hospitals suggest that policymakers face substantial obstacles to the achievement of health care performance goals that depend on health information technology. A policy strategy focused on financial support, interoperability, and training of technical support staff may be necessary to spur adoption of electronic-records systems in U.S. hospitals.
Perhaps the good news here is that the relative scarcity of EMR implementation thus far means that we can yet still devise an interoperable system without rendering substantial but incompatible investments obsolete. Which is to say that we are not yet too far down nine different non-intersecting roads and that “a communicative Tower” can still be built, and sustained, on a Platform.
No Small Change for the Health Information Economy
Interoperability brings us to Elizabeth Cooney’s thoughtful and succinct post in the Boston Globe regarding the other NEJM article, No Small Change for the Health Information Economy, Kenneth D. Mandl, M.D., M.P.H., and Isaac S. Kohane, M.D., Ph.D.
As do Professors Sharona Hoffman and Andy Podgurski, the authors of “No Small Change…” stress the need for flexibility, interoperability, liquidity of information, and the ability to substitute technologies as the need arises. To do this they propose governmental encouragement of the use of a platform with interoperable applications (blog builders, think: “plug ins” and “widgets”) In a recent post we noted that
In the words of Dr. Farzad Mostashari, an assistant commissioner in New York City’s health department and head of the much heralded Primary Care Information Project (which is functioning as a sort of I.T. Department for many of the City’s doctors using EMR), “There’s no way small practices can effectively implement electronic health records on their own. This is not the iPhone.”
Mandl and Kohane suggest that it should be. They make apt comparisons to the iPhone and ATM machines. Elizabeth Cooney’s article, “Health IT can learn from the iPhone and ATMs,” explains the comparisons quite well and is well worth the minute it will take to read– and if you have another three minutes, I highly recommend you take a quick look at Mandl and Kohanes’ brief but important article. There’s a link to it here, and there’s one in Elizabeth Cooney’s article also.
