Application of RFID Technology in eHealth

1. Introduction

Today’s hospitals are particularly interested in increasing the quality and efficiency of patient identification and monitoring procedures. While most patient health records are stored in separate systems, there is still a huge stack of paperwork left for health-care providers to fill out in order to comply with different regulations. Since many health care errors occur when important patient information is missing or simply not available, the electronic medical records (EMRs) may easily alleviate the distress of most doctors and nurses working in today’s care system.

The next step beyond the EMR is to connect and provide medical information to primary care physicians, medical and surgery specialists, anesthesiologists, nurses, assisted-living staff, patients themselves, patient’s family and so on.

However, each hospital may use a different system, store data in many ways and even decide upon its own data format. Furthermore, file system access and data retrieval are often governed by inconsistent parameters. Thus, the availability of medical information is seriously affected and effective communication among physicians is not achieved.

Within this framework, the present chapter focuses on how RFID technology can be used in order to solve the problems eHealth is dealing with. After defining the EHR and EMR terms, we shall focus on presenting an RFID-based system (named SIMOPAC) that integrates RFID and multi-agent technologies in the field of health care. The purpose of this system is to make patient emergency care as efficient and risk-free as possible, by providing doctors with as much information about a patient as quickly as possible. SIMOPAC could be used in every hospital with the existing systems in order to promote patient safety and optimize hospital workflow. The SIMOPAC system will assure information exchange with electronic health record (EHR/EMR) (Smaltz & Berner, 2007; Hallvard & Karlsen, 2006) systems set up in healthcare units. This information exchange will be in accordance with the HL7 standards specifications. In the present chapter, we will focus on the RFID technology and how it could be used in emergency care in order to identify patients and to achieve real time information concerning the patients’ biometric data, which might be used at different levels of the health care system (laboratory, family physician, etc.). Within the SIMOPAC system, the access to medical information is granted by an electronic memory-based chip (RFID tag or transponder). This tag, named Personal Health Information Card (CIP, in Romanian) (Turcu & Turcu, 2008), allows patient information storage (Jonathan, 2004). We describe a general purpose architecture and data model that is designed for storing and presenting clinically significant information to the emergency care physician. Also, we present the strengths and weaknesses of this RFID-based systems used in eHealth.

2. EHR vs. EMR

The most common method currently used by physicians in hospitals to record patient data is paper-based, a method considered low cost and easy to use. But there are various disadvantages concerning this practice, especially when health records must be stored for a long period of time. One disadvantage concerns the storage space: paper-based records require a significant amount of storage space in comparison with electronic/digital records. Another one refers to the costs involved: electronic storage media is cheaper then traditional storage media. More problems can occur when a patient’s paper records are stored at different levels of several health units: the process of collecting patient’s information by a health care provider proves very difficult and time consuming. In 1990, a study commissioned by the Institute of Medicine (IOM) highlighted the strength and weakness of the traditional paper-based health records. Some identified weaknesses were the disorganization, the illegibility, and the short availability (Van der Meijden, 2001). In order to eliminate the mentioned disadvantages and weaknesses the use of electronic medical records becomes imperative (I. de la Torre et al., 2010).

Electronic Health Record (EHR) and Electronic Medical Record (EMR) are two terms often used in the last years. Even though related to the same field and considered interchangeable, each of these terms describes a completely different concept and is defined in various ways. Recently, National Alliance for Health Information Technology (NAHIT), a leadership organisation that aims at enforcing the use of IT health systems in order to improve the US healthcare system has defined EMR and HER as follows:

1. EMR: The electronic record of health-related information on an individual that is created, gathered, managed, and consulted by licensed clinicians and staff from a single organization who are involved in the individual's health and care.

2. EHR: The aggregate electronic record of health-related information on an individual that is created and gathered cumulatively across more than one health care organization and is managed and consulted by licensed clinicians and staff involved in the individual's health and care.

A more elaborated definition of EHR was delineated by the Healthcare Information and Management Systems Society (HIMSS) – a professional member organization exclusively focused on providing leadership for the optimal use of healthcare information technology:

1. EHR: A longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports. The EHR automates and streamlines the clinician's workflow. The EHR has the ability to generate a complete record of a clinical patient encounter - as well as supporting other care-related activities directly or indirectly via interface - including evidence-based decision support, quality management, and outcomes reporting.

By considering these definitions one can conclude that an EHR is an EMR with interoperability. This attribute was also highlighted by Justin Barnes (Chairman Emeritus of the HIMSS) who believes that "the future of healthcare IT is interoperability”.

But selecting an EMR or an EHR software proves a difficult task for a health care services provider. Mr. Barnes considers that there are three criteria to be taken into consideration while choosing between EMR and EHR systems:

• Current-year interoperability certification standards (CCHIT- Certification Commission for Healthcare Information Technology, HL7 – Health Level Seven);

• A unique workflow that matches your practice and specialty;

• Excellent usability at the point of care.

Electronic medical records (EMRs) may easily alleviate the distress of most doctors and nurses working in today’s care system. Besides improving the degree of data availability among physicians and patients, they certainly increase the traceability of numerous medical details so deeply buried in traditional records. Still, despite these potential benefits that cannot be disregarded, doctors have been reluctant in adopting electronic health records.

Most hospitals have improved patient care by reducing wait times in the emergency ward when they decided to replace their paper-based process for emergency ward admission with a solution based on informatics systems. With these solutions in place, hospitals save minutes each time they admit a patient because doctors and nurses no longer fill out forms manually and improve healthcare outcomes. Thus, it has been estimated that 15 to 18 per cent of US physicians already use electronic health records (Tucci, 2008).

