Developing Interoperable Electronic Health Record Service in China

Developing Interoperable Electronic Health Record Service in China 1 Jun Liang, *2 MeiFang Xu, *3 LiZhong Zhang, 4 LanJuan Li, 5 XiaoLin Zheng, 6 DeRen Chen, 7 ShengLi Yang, 8 BaoLuo Li, 9 Ou Jin, 10 Zhou Ji, 11 JunXiang Sun 1, First Author,10 Second Affiliated Hospital, College of Medicine, Zhejiang University, Hangzhou, China. Email: panpanspan4@live.cn *2, Co-corresponding Author Institute of Medical-care Information Technology, Hangzhou, China. Email: imit_xumf@126.com *3, Co-corresponding Author Hangzhou Normal University, Hangzhou, China. Email: zlz@ewell.cc 4,7 Chinese Academy of Engineering, Beijing, China 5,6 College of Computer Science and Technology, Zhejiang University, Hangzhou, China 8 Ministry of Health - EHR Steering Committee, Beijing, China 9 Hangzhou State Software Industry Base Co., Ltd., Hangzhou, China 11 Sir Run Run Shaw Hospital, College of Medicine, Zhejiang University, Hangzhou, China doi:10.4156/jdcta.vol5. issue4.34 Abstract The effective use of electronic health records (EHRs) can improve the quality of health care services and reduce associated costs. Establishing interoperable EHR systems has been recognized as an important objective in many countries and regions. Here we propose a framework based on three guidelines-the HL7 v3 CDA R2, Basic Medical Data Sets of China (BDS), and SI-LOINC-as a solution for establishing EHR interoperability according to the particular conditions of China s health care system. We also describe in detail the realization of interoperability at each level within this framework. Keywords: ehealth, Interoperable Service Framework, Clinical Document Architecture, Health Level Seven, Basic Medical Data Sets of China, Controlled Medical Vocabulary, Electronic Health Record 1. Introduction An electronic health record (EHR) is a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. This information may include patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports [1]. The effective use of EHRs can potentially help improve the quality of health care services and reduce associated costs [2]. In a person s lifetime, he or she may acquire different EHRs from multiple federated clinical affinity domains. Therefore, the interoperability of EHRs has been recognized as an important objective in various countries and regions. Some examples of such systems are the Canada Health Infoway [3], Federal Health Information Technology in the United States [4], NHS Connecting for Health in England [5], Dossier Médical Personnel in France [6], Health Connect in Australia [7] and ASAMEKj in the Czech Republic [8]. In Asia, the Turkish Ministry of Health has initiated the development of Turkey s National Health Information System (NHIS-T), which aims to cover 59.8% of its citizens by 2011. Moreover, 99% of public hospitals and 77% of private or university hospitals in Turkey have been required to connect to the system [9]. In Taiwan, the National Health Information System based on the Taiwan Electronic Medical Record Template (TMT), which has been under development since 2004, also aims to involve all hospitals in Taiwan [10]. In mainland China, the Ministry of Health has identified the development of an interoperable EHR system as a key driving force in the reform of the national health care system [11]. The IEEE defines interoperability as the ability of two or more systems or components to exchange information and to use the information that has been exchanged [12]. Specifically, interoperability is - 280 -

