Perspective on Interoperability

Document Sample
Perspective on Interoperability Powered By Docstoc
					A Perspective on Interoperability
W. Ed Hammond, Ph.D.
Introduction Leaders have long postulated that appropriate use of information technology (IT) in health and health care would have significant positive influence on creating a healthy society with a long, high-quality life. In that ideal world we would combine data, knowledge, and process to inspire self-responsibility for health combined with effective monitoring and mentoring by the professional community. In acute care situations the most effective and productive decisions concerning treatment would be made with the best possible outcomes. I believe this ideal world is attainable within a relatively short period of time and at an affordable cost. The vision for that ideal health information technology (HIT) application includes a structured electronic health record (EHR) that contains all data relevant to a person’s current and future health, aggregated and merged for all sites and sources. In turn, that EHR serves multiple needs: patient well-being and care, disease management, research, performance evaluation, outcome evaluation, cross-institutional care, specialists care and referrals, reimbursement, data analysis and data mining, regulatory considerations, education, resource allocation, health surveillance, and other purposes that arise. The EHR may coexist in different presentations with different focuses. The EHR will serve the needs of an institution, for public health, and for the individual. In this ideal situation the data collected are consistently based on circumstance, purpose, and disease. Data sets may be exchanged and fully understood, fully usable, and fully trustable from any source. EHRs are easily navigable to find any data. Data may be exchanged in either a push or pull method. Data exchange must become rule-based, again based on purpose and circumstance. It is likely that management of such systems will occur in regions: in some cases these regions may be nations, in other cases states or provinces, and in other cases geographically defined regions. Since patients, for many reasons, do not observe any geographical boundaries, the rules, processes, and standards must be global. To achieve this ideal world, additional security and privacy concerns must be satisfied in such a way as to protect individuals but meet health requirements of individuals, families, and society in general. Achieving this ideal world is what interoperability is all about. Interoperability Interoperability has become the focus of attention in the HIT community. Some suggest it is overrated; others think it is a mandatory requirement for success in HIT. I suggest the truth is somewhere in between. The National Alliance for Health Information Technology (NAHIT) defines interoperability as “…the ability of different information technology systems, software applications, and networks to communicate, to exchange data accurately, effectively and consistently, and to use the information that has been exchanged.” [1] This definition, although still open to interpretation, seems consistent with the scenario defined in the ideal world. True interoperability seems to be an unattainable task, so a normal approach is to try to attain interoperability in steps. The challenge and rewards are in choosing the right steps. NAHIT defined levels of interoperability in an attempt to define workable steps. Level 1: Non-electronic data. Examples include paper, mail, and phone call. Level 2: Machine-transportable data. Examples include fax, email, and unindexed documents. Level 3: Machine-organizable data (structured messages, unstructured content). Examples include indexed (labeled) documents, images, and objects. Level 4: Machine-interpretable data (structured messages, standardized content). Examples include the automated transfer from an external

1

lab of coded results into a provider’s EHR. Data can be transmitted (or accessed without transmission) by HIT systems without need for further semantic interpretation or translation. These definitions are useful as incremental steps toward interoperability but fall short of true

interoperability. A number of other factors must be considered. One important consideration is to make sure that each step toward interoperability provides immediate value. Interoperability requires consideration in a number of areas. Figure 1 below defines my current view of what is required for eHealth Systemic Interoperability.

Stakeholder Interoperability

Human/computer Interface Interoperability

Security/ Privacy Interoperability

Semantic Interoperability eHealth Systemic Interoperability

Business Interoperability

Functional Interoperability

Communications Interoperability

Technical Interoperability

Environmental Interoperability

Legal, ethical and societal Interoperability