“Instant access to patient information is key to lifesaving care, especially in the emergency room and intensive-care unit, where delays may mean the difference between life and death”, Dr. Mark Smith said (Microsoft, 2006). Currently, Emergency Medical Service (EMS) providers rely completely on personal and medical history information provided by patients or family members. It is common knowledge that stress, physical and mental discomfort prevent most patients and family members to impart vital medical information. Problems may also arise if there are no family members around or if the patient is unconscious, incoherent or unable to talk or communicate (e.g. language difficulties).

The next step beyond the EMR is to connect and provide medical information to primary care physicians, medicine and surgery specialists, anesthesiologists, nurse practitioners, assisted-living staff, patients themselves, patient’s family and so on.

However, each health unit may use a different system, store data in many ways and even decide upon its own data format. Furthermore, file system access and data retrieval are often governed by inconsistent parameters seriously affecting the availability of medical information. Hence the inefficient communication among physicians.

Microsoft's Feied, a pioneer in medical training computer programs and medical intelligence software, said physician collaboration is the critical element for improving health care. He offered an impassioned testimonial. An emergency room physician who estimates he treated 80,000 patients "with my own hands", Feied said the thing that stuck out as he looked back on his career was how many times he was put in a position of "guessing over and over", "flying solo" in an information vacuum. In situations where people "die right in front of you", he said he often felt he was "one data element away" from stopping a patient from dying (Tucci, 2008).

The market for bringing healthcare data from disparate sources into one view is growing by leaps, according to a new study from KLAS, a healthcare research firm based in Orem, Utah (Klas, M., 2009).

For example, through Microsoft HealthVault and Google Health, Microsoft and Google have a common goal of managing vast quantities of personal health information to benefit end users. Thus, these systems encourage and support healthcare patients/consumers to control and account for their own and family health records.

According to (Impact, 2008), data integration – the automated aggregation and consolidation information from a variety of disparate systems and sources – across sites of care (inpatient, ambulatory, home), across domains (clinical, business, operational), and across technologies (text, video, images) – is the Holy Grail of healthcare information technology.

Still, it is necessary to find a way to get the vital medical data into the hands of those who can use it to save lives in emergency medical services, even when there is no connection to the Internet or the server is down.

Health systems and health policies across the European Union are becoming more and more interconnected, and also more complex. The European Commission aims at improving the safety of care for patients in all EU Member States through sharing information and expertise (EC, 2006). But healthcare is provided through different systems that run at the national level.

For the moment, introducing informatics systems within the Romanian healthcare proves to be relatively difficult, as patients data has not been shared at the level of medical entities, the medical records are not unitary and complete, and cannot be accessed online by the medical staff, when needed.

3. Healthcare in Romania

Medical care in Romania is not up to European standards and medical supplies are limited, especially in some rural areas. In larger cities, there are hospitals and private clinics, but in some small cities or village areas, quality health care level is low.

Hospitals are organized on geographical criteria at the regional, district and local level. Tertiary care is provided in specialized units (specialized hospitals, institutes and clinical centres) and in a number of cardiovascular and other surgery departments of teaching hospitals. Inpatient care is also provided by long-term care hospitals (for patients with chronic diseases who require long-term hospitalization), medicosocial care units (institutions under local authorities that provide both medical and social care), sanatoriums (units that besides usual treatments provide natural therapies) and health centres (inpatient units that assure medical services for at least two specialties) (C. Vlădescu et al., 2008).

The fact that primary care is provided especially by family doctors is an indicative of the low efficiency and underuse of primary and ambulatory care services. It is also a proof of the fragmentation of services and insufficient development of different levels of care.

Emergency care is provided through a network of emergency centres with a territorial dispatch system connected to hospital wards specialized in dealing with emergencies. Each district has an emergency dispatch system with a number of ambulances located in hospitals or dispatch centres and emergency wards at designated hospitals. All hospitals have to be prepared to receive emergencies, but not all of them are properly equipped for this purpose (C. Vlădescu et al., 2008).

The emergency system is based on the traditional ambulance system and SMURD (Romanian acronym for Mobile Emergency Service for Resuscitation and Extrication) as a complementary service, with a lot of bases in the whole Romania, still expanding.

Today’s Romanian medical sector has not fully embraced the gains and benefits of information systems. Thus, the medical staff is faced with endless amounts of paperwork of former and present patients. But, healthcare costs are expected to grow due to the aging of the population and the increasing demand on health systems. Considering this, one of the Romanian government’s priorities is controlling public spending on healthcare, in part, by IT investments.

In this context our research team proposed an integrated system for identification and monitoring of patients – SIMOPAC (C. Turcu & Cr. Turcu, 2008). This system was designed to integrate within the distributed medical information system, and privately, to solve the issues related to patient identification and monitoring. The SIMOPAC system will assure the information exchange with electronic health record (EHR/EMR) (Smaltz & Berner, 2007; Hallvard & Karlsen 2006) systems set up in healthcare units. This information exchange will be in accordance with the HL7 (HL7, n.d.) standards specifications. Within the SIMOPAC system, information needed in medical services is stored and can be accessed by means of a Personal Health Information Card (CIP, in Romanian) (C. Turcu & Cr. Turcu, 2008). This card will be implemented by using the RFID technologies (Jonathan, 2004), where information carrier is represented by a transponder (tag).