said to exist between two applications when one application can accept data (including data in the form of a service request) from the other and perform the task in an appropriate and satisfactory manner (as judged by the user of the receiving system) without the need for additional operator intervention [13]. Interoperability in an EHR system makes it possible to integrate a patient s health information from different sources. In China, public hospitals currently encompass 96% of the health care resources in the country [11], and hospital information systems (HISs) are correspondingly the largest source of patient health information. Under a mandate from the Chinese Ministry of Health, the Chinese Hospital Information Management Association surveyed the utilization of HISs in Chinese hospitals. In 2008, the survey showed that 38% of public hospitals in China were using HISs. Moreover, 80% of specialty tertiary hospitals, general hospitals and university-affiliated hospitals have been using HISs, and this rate reaches 95% in the southeastern coastal areas. The survey also found that 98% of the HISs in operation was based on relational databases and the client/server architecture. Meanwhile, only 2% of the hospitals were using or planning to use data exchange middleware, and no hospital was using a Health Level Seven (HL7) message interface engine, according to the survey. In China, there are currently more than 300 manufacturers and suppliers of HISs; 15% of them are large organizations, 60% are mid-sized, and 25% are small. It has been indicated that the number of HIS suppliers generally reflects the level and scale of hospital digitization in a country [14]. Meanwhile, the available HISs in China are characterized by a cost-focused style, which is primarily concerned with the costs generated from start to end of a course of patient health care. The cost-focused health information that is gathered can thus be a potentially incomplete depiction of the health care process. To further advance the reform of China s national health care system, in June 2008 the Ministry of Health partnered with GE and Intel to establish the Ministry of Health - EHR Steering Committee (EHRSC), which is responsible for designing and validating standards, policies, and guidelines related to the national electronic health information systems, as well as verifying that software vendors applications comply with standards. A report by the EHRSC showed that globally, ehealth systems primarily use two approaches of representing EHR content in a digital format. The first approach is to adopt international standards followed by further local adaptation (restriction or extension); some international examples of this are HL7, the Clinical Document Architecture (CDA) [15], the European Committee for Standardization (CEN) EN 13606-1 (CEN EN 13606) [16], and openehr [17]. Countries that have utilized this approach include Canada, South Korea, Turkey, and the United States. The other approach is to develop new local specifications, as was done with the Kind Messages for the Electronic Healthcare Records, or KMEHR, in Belgium [18]. Although in principle both approaches can achieve interoperability, the EHRSC, with its aim for wider international communication, decided to adopt the HL7 v3 CDA R2 as the basic specification and adapt it according to the particular business rules of China s national health care system. Correspondingly, the EHRSC developed an Electronic Health Record Templates Guideline (EHRTG) to meet the specific requirements and health care conditions of the country. With these templates in place, an HIS can construct appropriate EHRs for individual patients. Four aspects were identified by the EHRSC as priorities to address in developing the EHRTG and imparting it semantic interoperability. 1. Although EHR datasets and EHR content templates have been proposed, a theoretical interoperability framework remained to be developed, based on the HL7 v3 CDA R2 and Basic Medical Data Sets of China (BDS). This framework must be suitable according to the characteristics of China s national health care system and would thus guide the realization of interoperability at various levels. 2. At the syntactic level, although basic EHR content templates [19] have been developed, an HL7 v3 CDA R2-based template guideline as well as related full-scale examples were lacking. There have been some systems put into operation based on the HL7 v3 CDA R2, and some small-scale operational tests carried out in certain hospital departments [20-22]. However, these utilized HL7 v3 CDA R2 methods of data storage and data display, without incorporating the full systemic theory of the HL7 v3 CDA R2, the objective of recording subtle aspects of clinical data, and the incorporation of clinical data terminology supplements (e.g., BDS, SI-LOINC). 3. At the semantic level, there is strong interdependence between the controlled medical vocabulary (CMV) and the medical data exchange standard. The medical data exchange standard forms an - 281 -

essential framework, enabling a logical interpretation of the coded terms [23]. In China, a mapping between internationally standard CMVs and local code sets remained unavailable [14]. 4. There was a lack of a scheme to verify whether the generated medical documents conform to the developed templates. Here, we propose a framework to establish EHR interoperability for hospitals in China according to their current status of health care digitization. We will demonstrate the applicability of this model based on results from trial operations. 2. Enabling technologies and standards In this section, the standards and technologies used in this project are briefly summarized. 2.1. HL7 v3 CDA R2 CDA is a document markup standard that specifies the structure and semantics of a clinical document (such as a hospital discharge summary or progress note) for the purpose of exchange with other systems [24]. HL7 has released two CDA versions. CDA Release One (CDA R1), became an American National Standards Institute [25] (ANSI)-approved HL7 Standard in November 2000, representing the first specification derived from the HL7 Reference Information Model (RIM) [26]. CDA Release Two (CDA R2) became an ANSI-approved HL7 Standard in 2005 [19]. A CDA document is encoded in the Extensible Markup Language (XML). It has a root element (<ClinicalDocument>) and contains two parts, the Header and the Body. In CDA R1, only the Header derives from the RIM [27]. In CDA R2, however, both the Header and Body, which contain clinical statements, are derived from the RIM. The Refined Message Information Model (R-MIM) of the CDA R2 is presented in [24]. A CDA Header identifies and classifies the CDA document and provides information for authentication and on the encounter, the patient, and the involved health care providers. The CDA Body contains the clinical report, and can be either an unstructured blob (for CDA Level One) or comprised of one or multiple section components (for CDA Level Two). A section contains a narrative block and one or more entries (for CDA Level Three). Narrative blocks are human-readable, and entries present the same information in machine-processable form. 2.2. Basic Medical Data Sets of China (BDS) To ensure the interoperability and reusability of EHR components, China s Ministry of Health published the BDS [28], which defines all 34 data types and 1163 data elements for EHRs (e.g., ID, name, age, sex) and, based on these definitions, reusable data groups (e.g., prescription, laboratory examination results, medical examination results and demographic information). These datasets and elements are included in the National Health Metadata Dictionary of China [29]. The data elements are then mapped to corresponding CDA components and serialized into the XML format based on the HL7 v3 CDA R2 structure. Importantly, all local components were developed according to the particular context of China s health care system and are thus context-dependent. 2.3. Controlled Medical Vocabulary (CMV) A CMV must have synonymy, domain completeness and multiple classifications, providing consistent views and explicit relationships, while remaining unambiguous and non-redundant [30]. The CMV is crucial for ensuring that practitioners using the EHR have access to accurate and consistent data. Commonly used CMVs include: Logical Observation Identifier Names and Codes (LOINC) [23]; the International Classification of Diseases, Ninth Revision with Clinical - 282 -