Figure 1. Categories of Interoperability Required for eHealth Systemic Interoperability. Not all applications will necessarily require all of these components to be addressed to the same level of detail. However, the ideal world will require dealing with all of these components. There is also interaction among these different classes of interoperability. Details of Interoperability Semantic interoperability. Semantic interoperability is perhaps the first requirement for interoperability; without it, interoperability will not exist. Semantic interoperability means that the basic element of information exchange – the data element – is unambiguously understood in content, meaning, and purpose by the receiver. For semantic interoperability, the received data, with qualifying data such as date/time and source, stands alone. In the HIT setting, this data must be computable; that requirement is most likely satisfied with structured data, perhaps with some supporting narrative. A barrier to the exchange and use of data among disparate sources has always been the lack of a common set of data elements and a common terminology. The informatics community has primarily focused on terminology rather than the data element, which is a step in the right direction, but in itself will not provide the required level of interoperability. First, we focus on terminology. There are over 200 sets of controlled terminologies that have been created over the past 60 years. The National Library of Medicine attempted to provide some completeness to the terminology issue by creating the Unified Medical Language System (UMLS) in 1986. This set of databases includes over 150 different controlled terminologies and attempts to match overlapping terms among some of the major terminology sets. Unfortunately, the terminology models differ among the sets and mapping is, at best, incomplete and error-prone. No single controlled terminology is without error or is complete, even

2

in the primary domains addressed by the terminology. The issue is further complicated by subtle differences in vocabulary, terminology, nomenclature, taxonomy, classification, and now ontology. In frustration, most sites – large or small – use a local vocabulary and frequently that local vocabulary is not used consistently throughout the institution. At one time Duke University Medical Center used over 50 different terminologies. Mapping between terminologies is expensive and will contain errors. Further, the task is never finished, and synchronization among terminology sets is impossible. Even when mapping is the only choice, why require each group to do their own mapping rather than to provide a universal set? In the Veterans Administration IT system (VISTA), each site uses a local vocabulary, which means that semantic interoperability cannot occur. Further, Regional Healthcare Information Organizations that aggregate data over a number of sites rarely, if ever, are able to merge the data because of the lack of semantic interoperability. The existing numbers of used controlled vocabularies make a solution of a single terminology set impossible. There are, however, Terminology ICD-9-CM ICD-10 ICD-11 SNOMED CT SNOMED RT SNOMED III LOINC CPT DRG ICPC HCPSC

some predominate terminologies that are likely to be part of either an integrated solution or of a domain-specific solution. Figure 2 identifies a subset of these popular terminologies. An integrated solution is made even more complicated in that some terminologies are free, and others have significant licensing fees. Many different vocabularies support demographic terms, but frequently the permissible values, called the value set, are different and have different representation. For example, for gender, one set may use male, female, and unknown; another may use M, F, and U; another 0, 1, and 2; another 0, 1, and 9; and yet another Y, N, and U. The result is a lack of semantic interoperability. The issue of so-called “null flavors” and the lack of consistent use and meaning creates another problem. What is the meaning of unknown? Does it mean anatomically unknown? Does it mean unavailable? Does it mean not asked? There are issues of pre-coordination (combining terms to be part of the vocabulary set) or postcoordination (combining terms during use).

Terminology DSM-IV MeSH HL7 NDC RxNorm VA RDF WHO Drug Codes WHO Adverse Drug Reactions MedDRA ATC MEDICOMP

Terminology NANDA NIC NOC PCDS Omaha GHHCC ICNP AORN Perioperative ICCS Outcome Classification Genomic Ontology

Figure 2. List of some of the currently used controlled vocabularies. In the absence of some integrated approach, it is likely that, at least in the U.S., a combination of controlled vocabularies will be used: SNOMED CT, LOINC, RxNorm, ICD, CPT, and MedDRA. SNOMED CT has now reformed as the International Health Terminology Standards Development Organization (IHTSDO). Charter members include Australia, Canada, Denmark, Lithuania, the Netherlands, New Zealand, Sweden, United Kingdom, and the United States. There is a licensing fee associated with the use of SNOMED. In the U.S. a number of groups, including the U.S. government, have also committed to the use of LOINC for laboratory test names. Globally, ICD-10 is the most frequently used controlled vocabulary. In Global South countries it is particularly important to define and implement specific controlled terminologies for specific purposes. One of the first Returns on Investment (ROI) of these countries will be the ability to aggregate data for multiple purposes. From an aggregated database, countries will be able to understand prevalence and location of disease and be able to recognize pandemic outbreaks of disease. Such a database will also permit an evaluation of the effectiveness of various interventions to improve health of these countries.

3