4. SIMOPAC system

In order to provide high-quality medical services to all its citizens, EU has recently proposed the interconnection of all health and medical care systems and services. Thus, this proposal aims at creating a large continental medical service space available to all European citizens and authorized medical personnel. Unfortunately, the major challenge of implementing e-Health applications in Europe is the lack of interoperability of European medical systems and services. In our attempt to address this complex issue, we have proposed an integrated system for the identification and monitoring of patients, a system that suits the Romanian medical environment and allows further adaptations to any medical environment.

Today’s Romanian medical sector has not fully benefited from all gains and advantages of information systems. Patient-related information is scattered among various medical units, the patients’ charts have no standardized form or content and are seldom complete or up-to-date; moreover, if needed, they cannot be accessed online by the medical staff. Considering these major inconveniencies, we have devised an RFID-based system, called SIMOPAC, for the distributed medical field. Employing the latest Radio Frequency Identification solutions, the system permits the real time patient identification and monitoring, ensures the collaborative problem solving in distributed environment (multi-agent technologies) and provides the communication infrastructure with multi-point connections to the medical information within the system.

4.1. SIMOPAC objectives

The research’s main objective was the implementation of an integrated system using RFID technologies, agents and web services in order to identify and monitor patients. Delivering multi-source real time medical information, the SIMOPAC system aims at optimizing medical decision by increasing the quality of patient-oriented medical acts.

The major objectives of the research were:

1. increase the efficiency of medical information management;

2. increase the quality of medical services by adopting advanced information technologies;

3. build and expand the Romanian health information system in accordance with EU requirements in the field of health and medical care;

4. eliminate all physical constraints of hardcopy documents and to grant immediate access to medical charts or patient records;

5. establish partnerships among research units in different fields and motivate them to cumulate their experience and expertise in joint health projects;

6. give assistance in providing citizens with comprehensive and reliable information.

The specific objectives of the research were:

1. implement several RFID software applications aimed at patient identification by using Personal Health Identity Cards (CIPs) that allow the extraction of vital data in medical care and emergency situations and strengthen patients’ trust in medical treatment as by considerably reducing medication errors;

2. implement a high-speed communication system that secures the access of the medical staff to the electronic medical records (bi-directional access) and thus allows all medical and patient-related information to be shared by all parties involved in health and medical care;

3. improve the communication among all health-service providers: family physicians/specialist physicians, hospitals, medical laboratories, etc.

4.2. SIMOPAC facilities

The SIMOPAC system allows:

1. access to medical services via RFID Medical ID Cards;

2. sharing of patient-related information and development of databases containing patients’ electronic medical records;

3. secure access to medical information databases (for both medical staff and patients), as well as the complete and speedy bi-directional transfer of information;

4. quick and accurate information gain on the medical status of patients transported in emergency units (ambulances) and requiring appropriate medication;

5. enhanced communication among all health and medical care services: family doctors, specialists, hospitals, medical laboratories, pharmacists;

6. automated information-flow in the medical system.

4.3. Standards and technologies employed

SIMOPAC employs the latest technologies and software solutions. Widely used in a variety of other applications, RFID technologies have proved considerable advantages for the medical environment. Efficient patient identification solutions have already been reported by many European and American hospitals. However, according to recent surveys, the implementation of RFID solutions in healthcare is still in its infancy. The application of this technology in hospitals is part of the view that in the hospital of the future the patient's life will not be saved by the latest medicine, but by computer systems.

Within the next ten years, multi-agent systems will trigger major transformations in health and medical care. The decision to integrate this technology in our SIMOPAC system was taken after a close consideration of its major advantages such as intelligent, adaptive and decentralized coordination-solutions and data availability in fragmented and heterogeneous environments. Our major aim was to design and develop software agents which could dynamically extract patient-related information from heterogeneous environments within a distributed communication structure.

4.3.1. RFID technology

RFID technology has been considered one of today’s “hottest” technologies due to its specialized capacity to track and trace objects in real time (Castro & Wamba 2007). RFID technology is classified as a wireless Automatic Identification and Data Capture (AIDC) technology that uses electronic tags to store identification data and other specific information, and a reader to read and write tags (Mehrjerdi 2007). Tags are small chips with an antenna. There are three different types of RFID tags: passive (uses the reader’s signal to be activated), active (battery powered) or semi-passive (battery-assisted, activated by a signal from the reader).

RFID technology is also providing a high level of security and has various important advantages over similar technologies, such as barcodes. It has been successfully implemented in a variety of areas, such as: logistics operations, inventory and materials management, industrial automation etc.

Healthcare industry can also benefit from the RFID technology. Although most of the current RFID healthcare applications and systems are just in some experimental phases, the future looks promising. Thus, some studies estimate that the market for RFID tags and systems in healthcare will rise from $90 million in 2006 to $2.1 billion in 2016 (RFIDUpdate 2008). The RFID-based systems can provide a number of benefits to the healthcare industry. By attaching RFID tags to different entities in healthcare industry (people and objects), RFID technology can ensure the following: identification, tracking, location and security. These capabilities directly affect the major issues currently experienced by healthcare organizations while helping to drive down costs (RFIDHealthcare, n.d.).

