HL7 and SOA Based Distributed Electronic
Patient Record Architecture Using Open EMR

Priti Kalode; Dr Onkar S Kemkar; Dr P R Gundalwar

HL7 and SOA Based Distributed Electronic Patient Record Architecture Using Open EMR

Priti Kalode¹, Dr Onkar S Kemkar², Dr P R Gundalwar³

Research Student, Dept of Comp Sci &Elec, RTM Nagpur University Campus, Nagpur, India
Associate Professor, Dept of MCA, VMV College, Wardhaman Nagar, Nagpur, India
Associate Professor, Dept of MCA, VMV College, Wardhaman Nagar, Nagpur, India

Related article at Pubmed, Scholar Google

Visit for more related articles at International Journal of Innovative Research in Computer and Communication Engineering

Abstract

Semantic interoperability of electronic medical records systems is a major challenge in eHealth, because it would allow healthcare professionals to manage the complete EMR of patients, independently from the institutions that generated each clinical session. However, clinical information is usually distributed among several independent systems that may be syntactically or semantically incompatible. In this paper we proposed a architecture of an integrated DEPR system based on HL7 CDA standards which is derived from the OpenEMR system.

Keywords

HL7, CDA, OpenEMR, EMR, System Integration

INTRODUCTION

The OpenEMR approach to modelling information, services and domain knowledge is based on a number of design principles, described below. All of these principles lead to a separation of the models of the OpenEMR architecture, and consequently, a high level of componentization. This leads to better maintainability, extensibility, and flexible deployment. The most basic kind of separation in any system of models is ontological, i.e. in the semantic dimension. All models carry some kind of semantic meaning, but not all semantics are the same, or even of the same category. For example, some part of the SNOMED-CT terminology will describe types of bacterial infection, sites in the body, and symptoms. An information model might specify a logical type Quantity. A content model might define the model of information collected in an ante-natal examination by a physician. These types of information are qualitatively different, and need to be developed and maintained separately within the overall model eco-system

The medical information service platform can provide the data of physiological measuring device upload, store, realtime exception notification and online physiological measuring data query service that are closed system with special function and particular data format. We use service oriented architecture (SOA) system architecture that can combine variety of heterogeneous systems and that can integrate all wrapped services and implement a standard interface with external communication. The advantage is to reduce redundancy design and development time of the healthcare service systems [1].The EHR data format is converted to the electronic medical records (EMR) that is based on the Health Level 7 clinical the document architecture. The EMR is the reference when the doctor diagnosis or health care personnel associated services [2].

HL7 is mainly applied various types of medical information systems, such like the medical orders information systems, inspection systems, pharmacy information and management information systems which is a standards for interchange electronic data. HL7 develop for different types of electronic medical record information standard in nature of medical information. Also, they include the common standard: CDA(Clinical Document Architecture), CCR (Continuity of Care Record) and CCD (Continuity of Care Document) [4, 5].In our study which records the different physiological strategy process for a long period. We design the required data format and element base on the CDA format.

II. SYSTEM ARCHITECTURE

The system uses service-oriented architecture (SOA) and the standard structure of HL7 to exchange health information, the ease of information exchange with other medical record systems is also considered. Figure 1 shows the DEPR system architecture:

A. Data Layer

The Data layer involves the capture and storage of patient information in a GP Information System. An Open source GP Information System was chosen to represent legacy open source GP Systems OpenEMR.

Aim of the OpenEMR is to understand the remainder of the document. The architecture of OpenEMR is designed to support the construction of a number of types of system. One of the most important could be characterized as a distributed, patient-centered, life-long, shared care health record, illustrated in figure 2.

In this form, the OpenEMR services are added to the existing IT infrastructure provide a shared, secure health record for patients that are seen by any number of health providers in their community context

OpenEMR-enabled systems can also be used to provide EMR/EPR functionality at provider locations. Overall, a number of important categories of system can be implemented using OpenEMR including he following:

? shared-care community or regional health service EHRs;

? summary EHRs at a national, state, province or similar level;

? small desktop GP systems;

? hospital EMRs;