As noted above, terminology is only one component for semantic interoperability. A literature review conducted for the 1994 unstable angina guidelines documented 67 different definitions in use for unstable angina [2]. When a single box is checked in a clinical trial data collection form, which of those 67 definitions applies? Semantic interoperability requires precise and unambiguous definitions for all data elements. The focus, then, should be on data elements with a set of attributes that includes a unique and persistent numeric identifier (without meaning), a name that may be mapped to any controlled terminology, a data type from a standardized set, standard units, and a complete value set. Data type must be taken from a standard set of data type specifications, and units selected from a standard set. Other attributes might include a categorization, semantic linkages, synonyms, and functional attributes. One set of attributes can be used to translate the name attribute into other languages, translating the clinical concept rather than just the name. By passing the code and using a selected language for output, patient data can be interoperable across language barriers.

each medical society will use a common process to create data elements of interest to that group, including all of the attributes. Each group will then bring that work forward to the CIC. If overlaps in terminology occur, resolution and harmonization will occur as a CIC activity. HL7 will, in turn, be responsible for defining the architectural structure for the master data element repository and will identify and develop the tools necessary for easy use. Several medical groups, including the American Heart Association and the American College of Cardiology, are participating in this process. Unfortunately, a number of groups have ongoing efforts in defining data elements. The set of attributes and structure are different, and terms are not semantically interchangeable. With a little effort, that work could be incorporated into a master metadata dictionary. An International Standards Organization (ISO) standard, ISO 11179, “Information Technology — Specification and standardization of data elements — Part 1 Framework” for the specification and standardization of data elements has been used loosely as the basis for much of this work. Figure 3 below identifies several of the groups involved in the creation of a set of data elements for their use.

A master set of data elements should be defined and maintained internationally. A site is not required to collect all data elements, but any data element it collects must be taken from the derived set. The process of creating the master set of data must involve the clinical community. Most of the gaps in controlled terminology sets are a consequence of not involving the clinical community. Health Level Seven (HL7) has created a Clinical Interoperability Council (CIC) in which the membership will be the medical societies and other appropriate participants. One of the first projects proposed is the creation of the master set of data elements. The idea is that National Cancer Institute ASTM E31 caBIG The Open Group UDEF CDISC CDC DEEDS US Health Information HITSP Foundations Knowledgebase HL7 X12N Detailed Clinical Models Tolven openEHR CTSA

InfoTerm NHLBI NIAID AHIMA (with HL7) AMA Others …

Figure 3. Organizations defining data elements.

4

Technical Interoperability. Technical interoperability includes syntax, structure and architecture. The technical component that ties all these components together is the Reference Information Model (RIM) that serves as a common model for classes and the relationship among classes to build a common structure. The RIM provides a common reference point for defining the binding of data elements to classes, data interchange, semantic structures, and EHR architecture. For the most part, XML is used as syntax in structures and in data interchange. Few data elements exist only in the atomic form; in most cases there is a structure varying from simple to complex that informs and aids in the capture of data. These structures are defined through a range of compound data elements, complex data elements, clinical statements, and documents. These data structures are called archetypes or templates and the equivalence of names is confused among different Standards Development Organizations (SDOs). The simplest structure is the compound data element, and blood pressure is one of the simplest examples. The structure includes systolic pressure, diastolic pressure, patient position during measurement, location of measurement, cuff size, and method used. Even this structure is insufficient for interoperability. In many reality cases, the provider will record only the systolic and diastolic pressures and leave the rest of the components blank. Is this acceptable? Does this mean that there are assumed default values for the rest of the components? Do we need templates for each of the combinations of the components? When does it matter? These are questions that must be answered by the clinical community and built into the structure as required and optional. On the other hand, optional is frequently the enemy of interoperability. A better approach is to use the word conditional rather than optional; that is, the conditions in which the component is required is defined as part of the compound data element. There are also administrative or demographic compound data elements such as a person’s name, address, email address, telephone numbers, etc. In HL7, these administrative compound structures are called Common Message Element Types (CMETS). The complex data element usually involves some logic and/or mathematical calculation. A simple example is body mass index; even then additional specifications are required. How long is a height measurement effective? Is the answer a function of age? These additional requirements