The main idea of any RFID healthcare system is to tag patients. Thus, an RFID tag attached to a patient needs to store some of the patient’s relevant information, such as: identification data, a list of chronic diseases the patient is suffering from and the most significant data of patient’s medical history. But, the common problem of any memory based system has always been that no amount of memory is ever sufficient (Peacocks, n.d.). On the other hand, it is well known that RFID tags with large memory capacity are too expensive to be used in a system with thousands of patients and the only way to keep costs low is to use passive tags with reduced memory capacity. But it is obvious that a tag with a reduced memory capacity cannot store all the relevant information related to a patient. This problem can be solved by storing the vital information on the RFID tag and the additional information into a central database, based on a tag template. The IP address of the database server could also be stored on the RFID tag, so that the additional information could be accessed by the medical staff over the Internet. This way, all relevant patient-related information will always be available for the medical staff.

Another important feature that an RFID healthcare system should provide is the ability to integrate and exchange information with similar systems. This could be achieved by using HL7 standards. HL7, an abbreviation of Health Level Seven, regards the information exchange between medical applications and defines a specific format for transmitting health-related information. Using the HL7 standard, information is sent as a collection of one or more messages, each of which transmits one record or item of health-related information. The HL7 international community promotes the use of such standards within and among healthcare organizations, in order to increase the effectiveness and efficiency of healthcare delivery for the benefit of all (HL7_1, n.d.; Iguana & Chameleon n.d.; Shaver, 2007).

4.3.2. The HL7 standard

What is HL7? HL7 (Health Level Seven) is a non-profit organization that is a global authority in the field of interoperability of health information technology (*, HL7). HL7's more than 2,300 members represent approximately 500 corporate members, which includes more than 90 percent of the healthcare information systems vendors (Ehto, n.d.). Furthermore, HL7 “is a standard series of predefined logical formats for packaging healthcare data in the form of messages to be transmitted among computer systems” (OTech, 2007).

Why HL7? Because “HL7 is the most widely used standard that facilitates the communication between two or more clinical applications. The prime benefit of HL7 is that it simplifies the implementation of interfaces and reduces the need for custom interfaces. Since its inception in the late 1980’s, HL7 has evolved as a very flexible standard with a documented framework for negotiation between applications. The inherent flexibility makes deploying HL7 interfaces a little more challenging at times.” (Mertz 2010).

The HL7 messages are in fact clinical information and not only collections of data used to send information about some events in some healthcare enterprise.

Originally developed in 1987, HL7 Version 2.x is now in use in more than twenty countries around the world. It contains messages for almost every conceivable healthcare application area, including the following: registration, orders (clinical and other), results and observations, queries, finance, master files and indexes, document control, scheduling and logistics, personnel administration, patient care planning, network synchronization, laboratory automation (OTech, 2007).

In order to acquire all these, the HL7 standard includes: conceptual standards: RIM (Reference Information Model), document format standards: CDA (Clinical Document Architecture), clinical application standards: CCOW: (Clinical Context Object Workgroup) and messaging standard.

But the use of intelligent agents reduces the need for knowledge about HL7 and interfaces, and thus reduces the barriers to entry for the introduction of HL7 (Long et al., 2003).

Thus, ontology-based multi-agent systems provide a framework for interactions in a distributed medical systems environment without the limitations of a more traditional client server approach (Orgun & Vu, 2006).

We consider agents (Turcu et al., 2009) that cooperate with each other in order to manage the information flow between local EMR database applications and HL7 message templates.

4.3.3. Multi-agent technology

Agent technology is an emerging and promising research area, which increasingly contributes to the development of value-added information systems for different applications. An agent is a small, autonomous or semi-autonomous software program that performs a set of specialized functions to meet a set of specific goals, and then provides its results to a customer (e.g., human end-user, another program) in a format readily acceptable by that customer (Wagner, n.d.). For example, agent technology has been applied in the area of gathering information from World Wide Web heterogenous data sources. The performance evaluation of the agent-based system versus traditional systems (client-server and relational database based systems) was undertaken by some researchers (Yamamoto & Tai 2001; El-Gamal et al. 2007). The tests reveal that the agent-based systems provide better times of response as well quicker notification processing.

Healthcare systems are characterized by a wide variety of applications working in autonomous and isolated environments. The use of agent technology in healthcare system has been increasing during the last decade. Multi-agent systems become more and more important in the field of health care as they significantly enhance our ability to model, design and build complex, distributed health care software systems (Nealon & Moreno 2003)).

4.4. SIMOPAC architecture

In the last few years, most world-wide medical bodies and healthcare units have shown an increased interest in the employment of Healthcare Information and Management Systems and Electronic Medical Records (EMRs). Nevertheless, there are still many problems to be tackled upon, such as the case when patient information is not available because the unit which is supposed to offer medical assistance does not own the patient’s medical record. Furthermore, it is imperative to eliminate the duplication of medical services (e.g. laboratory tests) so that physicians may easily obtain any patient-related information that is stored in different databases within different EMR systems. Our research team developed a distributed RFID based system for patients’ identification and monitoring, named SIMOPAC. This system enables real time identification and monitoring of a patient in a medical facility, on the base of CIP. A CIP is a passive RFID tag that is storing relevant medical information regarding its carrier. The CIP provides a quick access to the actual health state of a patient and helps the medical staff in taking the best decisions, especially in case of an emergency. Thus, the risk of administrating wrong medication is highly reduced. The system is also able to integrate and exchange information with other HL7 and even non HL7 based clinical applications already developed by other companies or organizations. The presented system provides an interface to different areas of healthcare, such as: emergency services, medical analysis services, hospital services, family medicine services, etc.

The different components of this scalable and robust distributed system are depicted in figure 1.