Manifestations (ICD-9-CM) [31]; the International Classification of Diseases, Tenth Revision [32]; and the Systematized Nomenclature of Medicine (SNOMED). For example, LOINC is provided as a standard set of universal names and codes for identifying individual laboratory tests and for facilitation of transmission and storing of clinical laboratory results among different laboratory sources. Since June 2000, LOINC has also included other clinical information in addition to laboratory tests, such as medical history, claims attachment, and physical findings [33]. An item name can be uniquely identified by six fields separated by a delimiter (colon) in the LOINC database [14]. The six fields are <Analyte(Component)> : <Property> : <Time Aspect> : <System (Sample)> : <Scale> : <Method>. Similar to LOINC, SNOMED is also a transcendent ontology [34]. If we create ontology relationships between the internal code sets and the LOINC sets (for example, "sameas", "isamemberof", "requiredby", and so forth) then we can create a very powerful tool for data mining and research in a structured format. LOINC is considered a good basis for developing a medical ontology library, but has been applied only on a limited scale in China (e.g., the ICD-9-CM) because of various issues, including differences in business rules and language, as well as copyright restrictions. We have previously surveyed the coding systems for laboratory tests in six AAA-level hospitals in China s Zhejiang Province, and found that even for a simple term such as Platelet Count, the local code used in each hospital was different. Therefore, the lack of a standardized CMV has severely impaired the accuracy and integrity of electronic data records, and may impede future data integration. 3. Realizing EHR Interoperable Methods In this chapter, first the framework model is outlined to establish interoperability with EHRs. Second, the methodology is laid out on the syntactic level. Third, the mapping of the BDS and CDA items within the EHRTG are presented, and the document profiles of other specific business domains are discussed. Last, cross-mapping is conducted on the semantic level between internal codes of the legacy system and international standard codes. 3.1. Proposed framework Figure 1. Schematic showing the proposed framework for EHR interoperability Based on the characteristics of the health care system in China, we propose a structure based on the HL7 v3 CDA R2, BDS, and social insurance (SI)-LOINC, as a framework (illustrated in Fig 1) to realize EHR interoperability between federated clinical affinity domains around the country [35]. The - 283 -

framework is supported by interoperability at four sublayers, including a transport level, syntactic level, semantic level, and organizational level. In this framework, the top three levels should be compatible with the business rules of the health care system. 3.1.1. Transport level The transport level is responsible for data transfer, including its security and reliability. This lowest level of the framework is not exclusive to health care applications. Existing protocols can satisfy the requirement of interoperability at this level, such as the web services profile [36], ebxml message specification profile [37], and transmission control protocol/internet protocol (TCP/IP)-based minimal lower layer protocol profile [38]. 3.1.2. Syntactic level (exchange standard) This level is mainly responsible for controlling the structure and format of the data to be exchanged. The EHRTG (see below) is used at this level to enable heterogeneous systems to exchange information and understand the XML format and structure of the data being exchanged. 3.1.3. Semantic level (content standard) This level is responsible for the actual exchange of health data. Although the previous two layers allow data to be successfully shared, they cannot ensure that all heterogeneous systems interpret the exchanged information identically. This can be achieved only when the systems operate with the same semantics. Here, we propose a technique to allow all systems to communicate using a general information structure model, vocabulary system, and data types by mapping between EHRTG structure elements and BDS/CMV data elements as well as between CMV and local codes of federated clinical affinity domains [39]. 3.1.4. Organizational level This level not only shares and interprets but also manipulates the data, by the way of data modification. The objective is that the modified data should be correctly interpreted by other interoperable systems. This requires different federated clinical affinity domains to reach an agreement on the use of the data, namely by sharing the rules of business processing. Therefore, interoperability at this highest level is the most complicated among all the layers. We believe that successful EHR interoperability requires consensus at all these layers, and the degree of interoperability is determined by the extent of commonality. In this framework, each lower level must have interoperability in order for the higher level(s) to be interoperable. 3.2. Exchange standard (development of the EHRTG) Although China s Ministry of Health has published content templates for EHRs, an EHR guideline profiles library based on the HL7 v3 CDA R2 and BDS remains unavailable for use in medical institutions. In collaboration with the Ministry, in 2008 we began the development of an EHRTG. First, we propose a general EHRTG structure for particular domains. HL7 v3 provides two methods for the localization of RIM, a Constraint Method and a Transformation Method [40]. The proposed EHRTG incorporates the two methods. Specifically, the R-MIM model for the business process of the target subject area and the R-MIM model of CDA were combined to form a general CDA R-MIM model for the particular subject area. Or if a suitable model was available in the HL7 template library, it was directly adopted. This procedure generated a blank HL7 v3 CDA R2 EHR template, which was then mapped to the BDS to form CDA templates for the corresponding domains. Elements that could not be directly mapped from the BDS were treated separately by creating corresponding entry classes, and they were subsequently mapped to the BDS [41]. - 284 -