must be built into the definition of the complex data element. Complex data elements may also be used to define data collection structures. Examples include a workup for a screening visit for a patient suspected of having asthma or the return visit for a patient diagnosed as having asthma. Other examples might include a well-baby workup, a TB screen or an admission profile. The power of these structures is that they provide consistency and completeness to the data collected independent of source, site or event. A clinical statement fits somewhere into these structures. The clinical statement may simply be a phrase (data elements) that defines common concepts, such as the “right upper lobe of the lung.” Clinical statements are also similar in use to complex data elements, and may, in fact, be the same thing. All of these data structures have some characteristics in common with the data elements. They are assigned a number, have persistence, include name and definition, and are available in a global repository. Different types of media also come into play when defining structures. Waveforms have structure that depends on the type and purpose of the waveform. These structures frequently include both the actual waveform, measurements on the waveform, and interpretations. Images represent another structure as well, although these structures are independent standards. The Digital Imaging and Communications in Medicine (DICOM) standard is exclusively used globally for images. The structure for images includes not only the image but additional data and annotations defining how the image was created and some data about the patient. Another structure is the document standard. The most widely used document standard globally is the HL7 Clinical Document Architecture (CDA) Standard [3, 4]. The CDA is used for a variety of purposes including patient summaries, discharge summaries, infectious disease reporting, public health reporting, referrals, claim attachments, radiology reports, and other similar reports. The CDA includes a header, including a registered, unique document number, sender identification, receiver identification, document name, and date and time stamp. The body may be structured using a schema to define content. Level 2 supports content definition to the section level, and Level 3 permits definition down to the data element level. Archetypes or templates may be included within the body of the CDA. HL7 and

5

ASTM have created a harmonized standard called the Continuity of Care Document (CCD) [5], which incorporates the ASTM Continuity of Care Record (CCR) [6] into the CDA. The architecture of the EHR itself has made little progress toward standardization. There is ongoing work in the International Standards Organization Technical Committee 215 (ISO TC 215) that is beginning to address this issue. The European Committee for Standardization (CEN) 13606 standard does provide some approach to the architectural content of the EHR. However, there is still disagreement about the nature of the architecture. Some view an architectural structure in which the EHR is composed of documents such as the CDA or Folders based on encounters. I propose that the EHR architecture must permit direct access to the data element, including structured data elements. Interoperability requires independence of collection, storage and use or presentation. At this point, most vendors have a proprietary architecture for their EHR, and this situation is not likely to change in the near future. These proprietary architectures may not prevent data exchange if the vendor can extract and exchange the data preserving semantic interoperability. Navigation of the EHR is a difficult task in most existing systems. The architecture and the structure of the EHR must be such that any piece of data contained within the EHR can be found with 100% certainty. In a recent cardiology research project, the most frequently missing piece of data was ejection fraction, although it was usually contained somewhere in the record. The structure must be definable and data must exist in specified location. The architecture must support this need. The last area of discussion under this topic includes medical devices. Increasingly, there are direct connections between medical devices and the EHR. These linkages are important in intensive care settings as well as in home health and other settings. Many countries report lab results to patients using mobile phones. Medical device standards are important for patient safety. Interfaces for mobile phones and implanted sensors must be included and standardized. A number of countries, particularly Finland, are focusing on mobile technology to exchange data with its consumers. At the moment, adequate standards do not exist for these medical devices. Work on these standards is being done jointly by IEEE, HL7, CEN, and ISO. It is important to track technology and to recognize new technologies and new approaches

to the use of technology. One such trend is Service Oriented Architecture (SOA) which defines a component approach to defining standards and developing systems. HL7, for example, is rapidly moving in this direction. Human/Computer Interoperability. A challenge that has yet to be overcome is solving the human/computer interface. For the most part, these interfaces that have been done by engineers and computer scientists are still lacking in ease of use, simplicity of use, and speed. Part of the challenge is that no one is able to define the ideal system – all users know is that they don’t like what they are forced to use. Point and click, while popular, is somewhat restrictive and requires good hand/eye coordination. Paged systems seem to be preferred over scroll bars. Clearly, response time influences this choice. Some progress has been made with voice recognition, but it still seems to be an experiment in progress. Training of users is another challenge related to this topic. The idea’ system is one that selfeducates and requires little training for use. Turnover of users is quite high and training must be continually ongoing. Typically today, most institutions have more than one system, so there is confusion to the users caused by variations in the computer/human interface. In a recent survey, users rated high the desire to have the screens of all systems look the same. Perhaps one step in this direction would be some standardization of screen design, icons and presentation. Unsolved questions included how much data can be effectively displayed on the screen versus using multiple screens. The grouping of data for data collection still creates data entry problems. For example, in systems that use clinical guidelines, data collection for each guideline is different and sometimes redundant. Data collection presented to the user should be a logical integration of data elements. Presentation of data is part of the requirement for human/computer interoperability. Only the data of interest and importance should be presented, and the presentation should be prioritized. Presentations should be event driven. Communications Interoperability. Most required communication standards for the interchange of data have been developed with limited input from the health informatics community. Existing standards are adequate for what is currently required. The World Wide Web Consortium (W3C) and the Internet Engineering