The Personal Electronic Health Identity Card (PIC in English, CIP in Romanian) is a prerequisite of patient identification. SIMOPAC CIPs are designed to store patient personal data, minimum general health data, as well as other vital information indispensable in emergency situations. Employing the Domain Name System (DNS), the RFID tag permits patient identification in a SN@URI format, where SN represents the tag series corresponding to the patient’s CIP. The CIPs store the following data:

1. emergency medical information (blood type, RH, allergenic substances, HIV/ AIDS and any other chronic or transmissible diseases, etc.);

2. patient ID + URI server keeping the medical chart;

3. values of 1 and 0 corresponding to a template defined within the system by the medical staff.

SIMOPAC offers reliable solutions for the distribution of patient-related information among several medical units. The system requires that all medical units own EHR/EMR information systems to store patient electronic medical records. Moreover the information systems must be compatible with 2nd version of HL7 standard. Whenever a member of the medical staff needs to consult a patient’s medical record, the multi-agent system allows the gathering of patient-related information, regardless of the patient’s location.

Related to SIMOPAC architecture we can assert that this RFID-based system includes the following main modules:

• User management;

• EMR viewer;

• Tags management;

• HL7 server.

These modules are shortly described in following subsections.

Figure 1.

SIMOPAC System Architecture

4.4.1. User management

Needless to say, security is one of the main aspects that should be taken into consideration when implementing such a distributed system. User management is a critical part of maintaining a secure system. Ineffective user and privilege management often lead many systems into being compromised (Teambusiness, n.d.).

The User Management module was designed as a generalized system that enables the management of all users and users groups within a distributed system. It consists of different modules, each of them with its own list of entities and rights.

Within the framework of SIMOPAC system, the User Management module provides the following main facilities:

• password based access to the User Management application;

• data encryption with the TripleDES algorithm for all important information transferred over the Internet and stored into the central database (e.g.: user names, passwords, access rights);

• support for different levels of access rights. This implies that users are granted different rights to the system’s features;

• management of system registered users (users visualization, adding or removing of certain users, profile modification, granting/revoking user privileges, etc.);

• modules and entities management.

Figure 2 exemplifies the process of granting/revoking user privileges for different modules and entities of the SIMOPAC system.

Figure 2.

Granting/revoking user rights

4.4.2. EMR Viewer

This module, generically named VizEMR-PC, allows patient identification based on his own CIP and displays some pre-configured information from the electronic health record of that patient. The patient identification is based on the patient’s identifier that is stored on his RFID tag and printed on the CIP. VizEMR-PC module also displays patient information in the language requested by the user.

This module can be used when the CIP is read at a medical unit and the medical staff wants to obtain more information about the patient. VizEMR-PC provides the following main facilities:

• a specialized editor that allows the design (configuration) of a report template. This template will be used for the interest information from the electronic health record of the EHR/EMR system that is integrated with SIMOPAC. The report template is created only once by skilled health personnel and contains all or only some fields of the electronic medical/health record. This template can then be translated into several foreign languages in order to facilitate cooperation between medical units from different countries and assure a good care for a patient from another country.

• a report generator that will be responsible with the completion of the following tasks:

• filling the report template fields with information taken from the electronic medical/health record of a patient by using HL7 dedicated commands;

• generating a custom report in different formats (XML, CVS, MDB, etc.), using the language specified by the user.

In order to have access to VizEMR facilities, authorized users must first login to the application by entering their username/password. The client-server communication is secure; all the passwords that are sent over the Internet are first encrypted on the client-side. Also, the access to various facilities offered by VizEMR-PC is granted in accordance to the rights previously set for the registered user. Access rights are established by the User Management module.

4.4.3. Template management

This component of SIMOPAC system is mainly focused on the designing of the templates used for information structuring on patients’ CIP sheet and stored on a Web server. The patient’s CIP sheet contains two different areas, each of them storing specific information about the patient. The first one contains clear-text information that is needed especially in emergency situations. This information uniquely identifies a patient and specifies if he/she is suffering from any serious illnesses. The second section of the CIP contains data that can be interpreted only with the same template that was used for writing the information into the RFID tag. This template will be available for download at an URL written on the CIP. The medical staff can have quick access to the information written on the CIP by downloading (from the same URL address) a specialized add-on application that is mainly used to communicate with the RFID reader. Moreover, the medical staff can obtain a translation of this information, if it has been previously translated by the person created the template and the CIP sheet. This translation, available in an XML format, could be easily transferred and read. On the base of these templates, the medical staff can create the CIP sheet that corresponds to one or more patients.

One of the main advantages of template based information structuring is the fact that in order to be included on the CIP, information is translated only once. Other advantages are listed below:

• the use of a single template for a specific target group (because everyone will have the same type of data included in the CIP);

• allows a better organization of data to be included on the CIP.

A template consists of a list of user defined fields. Each field is defined by name and data type. The basic data types are shown in figure 3, to which more types can easily be added.

Figure 3.

Common data types

As seen in figure 3, each data type has been associated with a display format that will be used by a plug-in module for the correct displaying of the information stored on the CIP. The display format can be interpreted as follows:

• (A/_) - letters (A. … Z) and other displayable ASCII characters;

• [+-](0...9) – the symbol + or - (optional), followed by digits;

• [+-](0...9)[.(0...9)] – the symbol + or - (optional), followed by digits. The decimal point is optional and it is used for floating point numbers representation;

• yyyy-mm-dd – standard representation of dates (y - year, m - month, d - day);