? consolidated and summary EHRs in federation environments;

? legacy data purification and validation gateways;

? Web-based secure EHR systems for mobile patients.

B. Functionality of OpenEMR

The application stores

? patient demographic data

? patient encounter information

? laboratory results

? Prescriptions and allergy information.

? The system also allows the management of appointments and the generation of reports.

C. Interfacing to OpenEMR

The project entailed building an Interface Engine was developed in order to extract, Distribute Electronic patient Record (DEPR). This will hold patient history along with known allergies and any medications prescribed in the last 6 months.

The HL7 Clinical Document Architecture (CDA) was chosen as the document architecture standard.

The Interface Engine retrieves data from OpenEMR databases and construct CDA conformant documents using the CDA schema.

D. HL7 CDA

The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange.

A CDA document can include

? Text

? Images

? Sounds

? other multimedia content.

Structure of CDA Document is as follows:

... CDA Header ...

<ExternalObservation>...

</ExternalObservation>

</reference>

</Observation></section>

</section>

</StructuredBody>

</ClinicalDocument>

... CDA Header ...

</reference>

</Observation></section>

</section>

</StructuredBody>

</ClinicalDocument>

E. DEPR Record as a CDA Document

DEPR Document

Header

Recordset (Patient Id, Patient Name, Gender, DOB) Section

Symptotic Diagnosis and Gynecological Symptoms.

F. Interfacing

The Interface Engine was coded using Asp.Net and using a CDA document. The mapping from the OpenEMR database to the CDA schemas was incomplete as the database did not hold all the data specified in the CDA document schema. For example OpenEMR currently does not store clinical codes with separate parts of the medical record so the code fields in the CDA documents were left empty. Also the OpenEMR system stores dosing intervals as qid, bid, q3h while the CDA document needs these intervals to be represented as time periods and unit (e.g. 3 hours). The index information is initially retrieved from the OpenEMR Clinical Information System using the data layer interface as described above. The index information is wrapped in an XML message.

III. SERVICE ORIENTED SOLUTION (SOA)

A Web Services Server was used to build the SOA. The Web Service was defined in WSDL using Cape Clear Studio. The Web Service was implemented in Asp.Net and uses the SOAP protocol at the messaging layer. It generates SOAP requests which are sent to the sever and the response contains DEPR record

The SOA is composed by web service technology and standardized components that focus on businesses, schools or provide network services units to construct a flexible, reusable integration interface. It also promotes external as internal applications, users and departments perfect communication. In recent years usually has been used to integrate heterogeneous platforms. In this paper, we design a network service platform for health management based on SOA architecture use standard messages (such like XML) for data exchange

IV. CONCLUSION

The OpenEMR specifications make use of available standards where relevant, and as far as possible in a compatible way. However, for the many standards have never been validated in their published form. OpenEMR makes adjustments so as to ensure quality and coherence of the OpenEMR models. In general, using a standard in OpenEMR may mean defining a set of classes which map it into the OpenEMR type system, or wrap it or express it in some other compatible way, allowing us to build completely coherent OpenEMR systems, while retaining compliance or compatibility with standards.

Figures at a glance


Figure 1	Figure 2	Figure 3	Figure 4	Figure 5

References

Hongqi Li, and Zhuang Wu, “Research on Distributed Architecture Based on SOA,” 2009. ICCSN ‘09. International Conference onCommunication Software and Networks, pp. 670-674, 27-28 Feb. 2009.

J. Voos, G. Riva, Z.erbini, C. Centeno, and E. Gonzalez, “Custom HL7 V3 message provider using web services security features,” 2010Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC), pp. 3899-3902, Aug. 31 2010-Sept. 42010.

openEHR Foundation. http://www.openehr.org.

Health Level Seven, Inc. http://www.hl7.org

Blobel B. HL7 and architecture standards of electronic

Electronic health records (EHRs). In: Ferrer-Roca O(ed.). roceedings XIII Winter Course: AmbientIntelligence in Medicine AmI@Medicine,Tenerife, Canary Islands, Spain: CATAIedition; pp.141-8, 2004.