6

Task Force (ITEF) have been responsible for most of these standards, along with the IEEE and the Object Management Group (OMG). These standards do influence applications. Applications in health care do need to track trends and changes including the advance of social networking and Web 2.0 and Web 3.0 activities. These interests will definitely influence functionality for personal health record systems. Functional Interoperability. Functional interoperability is the ability to exchange patient related data and includes the ability to identify, without error, the person whose data is being exchanged. It also includes the ability to understand what data is to be exchanged and to extract that data for the patient’s database or Electronic Health Record (EHR) on the sending side, and the ability to receive that data and integrate it appropriately into the receiver’s database or application for which it is intended. Functional interoperability also includes the ability to carry out certain common functions required to support common applications. These functions include the functioning of an EHR System, decision support, queries, report generation and other such applications. Data Transport Standards. Data transport means moving data from point A to point B. In itself, it only requires a common, known communication protocol and a shared syntax for sending and receiving data. Exchanging data between a sender and receiver was one of the first applications in the use of IT for health care. Examples include reporting laboratory results, reporting the admission or discharge of a patient, sending a claim for payment, and sending a prescription to a pharmacy. The requirement of interoperability, however, goes far beyond those simple requirements. Unfortunately, even after 40 years of performing these tasks, we still have problems obtaining interoperability. The problems that prevent success for interoperability lie in both methodology and in the fact that several disparate groups must come together to solve the full spectrum of problems. Functional interoperability usually begins with messaging. The questions are “what data is transmitted when.” Most of the scenarios we use to define what must be done in data exchange are often more hypothetical than real. While transmitting complete, lifelong EHRs when a person moves to a new location has value and happens to about 10% of the population annually, it may not be an adequate business case to justify the expense of creating an infrastructure framework to justify the time and expense. A greater challenge is providing the needed

component data at the right time and place. Examples include a patient referred to another facility for a particular treatment or a patient seen in an emergency room for a specific acute problem. Functional interoperability requires defining these trigger events, defining the data to be exchanged, and dealing with corrections, additions and updates over the time of interest. Although exchanging all kinds of data could be easily accomplished with one kind of standard, several domain-specific standards exist for the exchange of data. The most widely implemented general clinical data messaging standard is the HL7 v2.x series of data transport standard. This standard, first defined in 1987 and having evolved to the current version 2.6 is used in over 95% of the hospitals in the U.S. as well as other countries. Version 2.x standards are based on messages with content based on specific trigger events. The format is a message consisting of segments which in turn consist of data fields made of components which are made of elements. Fields are separated by delimiters. The model for v2.x is implicit and was defined by experienced individuals who knew what data they needed to exchange and when. Version 2.x is used when both the sender and receiver are known, and conformance agreements can be put into place. If the receiver is not known, v2.x cannot provide interoperability. Version 2.x standards have the advantage of being easy to understand and implement. The disadvantage is in the high degree of optionality and, consequently, ambiguity. Later versions of v2.x use XML syntax to take advantage of XML tools. To solve the problems of interoperability for v2.x, HL7 began a new approach for an interoperable Version 3 standard based on the Reference Information Model. Version 3.0 is based on a core structured content that includes a prescribed set of data types, data elements, vocabulary, templates and clinical statements. This approach provides an interoperable conceptual foundation that is semantically interoperable and uses an abstract design methodology. This version uses XML syntax where the tags reflect the data model. The Clinical Data Architecture HL7 standard is also based on the RIM and can itself be used for the transport of data. ASTM’s CCR standard can also be used for clinical data transport as can the CCD discussed previously. The DICOM standard is used for transporting images of any form; the National Council for Prescription Drug Programs has created a suite of medication standards

7