• hh/mm/ss – standard representation of time (hh - hour, mm - minutes, ss - seconds);

• yyyy-mm-dd hh/mm/ss – standard representation of date-time values.

When the system contains at least one CIP sheet associated with a particular template, the template cannot be edited anymore, but another one could be built on the base of the first one. After building the template, the next phase is the translation of the fields; this translation will be saved in an XML format and then stored into the central database. There is no restriction related to the number of translations that can be done. When a doctor consults a patient's CIP sheet, he is granted access to the structured information as well. Regarding to the translation of the template's fields, the medical staff can choose between an automated translation (performed by the plug-in application, based on localization) and a translation that was downloaded once with the template associated to the patient's CIP sheet (see figure 4).

Figure 4.

SIMOPAC – CIP sheet

The template is automatically accessed through the add-on module downloadable from the official site of the SIMOPAC system. The URL is printed on the label of the RFID tag (see figure 5). After being downloaded and launched, the add-on module will perform the following actions:

• tries to find an RFID reader recognized by the system;

• if such a reader has been found, the add-on module accesses the SIMOPAC's database and downloads the template and its translation;

• based on this information and using the localizing function, the add-on displays the translated template filled with all data extracted from the patient’s CIP (local RFID tag);

• after patient investigation, the add-on module sends all the results/findings to the logs' area of the SIMOPAC server.

Figure 5.

An example of printed label of a patient’s CIP

The filling-in of the patient's CIP sheet, along with the creation/administration of the template(s) is to be performed by the treating doctor. If the medical unit does not use such an EMR system, it is still possible to use the SIMOPAC system, but without the facilities of an EMR system (e.g.: direct import of patients' related data).

Generally, the memory space on RFID tags is limited to about 1-2 Kbytes. Thus, an efficient data compression method is needed when working with large amount of data. In order to reduce the amount of memory needed to store the structured information on RFID tags, we have designed and developed several techniques of data representation, as follows:

• representation of Floating point/Integer numbers on subintervals [a, b], with step specified. This achieves a reduction in the number of bits needed for representation;

• representation of Date, Time and DateTime values by setting the startup date/time value;

• specifying the list of possible values for the fields using small sets of values;

• Huffman encoding of fields that frequently use the same numerical values.

When representing numerical values on subintervals, the template will store some additional information, as a 3-tuple (left borderline, number of values, [step]). If the distance between two consecutive values is different from 1, then it must be specified in the template, in the optional section [step] (see figure 6).

Figure 6.

Internal representation for floating point/integer numbers

When working with a Date field, the user can specify (in the template) the date from which the actual encoding within that field begins. Thus, the value 0000 corresponds to the start date. This start date will be specified as a 3-tuple (year, [month] [day]), year being the only mandatory. If month is missing, it is assumed to be January. When day is missing, it is assumed to be the first day of the month. The value stored in such a field represents the number of days elapsed from the start date (see figure 7). Time fields will be handled in a similar manner. The value stored in such a field represents the number of seconds elapsed from the start date (see figure 8).

Figure 7.

Internal representation of date values

Figure 8.

Internal representation of time values

Huffman coding, a variable-length coding method, was used to allow a substantial compression ratio of the data encrypted on the RFID tag. Thus, certain fields encode information such as "diseases" and some of them may occur more often on patients' tags than others. Figure 9 presents an example of a Huffman coding tree.

Figure 9.

Coding tree

4.4.4. HL7 portal

Our research team designed and developed a HL7 portal to integrate the SIMOPAC system with other clinical applications/systems already developed by other companies or organizations. Thus, the main purpose of this server is to acquire clinical data about patients (from different servers and applications) by using the HL7 messaging protocol. Within the framework of SIMOPAC system, the HL7 server will be primarily used to obtain the EMR of a patient that was identified by his RFID tag. There are two different ways of getting clinical data (Cerlinca et al., 2010):

• using the standard HL7 messaging protocol our HL7 Messaging Server connects to a list of medical applications and requests patient’s related data;

• using simple and intuitive ASCII commands any non-HL7 application can connect to the Messaging Server and request data about a patient.

The main objective of the HL7 portal is to ensure safe and standardized communication between aware and non-aware HL7 applications and SIMOPAC system modules (Figure 10). Other objectives that we had to accomplish are:

• easy integration with other modules of the system such as: plug-ins, PDA software, software agents;

• compatibility with Linux, Windows 7/XP/2000 and Windows Mobile operating systems;

• secure data exchange using HL7 CCOW standard authentication and encryption algorithms.

Figure 10.

HL7 Portal integration

The HL7 Portal should provide a secure and sustained flow of medical data between various system modules, regardless of whether they support or not the messaging standard. The modules we developed for this portal are (Figure 11):

• Medical Data serving module: HL7 V2/3 messaging which provides standardized communication between system’s modules and also with external medical software applications. This module can be integrated anywhere HL7 data messaging is used. The design and the implementation of this sub-module are compatible with Windows 7/XP/2000, Linux and Windows Mobile operating systems. Also it will provide, if and when needed, additional clinical information, other than the one stored on the RFID tag;

• Authentication and data encryption according to HL7 CCOW, and providing the necessary confidentiality elements regarding the flow of medical data. This sub-module works only with HL7-aware applications;

• Login and transfer module that uses HL7 V2 messaging in order to transfer clinical data between external HL7 servers and SIMOPAC applications. This method involves creating a TCP/IP socket connection that will connect to another socket (IP address: port) on a server, and providing thus the medical data flow. Typical connection used is HL7 LLP (Low Layer Protocol);

