This kind of spending, if done wrong, can have the negative market consequence of interfering with rapid innovation by locking in today’s processes and technologies, which although well-intended, came about without a systemic view. And we risk locking out the very innovations we need for meaningful health information sharing to support better decisions.
The goal for health IT should not be primarily the creation of standards or the certification of software. Rather, standards and certification should support measurable health improvements. Health improvements are not achieved by the mere installation of software; they are achieved through the effective use of information for better decision-making.
At the same time, individual states -- for example Massachusetts, which has a newly passed law that requires hospitals and community health centers in the state to implement an electronic health record systems by Oct. 1, 2015 -- have also been moving to improve the delivery of better health care through the use of EHR.To implement these programs, the healthcare industry seems poised to increase the adoption of EHR and electronic transmission standards to promote accuracy, transparency, and processing speed across disparate information systems. Today, they have a smorgasbord of health information technologies available to help them build a far better health system.
There are, in fact, too many standards and too many organizations writing them. There are the standards that support the systems we have in place today as well as the XML/Web-based standards that support newer web-centric systems and healthcare information exchanges.
While creating EHR data is an important first goal, an EHR is much more valuable if it can be summarized, moved, and shared. This and future posts will address EHR in that broader context. These discussions will address many technical, clinical, economic, political and managerial issues of electronic health record systems.
Perhaps the most difficult challenge is to bind the standards to structured vocabularies to ensure that there is the transfer of unambiguous knowledge of the meaning of the data among cooperating systems.
Before I get specific (sometimes talking about tools to facilitate implementation of these systems), I want to point out that building technology on U.S. standards alone would leave us with essentially a non-standard EHR platform. Remember that other countries, for example Canada and England, have single-payer health systems, while the U.S. does not.
A look back to before the PC, the Internet and all that
And, before looking ahead to how Electronic Health Records of the future will likely work, I thought I'd also display a pulmonary function test report produced at Yale New Haven Hospital (YNHH) several decades ago. While its underlying data (held in a PDP-8 computer) could be transmitted electronically -- analog modem to analog modem -- over a 128 bits/sec telephone line connection, these paper reports were generally sent from the laboratory where they were generated to the office of a YNHH physician via inter-office mail or to an outside physician via the U.S. Postal Service.
Computer-generated paper report: This photograph was produced by a Poloroid instant camera that was suspended over the front of a cathode ray tube (CRT). The CRT, along with a teletypewriter, provided human readable output for the PDP-8.
In subsequent posts, I'll include talk about safe wireless practices, Web services and other seemingly off-topic subjects, because they too are important parts of the EHR story.
Interoperability will be among these topics. The linking of vital information as patients receive care from a fragmented healthcare system is a problem that has consistently plagued interoperability efforts in healthcare. The privacy, technical, and policy issues involved need be addressed in order to effectively share information across multiple organizations. Making the information available will help to prevent drug interactions and adverse events, avoid medical errors, and help inform decision making for the patient and clinician. It will also enable the support of public health efforts, improvements in research, better physician and organizational performance and benchmarking, and greater empowerment of patients and families as active participants in their own healthcare, among other benefits.
In discussing these issues, I will sometimes cite my earlier writing on financial, legal and organizational issues that appears in articles available through links provided in my bibliography at the bottom of this page.
Finally, this might be a good time to introduce a few technical terms: HL7, HL7 mapping, HIPPA etc. They're central to the discussion of IT health records management.
Health Level 7 (HL7)
HL7 refers to both a standards organization and the set of healthcare messaging standards that it creates. Founded in 1987 to create a set of standards for hospital information systems (HIS), HL7 has expanded its reach to the creation of international standards that transgress hospitals to address clinical and administrative data in healthcare domains such as pharmaceutical, medical device, and insurance transactions. There are already a large number of countries that have mandated the use of HL7 for the transmission of healthcare data and there is an expectation that HL7 will become a part of the United State's Health Insurance Portability and Accountability Act (HIPAA) in the future.
For the large number of international healthcare organizations that are embracing the electronic transmission of healthcare data, there remain some formidable challenges. Though some compliance regulations specify the newer, XML-based HL7 v3.x, there are many jurisdictions that still need to update their legacy systems to handle this format, and many that even have multiple disparate data formats in the same system.
In the US, for example, many legacy HISs employ HL7 EDI messages alongside HIPAA X12N messages. Though these formats have quite a lot in common, syntactically speaking, they are by no means interoperable and must be mapped on-the-fly to create a dynamic workflow for managing healthcare transactions. Of course, the introduction of the XML-based HL7 v3.x adds EDI/XML mapping to the complication of mapping data from EDI to EDI.
HL7 mapping
There are off-the-shelf, any-to-any graphical data mapping tool (e.g., Altova MapForce) that supports mapping HL7 data, in its legacy EDI or newer XML-based format, to and from XML, databases, flat files, other EDI formats, and Web services. Mappings are implemented by simply importing the necessary data structures (MapForce ships with configuration files for the latest EDI standards and offers the full set of past and present HL7 standards as a free download on its Web site) and dragging lines to connect nodes. A built-in function library lets you add advanced data filters and functions to further manipulate the output data. MapForce can also facilitate the automation of your HL7 transaction workflow through code generation in Java, C#, or C++ and an accessible command line interface. Additional support for mapping HL7 data to and from Web services gives healthcare organizations the ability to meet new technology challenges and changing enterprise infrastructures as they unfold within internal and external provider domains.