including the SCRIPT standard for prescription data; ASC X12(N) has created Electronic Data Interchange standards for reimbursement; IEEE has standards for medical devices and home care sensors; and OASIS standards for the exchange of business information. Integrating the Healthcare Environment (IHE), a collaborative effort with the Radiological Society of North America and the Healthcare Information and Management Systems Society, working with various clinical groups, provides profiles for endto-end requirements from the above sets of standards. A typical application will require expertise in all of these standards. The required expertise is further extended when one includes ISO and CEN standards. Decision Support Standards. The requirements for decision support applications and knowledge management, as part of an EHR system, have long been postulated. The lack of semantic interoperability has prevented wide spread application of clinical decision support systems (CDSS). HL7 has a technical committee that has created standards for knowledge representation, logic structures for decision rules, clinical guidelines and disease management protocols. Specific standards include the Arden Syntax, GELLO, Guideline Interchange Format (GLIF), and the Infobutton. ASTM has a guideline standard, Guidelines Elements Model (GEM). HL7 also has ongoing work based on a virtual EHR that drives decision support algorithms. As part of the CIC activities, HL7 will assist in the development and implementation of clinical guidelines and decision support algorithms. The Infobutton standard should have value to the provider community. EHR Functional Standards. In spite of its importance, there is no consistent, agreed upon definition of the Electronic Health Record, or what are its different flavors such as an Electronic Medical Record, a Population Health Record, a Summary Health Record, and a Personal Health Record. Part of that definition, however, is what functions or capabilities must exist in an EHR system for it to meet a minimum set of requirements. HL7 has created a standard, the Electronic Health Record – Functional Model that became a normative standard in February 2007. This standard defines functionalities in three categories: direct care (care management, clinical decision support, and operations communications, and management); supportive (clinical support, measurement analysis, research and reports, and administrative and financial); and information infrastructure (security, health record information and management, unique identity, registry and directory services, health

informatics and terminology standards, interoperability standards, business rules management, and workflow management). The HL7 EHR-FM standard has been used by the Certification Commission for Health Information Technology (CCHIT) to define requirements for certification of EHR vendors. The creation and use of a Personal Health Record has received a lot of interest internationally. HL7 recently balloted a standard for Functional Requirements for the Personal Health Record. Other standards required for functional interoperability include functional standards for regional health care information organizations (RHIOs and HIEs) and National Healthcare Information Networks. Other standards include developing functional profiles for different sites, EHR content standards, and structure and architectural standards. A related set of standards includes identification standards for persons, providers, facilities, and employers. Actually, interoperability would be considerably easier if all objects, actors and attributes were assigned a unique and universal identification number. The pilot testing of ePrescribing in the U.S. in 2005 found that medication records from different sources could not be combined for an individual person with acceptable accuracy in the absence of a unique Personal Identification Number. Business Interoperability. Health care occurs in many different settings. Data requirements differ, priorities are different, and other influences such as culture and environment affect what is done. In many cases, controlled interoperability can be accomplished through agreements with all trading partners. So what do these different sites have in common and what is different? Obviously a nursing home will have different date requirements than an intensive care setting. The key to interoperability is to make sure all pertinent classes of interoperability are satisfied. Any data element used at any site must come from the common metadata registry. Every site should keep a registry that identifies what data elements are collected by that site. Business agreements should be in place with each business partner that defines the circumstances and the data elements that will be exchanged between sites and under what circumstances. For example, a nursing home should create a profile that would define what data elements should accompany the transfer of a patient from that hospital to the nursing home and a second profile that would define what data elements would accompany a

8

patient being transferred from the nursing home to the hospital. Reimbursement claim requirements could be driven by profiles that depend on problems and events. Research protocols and clinical trials would be a specification of what data elements were exchanged based on what triggers events. Some of these profiles are currently being defined by Integrating the Healthcare Enterprise (IHE). It is likely that any site will have many of these business profiles. Security and Privacy Interoperability. Perhaps the greatest pitfall in trying to achieve systemic interoperability is the failure to properly deal with security and privacy. How a system will deal with security and privacy must be very visible and must be one of the first things shared with the consumers. Major systems have been brought down by the failure to do this in an obvious and timely manner. In some cases, systems have over responded to privacy issues and actually have designed systems that are unsafe. In other cases, privacy has not been dealt with adequately. The general rule for privacy and security is that first, the patient must not be damaged by the use or release of data. Of equal importance, however, is that effective and appropriate treatment for the patient must not be withheld because of privacy concerns. In many cases, timely and appropriate treatment requires dealing with identified data. Further, there is a societal responsibility to share personal data for such purposes as identifying pandemic outbreaks, adverse drug events, bioterrorists attacks, and new vectors for disease. When possible, data should always be shared as de-identified data. In many cases, the identity of the patient can be restricted to the computer and not humans through the use of anonymous identifiers. As data is shared among many sites, it is important to ensure that a patient’s privacy requirements are maintained. A number of effective security standards are available, but the informatics community has been slow to identify which of these standards we will use. Effective standards exist for digital signatures, and these should be accepted globally and used immediately. Adequate authentication processes exist, but, in the United States, these certificates are expensive (because of the large numbers) and must be renewed annually. Authentication processes should be at the national level and should be done without cost to an individual.