• Data interpretation and translation module, the core of the entire portal;

• Encryption key management which keeps and distributes all keys inside our software system; it also provides safe exchange of keys between the system’s modules. Furthermore, this sub-module keeps and distributes authentication and encryption algorithms types used by every module and by each partner module/external application.

Figure 11.

HL7 Portal Architecture

HL7 Portal Facilities

The main requests covered by the HL7 Portal are:

• compatibility with Windows 7/XP/2000 and Linux operating systems;

• use of HL7 connection and authentication standards;

• acquiring clinical data regarding patients by using safe HL7 connections;

• encrypted exchange of data in all cases;

• translation of HL7 formatted data as close as possible to the natural language;

• the system architecture enables translation from/in an unlimited set of languages, as long as standard ASCII characters are used;

• ensuring connection to and authentication of an unlimited number of concurrent client applications requiring patient information from HL7 medical data servers;

• supported command set designed to provide complete support for gathering relevant medical data;

• storage of all connections, received commands and answers in an encrypted log file.

A language barrier between patients and healthcare providers is a major obstacle in providing quality care, according to (Bischoff et al., 2003).

The elements of originality of the HL7 portal are:

1. Translation of HL7 messages parts in various foreign languages;

2. Enabling partial interpretation and translation of data from HL7 segments from and in any language;

3. Providing a simple mechanism to add new languages for data interpretation;

4. Providing means to obtain and process HL7 format data into non-HL7 applications;

5. There is no other portal that has the same functionalities as the SIMOPAC portal, designed and developed by our research team.

Even if our main goal was to provide a solution for healthcare language issues, there are some aspects that our system, in its current state, cannot solve: translation of descriptive fields, translation of doctor observations, etc. To this extent, more research is needed on EMR translation systems.

4.4.5. Data interpretation and translation module

This module provides the following features:

• allows the interpretation of clinical data in different languages;

• allows users to customize interpreted messages;

• new languages can be dynamically added and then used for data interpretation;

• executes commands received from client applications, and returns the corresponding clinical data, if any;

• allows connections from an unlimited number of clients.

In order for this module to be fully functional, the following steps must be completed:

• read the languages.txt file that contains all supported languages;

• read all files used in data interpretation in different spoken languages and data initialization for each of these languages (Figure 12);

• create a TCP/IP server socket for the connection of potential external application;

• wait for connections and create one server socket for each client;

• reply to each client for received messages and return requested data using the appropriate foreign language;

• disconnect the client on request and close the corresponding thread/socket pair.

The languages.txt file is used in order to find out the available interpretation languages. Thus, this file contains all available interpretation languages identified by name and also indicates the associated language abbreviation used to find specific files. For example, the languages.txt file can contain: English (en), Francais (fr), Romana (ro).

The files needed to interpret clinical data in English are:

1. HL7 specific messages files: EVN.en, MRG.en, MSA.en, MSH.en, MSH-EventType.en, MSH-MessageType.en, OBR.en, OBX.en, ORC.en, PID.en, PV1.en, QAK.en, QPD.en, RCP.en, ZDS.en.

We choose these file names because we needed to interpret the most used HL7 messages:

1. MSH (Message header);

2. MSA (Message Acknowledgement);

3. OBX (Observation);

4. OBR (Observation Request);

5. EVN (Event Type);

6. PID (Patient Identification);

7. PV1 (Patient Visit),

9. Files with translated error messages: -none-.en,

10. files not found-.en, -not present-.en.

Table 1 presents the command set for English and the corresponding returned values.

Figure 12.

Module initialization by reading languages files

English Command	Returns
login(IP, port, user, password)	command sent by the client in order to connect through the portal to a HL7 server; OK if successful or NOK if the connection failed;
usePatient(SSN, language)	command that will set the current patient; all subsequent commands from the current client will receive data on this patient; OK if successful or NOK if the connection failed;
getExternalID()	external identifier associated with the current patient (external to HL7 application questioned); none if there is no external ID;
getInternalID()	internal identifier associated with the current patient (internal on HL7 application questioned); none if there is no internal ID;
getAlternateID()	alternative identifier associated with the current patient (alternate to HL7 application questioned), etc.; none if there is no alternate ID.
getName()	returns the name of current patient;
getMotherMaidenName()	returns the patient’s mother maiden name, this may be important in order to get all information about family health history. Also may be used to distinguish between patients with the same last name.

Table 1.

Command set for the English languages

This solution facilitates the addition of a new language support. The interpreter has to follow these steps:

1. 1.adding a new line in the languages.txt file (e.g. Espanol (es));

2. 2.creating the following files:

3. a.–files not found-.es, file with the following content: “!Archivos no encontrados! !Elija por favor otra lengua!”,

4. b.-none-.es file with the following content: “Ningunos”,

5. c.-not present-.es file with the following content: “No presente”;

6. 3.translation into Spanish of all HL7 specific files.

The data will be interpreted once commands are received from external applications.

Testing

In order to test the module, we developed a prototype for a generic client that executes all the commands described in the previous section. HL7 portal runs on a Linux machine, while the client is using a Windows platform. For testing the HL7 portal, we used three different applications, compatible with the HL7 standard: PatientOS, AccuMed EMR and the Mirth HL7 messaging server.

All tests proved that our system complies with the specified requirements and can be successfully used to provide accurate health information in different spoken languages.

From the performance point of view, our design and implementation meets all requirements of typical client/server software systems. Performance testing proves that there are no significant delays and the server response time is more than acceptable.