The workflow of the methodology of the Constraint Method is shown in Fig 2. 3.3. Mapping the BDS to CDA items Figure 2. Methodology of the Constraint method In the HL7 v3 CDA R2, a CDA document contains a Header and a Body. The CDA Header contains managerial information, mainly the type of document, patient information, author information, and health care provider information. We mapped the nine data groups (H.01: Document ID; H.02: Identifiers of target service; H.03: Personal demographic data; H.04: Next of kin; H.05: Address; H.06: Telephone; H.08 Healthcare organization; H.09: Health service provider; H.10 Health event summary) and two data subgroups in the BDS (H.02.001: Personal biological identifiers; H.02.002: Personal risk identifiers) to the items in the CDA Header to form a general Header specification, entitled CDAbased Medical Document Content Module Standard-Part 1: Basic Medical Document Specification. The value sets of the Header data elements were set according to current national coding standards. For example, the patient s sex was encoded following GB/T 2261.1-2003, marital status following GB/T 2261.2-2003, and education following GB/T 4658-1984. The Specification has significant value in that it provides a reference for the creation of document profiles of other specific business domains. In particular, document profiles for a business domain can be conveniently created by further constraining (using the Constraint Method) without the need for re-description, as compared with the TMT of Taiwan. The Body contains the clinical report in addition to the information in the Header. The EHRTG proposed here is based on forms, which correspond to individual health care activities. The forms were classified according to medical diagnostics theory [42] and included in different blocks, with each block as a section. The remaining 66 data groups/subgroups were also mapped to CDA sections, with a unique ID for each section, a <title> element describing its clinical implication, and a <text> element including the details of each item. - 285 -

Figure 3. Schematic illustration of the relationships between the data sets of the BDS and the HL7 v3 CDA R2 Additionally, the relationship between BDS data elements and CDA items was maintained by using a mapping engine (Fig 4.) based on Microsoft Excel. The Excel engine has three main components: a standard sample list, which includes a profile field and correlates with data elements in the BDS; a cross-mapping table, which includes the mapping of BDS data elements and CDA items, as well as the BDS data element codes for value sets; and a section/entry table, including all of the codes for section types and for entry types in the CDA document body. The engine stores the mapping relationship between BDS data elements and CDA items to minimize the risk of incorrect mapping. Meanwhile, the engine is also responsible for creating and maintaining CDA example codes and the required hierarchical message description documents. The following is an example of a section template guideline generated after completion of the mapping. <section> <templateid root='moh.rhin.cls.cda.sec.cc.sf'/> <code code='s.01.001' displayname=' Symptom: fever' codesystem='moh.rhin.cls.cs.bds' codesystemname='bds'/> <text> <list> <item ID='direct'> hyperpyrexia, cough for 3 days </item> </list> </text> - 286 -

<entry> <!-optional --> <templateid root='moh.rhin.cls.cda.entry.cli.pro'/> </entry> </section > (MOH.RHIN.CLS.CDA.SEC.CC.SF) is the template ID of the Chief Complaint Section. The <text> element contains a text description of the patient s primary health problem, main reasons for hospital visit, symptoms or signs and duration. The section template also allows the information in the text to be presented in a machine-processable format in the clinical problems entry template (MOH.RHIN.CLS.CDA.ENTRY.CLI.PRO). The <templateid root='moh.rhin.cls.cda.sec.cc.sf'/> is the unique ID of this section. Currently, a trial object identifier (OID) is being used in experiments; in the future, the EHRSC will apply for an official OID from HL7. The generated section template can be used as the basic general section template. In creating CDA section profiles for different domains, the profiles can be simply inherited from an ancestor profile and further tailored by using the Constraint Method. Figure 4. Screenshot of the BDS/CDA item mapping engine - 287 -