Legal, Ethical, and Societal Interoperability. For the most part, little attention has been paid to issues of legal, ethical and societal interoperability. Included under societal interoperability are cultural issues. Cultural issues are particularly important, particularly in the Global South. These issues need to be understood and accommodated consistent with excellent and desired outcomes. Legal issues need to be defined and accommodated in such a way that the effectiveness and usability of systems are not compromised. What are key characteristics of the population? What is the model for the health delivery system? How are decisions related to health care made? Stakeholder Interoperability. For much of the history of informatics and the use of IT in health care, the stake holders have been largely the industry (vendors), the providers of care, and a general community that includes consultants, a few academicians and a few representing the government. To achieve eHealth Systemic Interoperability, a much broader set of stakeholders must be educated, made interested and engaged. These stakeholders include almost all aspects of today’s society, including consumers, payers, regulators, governments, device manufacturers, the clinical community in contrast to clinical IT people, quality assessment people, media, consumer groups such as the AARP, and many others. For example, the manufacturers of the equipment that perform laboratory tests need to be involved. Their products are the starting point of an end-to-end interoperability challenge that involve, the device manufacturers, the commercial laboratories, the vendors of IT systems, the users of those systems, the clinical community, the payers, and others. Environmental Interoperability. Understanding the environment is very important to success in the use of IT in health care, particularly in the Global South. Access to the internet might be a prime consideration in the development of systems and the access to systems. What is the availability of electrical power in the universal setting? How is the internet available? Is it available only from satellites? What percentage of the population has access to the internet? Are land lines available? What role will mobile telephones play in the implementations strategy? What is the population density? What are the availability of hospitals? Are these general hospitals or specialist hospitals? What are the age distributions? What percent of the population is over age 65? What is needed and how it is delivered comes from the answer to these questions.

9

Interoperability for the Global South Interoperability should be treated as a direction for the Global South rather than as the end point. There are clearly immediate incentives for taking steps toward that goal. Already there are examples of countries that have implemented IT systems, but, due to lack of semantic interoperability, cannot aggregate the data to produce key national statistics. These statistics will be important in understanding where to focus resources. From a clinical perspective, patient data will be useful in understanding disease, the spread of disease, and in educating the population. Knowing what disease exists in what regions will be important in dealing with cause. In most cases, time is extremely important in recognizing pandemic outbreaks and bringing them immediately under control. Involving stakeholders, particularly political leadership, will be important in setting national goals and objectives. Much of these comments relate to “If you can’t measure it, you can’t change it.” There are currently several IT activities that involve countries that are part of the Global South. While many of these systems are effective, they come far short in making a significant impact on the health of these countries. Planning effective IT systems and understanding the requirements for interoperability in these countries will be a real challenge. The concept of appropriate technology should be a major focus. Whatever is done must have immediate value and must make an immediate impact. The first step seems obvious. A common set of data elements with an associated terminology should be adopted by each country. Ideally, the same set would be shared among all nations. Even if the focus is only on adopting a defined set from existing controlled vocabularies, countries can realize value in the effort. This is probably the highest value-add in the interoperability space. Having a common terminology set is essential for the earliest received value. It is likely that a data interchange standard such as HL7 v2 messages will be adequate and simple to implement. In fact, it makes more sense to use an existing standard rather than to create flat files with simple delimiters to exchange data. The HL7 messaging standards have already addressed many problems and have workable and proven solutions. The HL7 standard is expandable, and it will be easy to add data element without additional programming. In addressing this issue, appropriate use cases must be defined and discussed. These use