4.5. SIMOPAC novelties and benefits

SIMOPAC proposes a novel approach in patient identification and ensures the interoperability of HL7 medical information systems. Its implementation does not require any change in or re-design of existent information systems. SIMOPAC can easily integrate any other existing solutions in today’s medical establishments and provides a reliable way of identifying patients by using the latest RFID technology. Allowing the integration of other current technical solutions available in today’s medical units, SIMOPAC contributes to a considerable reduction of implementation costs. It also eliminates the import of patients’ electronic medical records into other EMR systems. Furthermore, the members of the medical staff do not need to be trained how to use the information system in order to store their patients’ medical records.

SIMOPAC permits the interoperability of medical information systems at an international level and especially among EU countries, irrespective of their centralized or decentralized health system organization:

1. when a traveling citizen gets sick in some other EU country and requires an emergency service;

2. when a citizen travels to an EU member state in order to benefit from some requested medical service available in the visited country;

3. when diagnostic requests are electronically posted by individual citizens or by members of the medical staff in real-time store-and-forward telemedicine.

Since SIMOPAC does not substitute the existent information systems, it represents a viable solution for the reduction of costs involved in acquiring infrastructure components of medical information system and services. Economically, the level of interoperable health information-exchange among medical institutions is expected to reach considerable values. The actual increase of international medical contacts and the real need to exchange patient-related information in cross-border contexts pave the way towards the implementation of such systems.

SIMOPAC offers the following major benefits:

1. clinical benefits:

2. the members of the medical staff can securely access medical data stored in patients' electronic records;

3. the patients’ health histories are made available to authorized staff;

4. the members of the medical staff can better coordinate the provision of health services by providing accurate information about their patients’ health, the history of their medical visits at any time and in any location where the system is operational;

5. the system stores and distributes upon request a whole-range of patient-related information;

6. patient-related data can be obtained on-line;

7. the paper consumption for keeping hardcopy documents may be considerably reduced or eliminated;

8. the system reduces medical errors and increases patient safety.

9. administrative benefits:

10. on-line access to information;

11. efficient management of medical information;

12. health care providers may be connected internally and externally;

13. the system eliminates the need to re-register patients and keep multiple healthcare records in several medical information systems.

5. Conclusion

Many errors in health care relate to lack of availability of important patient information. The use of information technology (IT) and electronic medical records (EMR) holds promise in improving the quality of information transfer and is essential to patient safety (Bates & Gawande, 2003). While the adoption of Information Technology in individual medical institutions is growing rapidly, interoperability is still a major challenge, and reaching agreement over the appropriate approach to a national EHR system has proved difficult. Thus, despite the fact that most hospitals store patient electronic medical information, these data cannot be easily shared among all healthcare systems because of its discordant formats.

The continuous decrease of costs in RFID technology will soon enforce its use in everyday life. In this chapter, we have focused on the RFID technology and how it could be used in emergency care in order to identify patients and to achieve real time information concerning the patients’ biometric data, which might be used at different points of the health system (laboratory, family physician, etc.).

Also, this chapter describes an RFID-based system (named SIMOPAC) that integrates RFID and multi-agent technologies in health care in order to make patient emergency care as more efficient and risk-free, by providing doctors with as much information about a patient as quickly as possible. The proposed RFID-based system could be used to ensure the positive patient identification (PPI) in a hospital. The SIMOPAC goal is to extend the procedure of patient identification beyond the hospital and country boundaries. Thus, our RFID-based system could be considered an open-loop RFID application, functioning across global hospital boundaries. The CIP will allow the identification of patients, and this RFID card will provide access to an ambulatory EMR, namely a data repository devised as a subset of a longitudinal health record. Furthermore, the CIP could be used to allow physicians to connect to the SIMOPAC server. In order to link patient identifiers to patient information, the SN@URI approach has been proposed, SN being the CIP serial number.

The interaction of the afore mentioned system with another full EMR system will assure optimal integration. The HL7 server we have designed and developed can be used to obtain the EMR of a patient that was identified on the base of his RFID tag. Clinical data can be acquired from different servers and applications. In addition, any non-HL7 application can connect to our HL7 server and request data about a patient. Our system is able to integrate and exchange information with other HL7 and even non-HL7 based clinical applications already developed by other companies or organizations. Using multi-agent technology reduces the need for knowledge about HL7 and interfaces.

Through the use of tag templates that can be translated into several foreign languages our system facilitates the cooperation between medical units from different countries in order to assure a good care for a patient from another country.

Every hospital could use SIMOPAC with their existing system in order to promote patient safety and optimize hospital workflow. We have described a general purpose architecture and data model that is designed for both collecting ambulatory data from various existing devices and systems, and storing clinically significant information in order to be accessed by the emergency care physician. The SIMOPAC complexity is further amplified by the fact that most individual electronic health record systems are packaged products supplied by a variety of independent software providers and run on different platforms.

Through the use of the RFID technology, the system we have developed is able to reduce medical errors, improve the patients’ overall safety and enhance the quality of medical services in hospitals and other medical institutions. For example, the risk of administrating wrong medication in case of emergency is highly reduced.

Our future research will focus on the development of various software modules that will use the medical information collected via RFID in order to optimize the patients’ treatment process.

Acknowledgments

This work was supported in part by the Romanian Ministry of Education and Research under Grant named “SIMOPAC – Integrated System for the Identification and Monitoring of Patients” no. 11-011/2007.