In accordance with the characteristics of the national health care system, the BDS includes a special data set to deal with cost-related data. However, the HL7 v3 CDA R2 clinical statement model prohibits the use of finance-related classes in RIM, such as Transaction and Payment. To maintain compatibility with the HL7 CDA, we adapted Act (an entry for describing financial data in agriculture) for our purposes. (Meanwhile, the BDS itself is undergoing active development and some data elements might experience major modifications in the future, including incorporation of more costrelated information.) The data set includes two data groups: 1. Payment section. This section includes information on payment activities and the fee paid. An Act/code element describes the method of payment. The Act class is connected to a RIM Role class through a RIM participation class to describe the payer. 2. Healthcare service fee section. This section includes information on the cost of specific health care services. It includes an Observation entry, which further includes an Observation/code element to describe the classification of the health care service, and a Value element to describe the amount charged for the service. In addition, the BDS also includes a large number of data elements that essentially can be derived from other data, such as number of in-hospital stays and number of outpatient visits. In principle, these data elements can be easily calculated based on the record of patient encounters, but many HISs in operation in China currently do not provide structured information on the patient s encounter history. Consequently, it is more realistic to directly record these data for later output. However, because theoretically they should be determined by calculation, specific models developed for these data would not be related to any clinical business models. Therefore, we designed a general administrative template for recording these data that could otherwise not be easily expressed using an existing model. The general administrative template provides an abstract class and is not specific to a clinical business model; it can be used to describe clinical administrative concepts defined on corresponding value sets (which are extendable) as well as the associated data. Meanwhile, the BDS is the metadata bridge in the legacy system based on relational databases and CDA items of other specific business domain profiles. The mapping of metadata and the BDS has been completed, and incorporated in the Laboratory Results Report Document and the Inpatient Summary Document in accordance with the CDA-based Medical Document Content Module Standard-Part 2: Laboratory Results Report Document Specification, as well as the CDA-based Medical Document Content Module Standard-Part 2: Inpatient Summary Document Specification. 3.4. Mapping laboratory internal codes to LOINC The BDS alone cannot ensure that the receiver and sender communicate based on an identical understanding of the content in an exchanged CDA. A CMV such as LOINC is required for this purpose. The internal codes for laboratory tests should first be mapped to LOINC because laboratory data are one of core components of electronic health records [43], and also because the LOINC coding is multipurpose [44] and can serve as an important complement to the BDS. The health service price regulation office of each province in China has developed a local coding system, termed social insurance (SI), for the terminology in clinical laboratory tests and prescriptions [45]. In all hospitals in a particular province, the internal code for each test item is required to conform to the corresponding SI. However, the SI systems are cost-focused, and a particular SI code may correspond to multiple test services with the same price. In addition, the SI code sets cannot adequately describe the details of laboratory tests, and thus might occasionally lack a description of essential information. Because of these disadvantages, the SI coding systems alone cannot support the standardized exchange of laboratory test data. Having realized this, the EHRSC assembled a consulting team including experts from six AAA-level hospitals in Zhejiang. Based on clinical laboratory science as well as the laboratory information systems (LISs) in the six hospitals, the team successfully developed a mapping between the SI in Zhejiang province and the six fields in LOINC, as listed in Table 1. - 288 -

4. Results Developing Interoperable Electronic Health Record Service in China Table 1. Mapping of LOINC fields and LIS fields LOINC Field LIS field Example Local code and name of the test, 1654 white cell counting (W.B.C.), Analyte/component tube used for sampling plain tube Property Unit 10^3/μl Time Name of test, important notice Draw blood immediately, avoid hemolysis System Sample Blood Scale Reference level Quantitative, number Method Instrument or method Beckman coulter lh7500 4.1. Creation of medical field record document profiles By the methods described above, we have successfully created the specifications for reusable CDA Headers ( CDA-based Medical Document Content Module Standard-Part 1: Basic Medical Document Specification ), 66 reusable basic section templates, 23 reusable basic entry templates (which became the CDA-based Medical Document Content Module Standard-Part 3: Section and Entry Template Library ), and the corresponding value fields for the data elements mapped in these templates (which became the CDA-based Medical Document Content Module Standard-Part 4: Coded Data Elements Value Set Library ). By reusing, inheriting, and constraining these basic templates, 22 clinical document profiles for various domains were further developed, including the CDA-based Medical Document Content Module Standard-Part 2: Laboratory Results Report Document Specification, CDA-based Medical Document Content Module Standard-Part 2: Adult Physical Examination Results Report Document Specification, CDA-based Medical Document Content Module Standard-Part 2: Outpatient Medical Summary Document Specification, CDA-based Medical Document Content Module Standard-Part 2: Inpatient Service Document Specification, CDAbased Medical Document Content Module Standard-Part 2: Healthcare Service Payment Document Specification, and CDA-based Medical Document Content Module Standard-Part 2: Inpatient Summary Document Specification etc. As shown in Fig 5, by inheriting from CDA-based Medical Document Content Module Standard- Part 1: Basic Medical Document Specification, the Header of Laboratory Results Report Document Specification was generated. Because the structure of the CDA Header was clearly defined, its items were further constrained based on the business model for laboratory tests. For example, additional semantic constraints were imposed on the ClinicalDocument/title element to specify that it must include the string Laboratory Results Report. By constraining operations, it was possible to further tailor or add constraints to CDA items, but extension of an item is not allowed. Then, according to the business model for laboratory tests, three basic section templates ( Chief Complaint Section, Laboratory Specialty Section, and Laboratory Report Item Section ) already available in the template library were reused to develop the Body of the target document. Previous consultation with experts revealed that two laboratory report formats are used in China. The first format, primarily used in northern China, lists results from multiple tests, such as blood band studies and blood gas studies. The other format, mainly used in the eastern and coastal areas of China, only lists results from one test subject. To accommodate this regional difference, we inherited and reconstructed the Laboratory Specialty Section and thus generated two new sections for the two formats, Laboratory Specialty Section-Composite and Laboratory Specialty Section-Single, and further constrained the corresponding value fields of their Section/code elements. Then they were added into the template library as extended templates, which consequently became reusable when developing the document profiles of other domains. Finally, the value sets of the data elements in the new templates were added to the coded Data Elements Value Set Library. - 289 -