cases should include what will be the evaluations to prove the value of such systems. The question is what shared data will have an impact on the health of individuals in these countries of interest. Suggestions would include creating and aggregating data for a country that would assist in understanding the health status of a country and the level of the ability of the country to deal with those problems. The balance between the reality of what can be done and the perceived needs is important. For example, it is likely that making laboratory results available at the point and time of care might have an immediate impact on the health of the population. Education of the people may be more important than imaging equipment. Simple will always, in any environment, be better than complex. What will be the impact of ePrescribing in a population that may not have access to drugs needed for treatment? In any case, the focus must be on the receivers and users of the IT systems rather than the developers of such systems. In some cases, the adoption of clinical guidelines and decision support will be important. These guidelines might be incorporated into educational components to help local providers be better prepared for disease management and patient care. HL7 standards can be made available for little cost. The standards we propose are simple to use and easy to implement. It is important to identify and provide the stability to adopt standards and put them into immediate use. There needs to be an infrastructure in place that can make the decision that standards will be used and to identify those standards. There exists already a number of groups who are committed to advising Global South countries on implementation of eHealth Standards. These organizations include ISO, WHO, IMIA, AMIA, and others. HL7 would be willing to bring these countries in as HL7 affiliates and assign a twining affiliate to work with them in implementing standards. The primary barrier to progress is the inability to identify the appropriate individuals to provide leadership and stability to the efforts. It is likely that these efforts would be affordable. The systems need not be so sophisticated and could provide immediate value. There are examples of some countries, not necessarily Global South, that have involved a single individual to advise them in the implementation of standards. Many of these countries, such as Vietnam, Thailand and Uganda have already shown an interest and have individuals and groups working with them. The problem is

10

sustainability. I think it is essential to have government backing, even with a small expenditure of funds, to make these projects work. I think many vendors would be willing to work to create systems for Global South countries. As a first step, I would engage the EHR Vendors Association (U.S.) and other similar organizations in discussions in what could be done for some of these countries as pilot projects. The President’s Commission on Systemic Interoperability [7] suggests a practical approach to systemic interoperability. In this case, the focus is on creating a medication record. That focus may be inappropriate in the case of Global South. However, what can be accomplished calls for imagination and innovation. For example, the cost of memory sticks with adequate memory is minimal. Simple personal health records could be stored on these devices, water-proofed and made into a wearable object. The National Library of Medicine gives its students at the Woods Hole Medical Informatics course a one

gigabyte memory stick that is wearable as a bracelet. There are now very capable computers available for less than $200. Summary and Conclusions Most of the standards necessary to make valued progress toward systemic interoperability currently exist. Part of the problem is that there are duplicating and overlapping standards, and which standards will be used must be identified. There are some gaps in the required standards, but SDOs are working to identify those gaps, and most of those additional standards will be developed in time. There are still some questions in the extent of standardization versus proprietary design. The systems that are implemented in the Global South need only be adequate for appropriate applications. It is important that all necessary stakeholders be identified early on and engaged in the implementations. What is needed is innovative leadership in making these visions happen.

11

References

1.

The National Alliance for Health Information Technology. “What is Interoperability?” 2006. Available at http://www.nahit.org/cms/index.php?option=com_content&task=view&id=186&Itemid=195. Accessed October 31, 2007. Braunwald E, Mark DB, Jones RH, et al. “Unstable Angina: Diagnosis and Management. Clinical Practice Guideline Number 10.” AHCPR Publication No. 94-0602. Rockville, MD, Agency for Health Care Policy and Research and National Heart, Lung, and Blood Institute, Public Health Service, U.S. Department of Health and Human Services. March 1994. Health Level Seven, Inc. HL7 Clinical Data Architecture, Release 2. Available at http://www.hl7.org. Accessed June 25, 2008. Dolin RH et al. The HL7 Clinical Document Architecture. J Am Med Inform Assoc 2001:8:552-569. Health Level Seven, Inc. HL7 Continuity of Care Document, Release 1. Available at http://www.hl7.org. Accessed June 25, 2008. ASTM International. ASTM E 2369 Standard Specification for Continuity of Care Record (CCR). 2005. Referenced ASTM Standards, available www.astm.org. Commission on Systemic Interoperability. “Ending the Document Game: Connecting Your Healthcare through Information Technology.” U.S. Government Printing Office, Washington, DC, 2005. Available at http://www.EndingTheDocumentGame.gov. Accessed June 25, 2008.

2.

3. 4. 5. 6. 7.

12


				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:586
posted:6/3/2009
language:English
pages:12