Figure 5. Illustration of developing document profiles (Laboratory Results Report Document Specification) for particular domains through reuse of CDA-based Medical Document Content Module Standard 4.2. Examination of syntax and business rules Here we describe a two-phase technique to validate a CDA document generated following the EHRTG. The first phase is syntactic validation, in which a CDA document instance is validated against an XML schema definition (XSD). Because the general structure of the EHRTG was adapted to the CDA conformant method, the generated CDA instances should pass the XSD validation. The second phase is business rule validation, which verifies a series of rules among elements. Using Schematron [46], we created rule validation documents based on the constraining rules for the clinical document profiles of 22 domains. The documents are used for validating constraints imposed on the corresponding items and sections. The following example shows part of the Schematron validation document for the CDA document Laboratory Results Report Document. <sch:pattern> <sch:rule context='hl7:clinicaldocument/hl7:component/hl7:structuredbody/ hl7:component/hl7:section/hl7:code'> <sch:assert diagnostics='cr-ltr-0004' test=' (compare(string(@code), '18717-9')=0 and compare(string(@codesystem), '2.16.840.1.113883.6.1')=0) or (compare(string(@code), '18719-5')=0 and compare(string(@codesystem),'2.16.840.1.113883.6.1')=0) '> CR-LTR-0004: section code element must observe the definition of laboratory test classification codes in LOINC </assert> </sch:rule> </sch:pattern> - 290 -

This example is a rule of the section level, which specifies that the value sets of section/code@code and section/code@codesystem in Laboratory Specialty Section-Single must be the corresponding laboratory test classification codes and the LOINC coding system, respectively. 4.3. SI-LOINC mapping database To minimize the range of candidate LOINC codes while maximizing the accuracy of SI-LOINC mapping, we first analyzed the National Health Insurance (NHI) coding system of Taiwan. Then, with the NHI system as a starting point, we formulated the SI-LOINC mapping of 54 common laboratory tests. The mapping successfully accomplished the goal of the first experimental project (Adult Physical Examination Results Report Document Specification) initiated by the Chinese Ministry of Health. The 54 common tests included 14 urine tests, three stool tests, 13 hematological examinations, 18 immunological examinations, and six biochemical examinations. A comparison between our coding system and the NHI coding system is shown in Table 2. Table 2. Summary of system mapping Category SI test NHI test Mapping rate Urine Test Stool Test Hematological Examination Immunological Examination Biochemical Examination Total 14 3 13 18 6 54 11 3 8 14 2 38 78.57% 100% 61.53% 77.77% 33.33% 70.37% It can be observed that, because of the differences in tests performed in Taiwan and mainland China, 29.63% of the codes in the SI system could not be mapped to the NHI system. The non-overlapping tests were manually mapped using the Regenstrief LOINC Mapping Assistant. Additionally, it was found that in some cases, different NHI codes could be mapped to a single SI code, such as mapping from NHI code 09015C to both SI codes 25030700200 and 25030700300. This multiple match is attributed to the health care pricing policies in mainland China, where the costs of some laboratory tests are dependent on their priority level; for example the emergency test for creatinine (Creatinine, CRTN) is of higher than the counterpart outpatient test, although the two tests are semantically identical. Hospitals in China typically use individualized coding systems for their laboratory tests, and these tend to be substantially different from the LOINC system. Our method can maximally protect the investment on the original system. Additionally, it can reduce the technical difficulties in code mapping while improving the understanding among laboratory staff regarding the LOINC system. - 291 -

Figure 6. Mapping steps between local laboratory codes and LOINC Figure 7. Examples of SI-LOINC mapping database content - 292 -

5. Conclusion and future research directions To date, most health care information technology systems in China have been designed following the structures of medical domains and have consequently produced numerous information islands. In addition, each system manages only a part of the information generated during the whole health care process of each patient, and it is difficult to retrieve a patient s health information from another system. Because of this lack of interoperability, clinicians are often forced to perform diagnoses and operations without complete background information, which may result in unnecessarily repeated examinations, inferior treatment, and even medical error. A secure and reliable health information system that can continuously encompass the complete process of health care is critical to ensure safe and effective health care services. Interoperable EHRs can effectively meet this requirement. Based on our previous work, we have proposed here a theoretical framework based on the HL7 v3 CDA R2 and BDS as an approach to achieve HIS interoperability in China. The framework is divided into four levels: (from lowest to highest) the transport level, semantic level, syntactic level, and organizational level. Each lower level must have interoperability in order for the higher level(s) to be interoperable. The characteristics of the framework include maneuverability and practicality for broader national implementation, as well as suitability for use with the conditions and medical information level of China, as compared with other countries systems such as the NHIS-T in Turkey, TMT in Taiwan, and MREx in Saudi Arabia [10,47,48]. Furthermore, hospitals have been directed to refer to the Laboratory Results Report Document and Inpatient Summary Document in accordance with the CDA-based Medical Document Content Module Standard-Part 2: Laboratory Results Report Document Specification, as well as the CDA-based Medical Document Content Module Standard- Part 2: Inpatient Summary Document Specification, which emerged from the AAA-level hospital evaluation in Zhejiang Province in 2010. Within this framework, we developed the CDA-based Medical Document Content Module Standard-Part 1: Basic Medical Document Specification, CDAbased Medical Document Content Module Standard-Part 3: Section and Entry Template Library, and CDA-based Medical Document Content Module Standard-Part 4: Coded Data Elements Value Set Library. Through reusing, inheriting, and constraining, we further developed 22 example document profiles for specific domains, including the Laboratory Results Report Document Specification, Adult Physical Examination Results Report Document Specification, Outpatient Medical Summary Document Specification, Inpatient Service Document Specification, Healthcare Service Payment Document Specification, and Inpatient Summary Document Specification. We also created XSD and Schematron documents for verifying the conformance of the generated CDA documents to the structures and business rules in the above profiles, respectively. Because the BDS alone cannot ensure the use of identical semantics among communicating systems, CMVs are needed to meet the requirement of having document profiles in various domains, such as the use of LOINC for the Laboratory Results Report Document. Therefore, we also developed a SI- LOINC mapping algorithm to help laboratory staff convert between local codes in federated clinical affinity domains and the LOINC codes. In the future, we will develop more document profiles for different domains and more CMVs, as well as the mapping between SNOMED codes and local codes. Meanwhile, we will consider a set of evaluation criteria for the proposed framework in our follow-up work, and attempt to construct and implement the evaluation over the next 1-2 years. Based on this work, we will proceed to develop health information ontologies suitable for the particular conditions of the health care system in China. 6. Acknowledgments This research was supported by the Key Project of the National Eleventh Five-Year Research Program of China Grant (No. 2008BAH27B01, No. 2008BAH27B03) from the Ministry of Science and Technology of the People s Republic of China. The authors would like to thank the Center of Health Statistics and Information, Ministry of Health, P.R. China. We thank the Regenstrief Institute for free distribution of the LOINC database. We also thank HL7 Taiwan for distribution of the NHI- LOINC. Special thanks are extended to the hospitals that participated in this research. - 293 -

7. References [1] "HIMSS - Electronic Health Record (EHR) [Online]", Available: http://www.himss.org/asp/topics_ehr.asp. [2] Kilic O., Dogac A., "Achieving Clinical Statement Interoperability Using R-MIM and Archetype-Based Semantic Transformations", Information Technology in Biomedicine IEEE Transactions on, vol. 13, no. 4, pp.467-477, 2009. [3] "Canada Health Infoway [Online]", Available: http://www.infowayinforoute.ca. [4] "Federal Health Information Technology [Online]", Available: http://www.hhs.gov/healthit. [5] "NHS Connecting for Health [Online]", Available: http://www.connectingforhealth.nhs.uk/. [6] "Dossier Médical Personnel (DMP)". [7] Moulton. B., Chaczko. Z. et al., "Data Fusion and Aggregation Methods for Pre-Processing Ambulatory Monitoring and Remote Sensor Data for Upload to Personal Electronic Health Records", International Journal of Digital Content Technology and its Applications, vol. 3, no. 4, pp.120-127, 2009. [8] Nagy M., Preckova P. et al., "Challenges of interoperability using HL7 v3 in Czech healthcare", Stud Health Technol Inform, vol. 155, pp.122-128, 2010. [9] Dogac A., Yuksel M. et al., "Electronic Health Record Interoperability as Realized in the Turkish Health Information System", Methods Inf Med, vol. 50, no. 1, pp.1, 2010. [10] Hsiao-Hsien R., Chien-Yeh H. et al., "Developing Electronic Health Records in Taiwan", IT Professional, vol. 12, no. 2, pp.17-25, 2010. [11] Chen Z., "Overall Strengthening of Health Care Quality Management [Online]", Available: http://www.moh.gov.cn/publicfiles/business/htmlfiles/chenz/pldjh/200810/38023.htm. [12] "A Compilation of IEEE Standard Computer Glossaries", IEEE Standard Computer Dictionary, IEEE, New York, 1990. [13] Brown N., "Short Strategic Study CEN/TC 251/N00-047: Strategy for production and maintenance of standards for interoperability within and between service departments and other healthcare domain", CEN/TC251 Health Informatics, Belgium, 2000. [14] Li. B., "China Health White Paper", In China Health Information Technology Conference & International Forum, 2008. [15] "HL7 Clinical Document Architecture Release 2 [Online]", Available: http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm. [16] "CEN/TC 251; EN 13606-1; Health Informatics Electronic Health Record Communication Part 1: ReferenceModel [Online]", Available: http://www.chime.ucl.ac.uk/resources/cen/en13606-1/n06-02_pren13606-1_20060209.pdf. [17] "openehr Community [Online]", Available: http://www.openehr.org/. [18] "Kind Messaging for the Electronic Healthcare Records (Kmehr) [Online]", Available: http://www.health.fgov.be/telematics/kmehr/one/. [19] Tu H., Yu Y. et al., "Building Clinical Data Groups for Electronic Medical Record in China", J Med Syst, vol. 2010, pp.14, 2010. [20] Jinhuang. Z., Sui H., "Modeling and Designing the System of Electronic Patient Record Based on XML", Computer Applications and Software, vol. 21, pp.216-219, 2004. [21] Li. X., Cong. Y. et al., "Personal Health Record Based on XML Technology", Computer Applications and Software, vol. 27, no. 3, pp.152-155, 2010. [22] Haomin. L., Huilong. D. et al., "Method Of Structured Electronic Health Record Data Entry", Journal of Zhejiang University(Engineering Science), vol. 42, no. 10, pp.1693-1696, 2008. [23] Huff S.M., Rocha R.A. et al., "Development of the Logical Observation Identifier Names and Codes (LOINC) vocabulary", J Am Med Inform Assoc, vol. 5, no. 3, pp.276-292, 1998. [24] Dolin R.H., Alschuler L. et al., "HL7 Clinical Document Architecture, Release 2", J Am Med Inform Assoc, vol. 13, pp.30-39, 2005. [25] "American National Standards Institute [Online]", Available: http://www.ansi.org/. [26] Dolin R.H., Alschuler L. et al., "The HL7 Clinical Document Architecture", J Am Med Inform Assoc, vol. 8, no. 6, pp.552-569, 2001. - 294 -

[27] Beeler G.W., "HL7 Version 3-An object-oriented methodology for collaborative standards development", International Journal of Medical Informatics, vol. 48, pp.10, 1998. [28] "Basic Health Data Sets of China (BDS) [Online]", Available: http://www.moh.gov.cn/publicfiles/business/htmlfiles/mohwsbwstjxxzx/s7968/list.htm. [29] "National Health Metadata Dictionary of China (NHMD) [Online]", Available: http://www.chiss.org.cn/. [30] JJ C., G H. et al., "Designing an Introspective, Multipurpose, Controlled Medical Vocabulary", In Proceedings of the Thirteenth Annual Symposium on Computer Applications in Medical Care(SCAMC), pp.513-518, 1989. [31] Statistics U.S.N.C.f.I., "International Classification of Diseases, Ninth Revision, with Clinical Manifestations", Washington DC, 1980. [32] "International Classification of Diseases (ICD 10) [Online]", Available: http://www.who.int/classifications/icd/en/. [33] McDonald. C., Huff. S. et al., Logical Observation Identifiers Names and Codes (LOINC ) Users' Guide Ver 2, 2007. [34] Jepsen T.C., "Just What Is an Ontology, Anyway?", IT Professional, vol. 11, no. 5, pp.22-27, 2009. [35] Dogac A., Laleci G.B. et al., "Enhancing IHE XDS for Federated Clinical Affinity Domain Support", Information Technology in Biomedicine IEEE Transactions on, vol. 11, no. 2, pp.213-221, 2007. [36] "HL7 Version 3 Standard: Transport Specification - Web Services Profile Release 2 [Online]", Available: http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-wsprofiles.htm. [37] "HL7 Version 3 Standard: Transport Specification - ebxml Messaging Services Profile Release 2 [Online]", Available: http://www.hl7.org/v3ballot/html/infrastructure/transport/transportebxml.htm. [38] "Minimal Lower Layer Protocol Profile [Online]", Available: http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-mllp.htm. [39] Dehmoobad A., Sartipi K., "Minimized Domain Knowledge for SOA-Based Interoperability", In Asia-Pacific Services Computing Conference 2008 IEEE, pp.500-506, 2008. [40] "HL7 Refinement Constraint and Localization Release 2 [Online]", Available: http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.htm. [41] Liang J., Xu M.F. et al., "Increasing the meaningful use of electronic medical records: A localized health level 7 clinical document architecture system", In the 6th International Conference on Advanced Data Mining and Applications, pp.491-499, 2010. [42] Chen. W., Pan. X., Diagnostics. Version 7, People Health Press, BeiJing, 2008. [43] Takedaa. H., Matsumuraa. Y. et al., "Architecture for networked electronic patient record systems", International Journal of Medical Informatics, vol. 60, no. 2, pp.7, 2000. [44] Cimino J.J., "Desiderata for Controlled Medical Vocabularies in the Twenty-First Century", Methods of Information in Medicine, 1998. [45] Zhang. Y., Zhang. L. et al., "Impact of Information Asymmetry on China's Medical Insurance System:An Analysis from Co-insurance and Reinsurance Perspectives", International Journal of Digital Content Technology and its Applications, vol. 5, no. 1, pp.10-15, 2011. [46] "Schematron [Online]", Available: http://www.schematron.com/. [47] Köse. I., Akpinar. N. et al., "Turkey s National Health InformationSystem (NHIS)", In 9th International HL7 Interoperability Conference, pp.8, 2008. [48] Al-Safadi L.A.E., "Electronic Medical Record Ontology Mapper ", International Journal of Advancements in Computing Technology, vol. 1, no. 1, pp.85-97, 2009. - 295 -