Proof-of-concept Design and Development of an EN13606-based Electronic Health Care Record Service

Abstract

Objective

The authors present an Electronic Healthcare Record (EHR) server, designed and developed as a proof of concept of the revised prEN13606:2005 European standard concerning EHR communications.

Methods

The development of the server includes five modules: the libraries for the management of the standard reference model, for the demographic package and for the data types; the permanent storage module, built on a relational database; two communication interfaces through which the clients can send information or make queries; the XML (eXtensible Markup Language) process module; and the tools for the validation of the extracts managed, implemented on a defined XML-Schema.

Results

The server was subjected to four phases of trials, the first three with ad hoc test data and processes to ensure that each of the modules complied with its specifications and that the interaction between them provided the expected functionalities. The fourth used real extracts generated by other research groups for the additional purpose of testing the validity of the standard in real-world scenarios.

Conclusion

The acceptable performance of the server has made it possible to include it as a middleware service in a platform for the out-of-hospital follow-up and monitoring of patients with chronic heart disease which, at the present time, supports pilot projects and clinical trials for the evaluation of eHealth services.

Introduction

The need for semantically interoperable electronic health care records (EHR) is now a well-established tenet. ^1–4 Integrated care is an organizational principle encompassing continuity of care, shared care, and seamless care that is currently the basis of health care provision. ⁵ However, aspects such as the marked mobility of the population (changes of residence, job changes, tourism) and its demand to have access to services (including health care) of similar quality to those of their place of origin are factors that set in motion the creation of information systems based on interoperable EHR. ⁶ This cannot be done properly if the information systems are not capable of transferring information in such a way that it conserves its full significance, both clinical and contextual.

Traditionally, the development of information systems has been carried out following methodologies that we would call a single modeling level, in which the domain concepts are hard-coded directly into the software and its database models. Although this type of approximation allows for rapid development, when it is applied to environments characterized by the high degree of complexity of the concepts that are managed and their high speed of change, information systems are generated that need frequent and expensive updates which, if not carried out, will terminate the systems because they have become obsolete. ⁷ For example, clinical knowledge could define that a measurement of arterial pressure in a patient is made up of two values: systolic and diastolic. An approximation at the time of developing an information system to store the BP measurements could implement a table in the database with two columns in order to save these values (the knowledge has been entered in order to form part of the database data models used directly). The system thus created could work correctly for a time, but if later research concludes that it is necessary to also save the position of the patient at the time of the measurement (a change in the knowledge that carries with it a change in this domain concept), the system will not be able to do so, as it will need an update. Another problem that can occur with these approximations is that their interoperability is limited to the model that the developers have followed in each system.

The achievement of the objective of interoperability, therefore, will require, at least, the standardization of the communication of partial/entire EHRs between systems. HL7, ⁸ CEN, ⁹ and openEHR ¹⁰ normalization entities have been working for some time toward this aim and collaborating actively to achieve a certain minimum of convergence. ¹¹ Crossmappings are being carried out to enable the interchange of EHR data between its implementations; in addition, Part 5 of EN13606 includes a Domain Message Information Model HL7 (D-MIM) corresponding to its reference model.

This article describes the design and development of an EHR server compatible with the revised EN13606 standard, according to its paradigms: separation of points of view, ¹² separation of responsibilities, ¹³ and a dual-approach model (of information and knowledge), established by openEHR, ¹⁴ that seek to protect information systems from domain changes.

The initial aim was to create a prototype to test concepts included in the standard for use in demonstrations and training, without dealing with performance parameters of the server. The good results obtained have made it possible to carry out trials in a real-world scenario, on a platform for the out-of-hospital follow-up of patients with chronic heart disease.

Background

The aim of the EN13606 European Standard is to normalize the transfer of information between EHRs systems in an interoperable fashion, without specifying how to implement them.

The EHRCom Task Force, from within Working Group 1 of the 251—Health Informatics—Technical Committee of the European Committee for Standardization (CEN) has been put in charge of its drawing up, following the current paradigms in the creation of the standards:

• • Separation of responsibilities: the really complex systems can only be dealt with if their functional nature is divided into parts or subsystems, becoming what Maier calls a “System of Systems.”¹³ Each of these systems must have a well-defined responsibility (scope) in such a way that the dependency between them is low and can be reused. One of the best contributions in this section is the work of the Object Management Group/Healthcare Domain Task Force (OMG/HDTF).¹⁵ which has defined a series of services (subsystems) and interfaces for the health domain (EHR, security, identification, work flow, terminology, etc.). The EN13606 standard defines the EHRs transfer system.

• • Separation of points of view: every standard can be described following the ISO Reference Model standard for Distributed Processing in Open Systems (ISO RM/ODP),¹² which defines five points of view for distinguishing different aspects of the distributed systems: business (business activities), information (semantic of the information that will be processed by the system), computation (describes the system as a set of objects that interact through their interfaces), engineering (including the mechanisms that support the distribution), technology (description of the components that make up the system). As a consequence of this paradigm, the systems will be described in terms of the different points of view. The EN13606 standard deals with information. Another CEN standard (pr EN12967-3 HISA),¹⁶ deals with the computation point of view (defining the interfaces) in Part 3.

• • Separation of information and knowledge: within a domain, knowledge can be defined as the set of facts that has been put together over time, coming from many sources, and which is true for all of the entities of this domain, for example, “The atrial septum separates the left and right auricles of the human heart.” Information is made up of the facts or opinions collected or related to the specific entities, for example, “John Doe has a defect in the atrial septum.” When information is represented in a form suitable for processing by a computer, it is called data.

The greatest change in the design strategy of the standards has been caused mainly by the third paradigm, the separation of information and knowledge. The majority of the classic strategies, independently of the methodology used (object oriented, E/R, etc.) mixes both kinds of semantic together into a single model. Normally, the developer and the specialist of the domain identify the concepts of the domain and create a model from which the system is designed. In areas in which knowledge changes rapidly, such as clinical settings, this approximation is unsatisfactory—not only because the difficulty means that people with very different training have to collaborate—but also because these changes in knowledge make it necessary to modify the single model. These modifications have to be implemented in the system to prevent it becoming obsolete, which means very complex systems that are expensive to maintain. The information/knowledge separation gives rise to two differentiated concepts: a small set of generic concepts, the grammar of the domain, managed by the developer; and a large number of domain concepts which are understood and described by their specialists. The work of both groups of people can become independent, thus obtaining a small, generic reference model not liable to change that, managing information concepts, will serve as a basis for the development of the system and a knowledge model, which will manage its concepts.

With these premises, the EHRCom Task Force revised the ENV13606 pre-standard in order to draw up the EN13606 standard. The standard is made up of five parts:

• 1 Reference model:¹⁷ This models the stable characteristics of the patient register and how it is organized hierarchically, defining the necessary classes in order to manage both the clinical information and that of its context.

• 2 Specification for the exchange of archetypes:¹⁸ It includes the generic information model and the language for the representation and communication of the definitions of individual instances of archetypes. It follows the approximation drawn up by the openEHR group. It is compatible with the specification of HL7 templates.

• 3 Archetype reference and list of terms: They contain the initial set of archetypes for Europe, as well as the specification of their repository. They also define the list of relevant terms (both regulatory and informative) necessary for other parts of this standard (for example, for certain attributes in Part 1).

• 4 Security characteristics: These specify the measures necessary for the control of access to information, the consent and register of the communications activity.

• 5 Exchange models: Messages and interface services which allow the communication of EHR extracts and archetypes.

The reference model (the equivalent to HL7 CDA) ¹⁹ represents the general features of the components of the health record, how they are organized, and the context information needed to satisfy both the ethical and legal requirements of the record. The model defines the set of classes that makes up the blocks that constitute the record, that is, it encompasses its stable features. However, in order to achieve interoperability, a model like this should be complemented in the knowledge domain by a formal method for transmitting and sharing structures of predefined classes, agreed upon by a community, corresponding to fragments of the record created in specific clinical situations: the archetypes.

An archetype is the definition of a hierarchical combination of components of the reference model, which restrict it (giving the names, possible types of data, default values, cardinality, etc.), to model clinical concepts of the knowledge domain. These structures, although sufficiently stable, may be modified or substituted by others as clinical practice evolves.

An analogy used to explain the working of the double model is that of a LEGO® construction game. ¹⁴ In this analogy, the reference model would be equivalent to the technical specifications of the construction blocks and the mechanisms for connecting them. By putting the blocks together, we can carry out a multitude of legal constructions from the point of view of these specifications, although only some of them seem to be somewhat of the real world; that is, they have meaning. We can also use plans that describe certain constructions, such as houses, cars, or animals, which are taken as models in order to connect the blocks (these plans would be equivalent to archetypes). Over time we can come up with new plans (use new archetypes to define new domain concepts) or, even, to make changes to existing plans in order to accommodate them to our needs or to adjust them to the real world (to create new versions of existing archetypes in order to represent the changes brought about in the domain concepts). However, in all cases, the constructions are carried out with the same blocks and respecting the initial specifications (the reference model), which will not change. Equally, building an information system based on the reference model has the security of knowing that no modifications will be necessary although the domain concepts of the knowledge may change. It will only have to work with different archetypes.

As has already been stated, the EN13606 standard regulates the EHR transfer (or a part of it) corresponding to a patient. Whenever it is sent, the information to be transmitted will be organized, following the specification of the reference model, in an extract (EHR_EXTRACT) (▶), which will be incorporated in a message, and therefore the extract is the transmission unit. Within the extract, the clinical information is organized as follows (▶): The extract contains a set of compositions (information on a subject gathered during a visit, a report, etc.) that include version information to make it possible to reconstruct the history of the data. The compositions store entries (entry) that are simple statements concerning observations, evaluations, or instructions that can be grouped into sections to represent the internal organization of the documents, as occurs with the document headings. Finally, the entries contain elements, in each of which a specific datum is stored. The elements can be grouped into clusters to represent more complex data structures, such as time series or tables. The standard provides an additional high level of organization that makes it possible to group the compositions into folders in order to enable the reproduction of the organizational criteria of each center (according to episode, service, visit, etc.). The clinical information is accompanied by another type of context information in order to enhance its significance or meet legal requirements. Thus, any component can contain information on who provided it (audit_info), can be signed (attestation_info), or can be linked to other components (link), in order to express cause–effect, problem–solution relationships, etc. Information on the setting in which an activity is carried out (attributes included in composition), who participated in it (functional_role), or whether the information refers to the patient or to another entity (related_party) is also collected.

Figure 1.

EN13606 reference model. UML notation. (Extracted from ¹⁶ .)

Figure 2.

Blocks of an EHR_EXTRACT example.

There are different types of archetypes depending on the structures of the reference model being modeled:

• • Primary archetypes: They model the basic concepts of the knowledge domain (blood pressure, weight, etc.) for which they become entries within the reference model. These archetypes are necessary in order to achieve the semantic interoperability, for which they form part of the repositories that allow them to be shared by all of the communicating entities.

• • Organizational archetypes: They model more complex concepts than the primary ones (abdominal examination, blood test, etc.), usually built by uniting and restricting them and being, to a certain extent, dependant on the organization that they use. Their main task is to help in navigating through the information. They correspond to the section structure of the reference model and are not strictly necessary to achieve the semantic interoperability, although they help in this objective.

• • Templates: They model the documents used in a certain organization (operation report, patient visit, etc.) and are built by uniting and restricting archetypes of the previous types. They are used to build automatically, for example, forms for the introduction of data by the user or the drawing up of reports. They correspond to the compositions of the reference model.

A typical scenario of use is a follows:

—After the patient is seen at a health center, the information generated is introduced into the system for storage in the EHR of the patient. Using the suitable template itself (which will have been built using archetypes from a common repository), a form will be generated in which the clinical user will write the necessary data. This introduction of data into the system is a task that could turn out to be very laborious due to the large quantity of information that has to be entered. The use of a template facilitates this task greatly, since a lot of this information is included in it (the structure of the data, the name and meaning of attributes, the units in which the measurement has been taken, default values, …), thus, the user does not have to enter it. This information will remain stored in the information system of the center using its particular architecture.

—When it is necessary to transfer the information relative to a patient to another center, it is extracted from the information system and encoded in an extract following the EN13606 standard. The extract created will not contain archetypes, but an identifier that will allow the location, within a repository, of the archetypes that were used (i.e., that were included in the template used) in the creation of the information and that, therefore, model the concepts included in the information transferred. This extract will be embedded into a message and sent on the destination system, where the received extract will be decoded and the information stored according to its own architecture.

—In order to consult the information stored relative to a certain clinical concept, the system will be able to go, whenever necessary, to the repository of archetypes to identify which of them models the said concept and, from this information, put together the suitable questions that are extracted from the information storage system referring to the domain concepts sought. Using the templates themselves, the system will be able to build the required computer screens in order to present the said information to the user.

The development of the server presented here was carried out within the framework of the FIS RG03/117 research project entitled “New models of healthcare services using Telemedicine.” ²⁰ The broad objectives of this project covered from the modeling of the new services to the implementation of guidelines and protocols for their introduction and evaluation, including the development of a technological platform that would serve as a basis for them. The core of this platform (▶), based on a middleware philosophy, is the EHR server, compatible with European standard EN13606, to which the rest of the modules and applications that need to store or read information in/from the patient history are connected, from controllers of devices in the homes of the patients, to information systems (not compatible with the standard) presently existing in the centers.

Figure 3.

Technological platform architecture.

Design Objectives

The general objective of this project was the implementation of an interoperable EHR server compatible with standard EN13606 that would serve as a demonstrator of its capabilities. The specifics of this main objective were defined in terms of the following partial objectives:

• 1 To test the capacity of the standard to address the semantic needs of the real-world setting; that is, to ensure that it provides structures that make it possible to work with the full significance of the information that is dealt with in the clinical setting. To enable this, the server has to be capable of working with the classes of the extract, of the demographic package, and of the data types defined in the TS14796²¹ technical specification, which are those managed by the former.

• 2 To maximize the possibilities of connection on the part of the clients. The server forms part of an architecture developed with a middleware philosophy. The different modules that wish to communicate with it may have been developed using different communications technologies.

• 3 To create tools that make it possible to verify compliance with the standard of the extracts managed. This objective not only involves the server, but the clients as well. Given the complexity that an extract can exhibit in the server, it would be appropriate to be able to exclude an erroneous one before it is processed. This would not only save on processing time, but would avoid possible problems with the corruption of the information in the database. And for the clients, especially at the beginning, it might prove very helpful to have some mechanism that enables them to verify the validity of the extracts they generate.

• 4 To minimize the impact that changes in the setting may have on the implementation of the server. The main reason for including this objective is the fact that during the development (and now, at the time of this writing), the specification of standard EN13606 had not been completed (although it is at a very advanced stage, especially with regard to the reference models and archetypes); thus, changes that will have to be transferred to the server may arise.

• 5 Given that this development focuses on proof of concept, the performance of the server in terms of storage was not considered a crucial aspect at the time of its design; however, a simple way of changing the storage system must be envisaged.

System Description

After the appropriate study of the state of the art to determine which technological solutions were most suitable for the different parts of our server, it was decided to use Eiffel and Java (for the Web Services interface) as the programming languages, ODBC (Open DataBase Connectivity) databases as the storage system, CORBA (Common Object Request Broker Architecture) and Web Services for communications between remote machines, and SAX (Simple Api for XML) for the process of XML documents.

Eiffel ²² is an object-oriented programming language whose characteristics (multiple inheritance, design by contract, strict typing) make it ideal for the implementation of the service. Moreover, Eiffel offers the development tools and libraries necessary for creating the server. Some of these libraries, such as Gobo ²³ and e-POSIX, ²⁴ are of a general nature and others, like the mico-e library, ²⁵ which is an implementation of CORBA expressly for Eiffel, are more specific.

CORBA is a standard for the communication of objects between remote machines, via heterogeneous networks, and between terminals working with different platforms and programming languages. CORBA establishes a common mode of communicating by means of its interface definition language (IDL). Moreover, the CORBA technology includes the prior definition of a series of services that provide support for different tasks that are common in the health care setting, such as patient identification, terminology repository, security, etc. This set of services was initially referred to as CORBAMED, after which it came to be called HDTF (HealthCare Domain Task Force), ¹⁵ and it provides a series of advantages for the development of medical applications under CORBA.

Web Services is a technology for the interoperability of distributed services that was introduced in 1999 and has recently become very widely used. Based on W3C standards (the Internet is their natural operating environment), they emerge because of the need to standardize communication between different platforms and programming languages. Web Services creates services and publishes their descriptions (written in WSDL-Web Services Description Language) in public registries (UDDI—Universal Description, Discovery and Integration), thus making them available to clients. Axis, ²⁶ a Java library used in its development, provides the low-level layer of Web Services and allows programming at a higher level. In order to avoid problems with the corporate security policy, SOAP (Simple Object Access Protocol) on HTTP has been chosen as the communications protocol. In the machine that houses the EHR server, it was necessary to install an application server (Jakarta Tomcat 5) that runs on a Web server (Apache 2 was used in this case).

SAX ²⁷ is the technology chosen for the extraction of the information from the XML files since it permits its dynamic process, a circumstance that increases the processing speed and reduces the memory requirements. Its greatest disadvantage, when compared with other technologies such as DOM (Document Object Model), ²⁸ is that it does not allow the modification of the file; however, this was not a design requirement. The SAX implementation used is provided by Gobo in its freeware XML library.

The development of the server was divided into several modules (▶) that address different functional requirements. Since the modules are independent of one another, the modification of one of them does not create problems in its integration with the others.

Figure 4.

Block diagram.

Standard EN13606 Libraries

The main module of the server is the representation of the EHR according to the standard EN13606 reference model. For this purpose, three different libraries (which are also defined separately in the standards) have been developed in Eiffel: one to represent the reference model, another for the demographic package, and the third for the data types. The first library to be developed was that of the data types, in accordance with the TS 14796 European specification, ²¹ since the reference model and demographic model classes contain fields or variables of this library. Subsequently, the demographic package was developed and, finally, the library that represents the reference model classes, which makes use of the other two libraries.

The bases were the UML diagrams of the reference model, the demographic package, and the data types. These were used to generate an Eiffel class for each of the classes that appeared in each diagram. All these classes inherit from an abstract class referred to as BASE_. This class contains an attribute called key (string data type), which is a unique identifier of each of the objects. This identifier is created from the instant in which a given object was generated and from the type of the object, which is added to a unique identifier of each system, based on its IP address, to ensure that there are no two identical identifiers, either in the data pertaining to this system or in the information received from another system.

The demographic data of the entities present in the EHR extract do not appear in the extract for reasons of security, but are referenced by a unique identifier. These data, however, may be necessary in certain cases; thus, the standard offers the possibility of including them in separate structures, defining a demographic package. The library developed to support this package represents all the classes of a demographic server.

The library of the reference model was the last to be developed since it uses the demographic library in the IDENTIFIED_ENTITY class and the data types in all its classes. This library represents all the classes of the reference model, their relationships, and restrictions.

Permanent Storage

The permanent storage with which the server is equipped is a relational database with an ODBC interface, which guarantees that it can be implanted in more powerful, external machines, when necessary. In this database, each class is represented by a table, both for the types of data and for the demographic classes or the extract. The relationships between them are implemented in the unique key created by the BASE_ class described above.

Verification

In order to avoid later errors it is necessary to carry out a verification of the XML files before processing them. A set of XML-Schemas have been implemented for this that follow the same structure as the libraries for managing the data, that is, they are divided into types of data, demographic packet, and extract. The XML-Schemas are files written in XML that show the format (field names, cardinality, attribute types, etc.) that must have a certain type of XML document.

XML Processing

The passage of the EHR information of the XML extracts (utilized in the communication in accordance with the standard) to the Eiffel objects in accordance with the reference model is not trivial; this task is carried out by the parsing module of the XML documents. The transformation of the information should be possible in both directions: from XML files to Eiffel objects and vice versa. The first case is the most problematic and requires the use of a specific XML processing technology (SAX from the Gobo library). The SAX implementation is based on event-handling functions (beginning and end of the document, start and end tag, closing element and element content tag) and a flow to be processed, which, in this case, is the file received. The aforementioned event-handling functions are what make it possible to carry out a dynamic process of the file received. The second case is simpler and the transformation is carried out via calls to a function referred to as to_xml that is implemented by all the descendents of BASE_, which is called recursively.

Communications

The CORBA interface was based on mico-e, an implementation of CORBA in the Eiffel language freely distributed. The EHR server registers its service in the names server with the name “SV-EHR-13606” and publishes the functions that it makes available to the clients, by means of a file written in IDL, who have to compile it and introduce it into their systems. ▶ provides a detailed description of the currently available functions for the server via CORBA with their entry parameters and the content of the extracts they return.

Table 1.

Table 1. Available Functions

	EHR	Input Arguments			Output	Get
		Patient	Code	arch_id		Compositions	Sections	Entries
put_extract	in	—	xml_file	—	string_id	—	—	—
get_extract	out	—	string_id	—	xml_file	—	—	—
get_health_record	out	Yes	No	No	xml_file	Yes	Yes	Yes
get_compositions	out	Yes	Yes	No	xml_file	Yes	No	No
get_sections	out	Yes	Yes	No	xml_file	No	Yes	No
get_entries	out	Yes	Yes	No	xml_file	No	No	Yes
get_compositions_arch	out	Yes	No	Yes	xml_file	Yes	No	No
get_sections_arch	out	Yes	No	Yes	xml_file	No	Yes	No
get_entries_arch	out	Yes	No	Yes	xml_file	No	No	Yes

The Web Services interface provides the same available functions as the CORBA interface and their internal executions in the server are also the same. The only thing that changes is the manner of invoking the functions and detecting the available services. The functions accessible via Web Services are written in Java, using the Axis library.

Status Report

Validation Tests

The validation tests carried out on the EHR service are divided into four phases, each of them with very different objectives such as: to test whether the libraries are working well, as well as the modules and XML-Schema generated, to check the performance of the storage model in both local and remote configuration, to check the performance of the communications interfaces and to check whether the reference model has sufficient semantic power to express the information structures that appear in the usual clinical practice.

For the trials in the first phase, a series of structures were constructed for each of the classes that appear in the model. This was done in a cumulative manner, that is, beginning with the classes of data types and, in each new step, utilizing the preceding structures to include them in the new ones, until the extract was completed. Each one of these structures was used in a chain of processes (▶) designed to test all the modules of the server, obtaining satisfactory results in all of them.

Table 2.

Table 2. Testing Procedures

	Testing Procedures	Evaluated Modules
Put structures	1. Creation of the XML file that represents the structure	Libraries of the reference model and transformer to XML
	2. Validation of the XML document	XML-Schema validator
	3. Generation of the Eiffel object corresponding to the structure	Libraries of the reference model XML parser (SAX)
	4. Storage of the structure in the database	Database interface
Get structures	5. Extraction of the database of the stored structures	Database interface
	6. Creation of the corresponding XML file	Libraries of the reference model and transformer to XML
	7. Validation of the XML document	XML-Schema validator
	8. Comparison of the new XML document with the original	Overall evaluation
Send structures	9. Transmission of an XML document to another machine	Communications modules
	10. Retrieval of the XML document	Communications modules

The second phase of the tests is centered on the performances of the different configurations of the permanent storage model. Extracts of different sizes are generated for this and the time taken to save and then recover them from the storage model is measured. The storage system used was MS Access 2000 in Windows 2000 and MySQL 4.1.14 in Windows 2000 and in Linux (SUSE 9.3). Comparisons of time were carried out both with the server and the storage system on the same machine (local configuration) and on different machines (remote configuration). The results show that the remote configurations have a very small delay, practically negligible, with respect to the local configurations.

In the third phase, the behavior of the communications interfaces, CORBA and Web Services, was tested. For this purpose, three identical machines were installed in a local-area network. In one of them, the MySQL 4.1.14 database manager was installed under Linux SUSE 9.3; in another, the developed EHR server and the CORBA and Web Services servers were installed; and in the third, the clients of both interfaces. Trials on the transmission and reception of extracts of different sizes were carried out using both interfaces, and the results show that both technologies have similar performances, although the CORBA times are slightly less.

The fourth and final phase of testing is centered on checking the capacity of the reference model of the standard to express the information structures that appear in the clinical practice with the necessary semantic power. For this, we work with other research groups centered on monitoring devices in the home and follow-up visits to patients with HIV. ^29,30 In this test, new groups generated extracts, which reflected their clinical activity, sent them to our server, and extracted them back. The first step was to define the archetypes that conform to the EN13606 standard, which represents the managed data. The primary archetypes were agreed between the groups implicated, while the organizational archetypes and the templates became the responsibility of the groups that were going to use them. Some specific XML-Schemas were also developed, very useful in validating the extracts generated. The generation of extracts was not particularly difficult for any of the groups, and the communication with our server, both in saving and in recovering extracts, was carried out correctly using the established functions.

Integration into a Real Scenario

In view of the results obtained, it was decided to test the function of the server in a real-world scenario, although it had to be chosen with care in order that the special characteristics of the prototype of the server do not affect the proper functioning of the system as a whole. From the very start, any application in real time was ruled out since the delays introduced by the storage module would make it difficult to obtain good results. Finally, we selected the platform for the follow-up of chronically ill patients, AIRMED-CARDIO, ³¹ which was also developed in our laboratory. This automatic platform (it does not require the intervention of an operator) permits patients from different groups (hypertension—HBP, heart failure—HF, Oral Anticoagulant Therapy—OAT, and asthma) to measure certain parameters themselves (the specific parameters that were measured in each scenario are set out in ▶) as well as a questionnaire to be filled in for its condition, and this information sent (through direct communication with the devices: General Packet Radio Service—GPRS; or through Wireless Application Protocol—WAP sessions when it is the patient who sends the data) to the hospital in which they are being treated. There, their physicians examine the data, which helps them to make decisions concerning the treatment of the patients and sends its recommendations in an SMS message through the platform. This greatly reduces the number of times that the patients have to visit the health care system. At the present time, this platform, although it is still not integrated into the routine activity of the hospital, manages clinical trials and pilot projects involving a large number of patients (four are active now, two of them, focusing on hypertension and heart failure, with the participation of 650 patients and 70 physicians, and another two, dealing with OAT and asthma, with 90 patients and 12 physicians). The platform, however, has a problem that is common to many e-health applications: the information generated during its use remains isolated, is not included in the electronic record of the patient and, ultimately, is lost. ³² The interest in having this information reach the record, thus making it available, for example, to research groups, is evident. This led the authors to consider the possibility of use the server developed to store in it the information generated in the AIRMED-CARDIO platform, in such a way that, with the inclusion of the entire necessary context, it loses none of its significance. Thus, all the information will be available to interested research groups and could, in the future, form part of the electronic patient file in the hospital, when this is introduced.

Table 3.

Table 3. Parameters in Each Scenario

	HBP	HF	OAT	ASTHMA
Patient sending
BP	X	X
Pulse	X	X
Weight	X	X
ECG		X
SpO2		X
INR			X
Spirometry				X
Questionnaire ∗	X	X	X	X
Replies
Message	X	X	X	X
Treatment	X	X	X	X

^∗ The questionnaire is different in each scenario, although made up of the same types of questions.

BP = blood pressure; ECG = electrocardiogram; SpO2 = pulse oximetry; INR = international normalized ratio (a measurement of the prothrombin time).

The process of connecting the platform to the server was as follows: First, the part of the information generated in the platform that was to be included in the future patient file was defined to enable the definition of the corresponding archetypes and templates. Then, a client of the server was generated that would automatically generate the extracts from the information stored in the platform database, in agreement with the previously defined archetypes, and send them to the server, where they were stored.

In this case, for each of the four scenarios dealt with (HBP, HF, OAT, asthma), the clinical concepts that are managed are identified in order to create the corresponding primary archetypes that included the definition of the questions that appear in the questionnaires. The templates based on them are created below in order to model the patient sending (that contain several concepts/archetypes each). Two more archetypes are also created, one to define the messages that the doctors send to the patients and another for the changes in treatment, which were the same for the four scenarios. The templates and archetypes generated for each scenario can be seen in ▶, and as an example, an archetype for an ENTRY that models blood pressure can be seen in ▶ as a symbolic representation and formally in ADL (Archetype Definition Language), the language for its definition specified in Part 2 of the EN13606 standard in ▶. The concept modeled is made up of three values, the systolic pressure, the diastolic (both in millimeters of mercury and with a restriction regarding the value that cannot be less than 10 mm nor greater than 500), and the time at which the measurement is taken (date and time). ▶ shows a fragment in XML of an extract corresponding to a message sent in which an ENTRY is shown in accordance with the previous archetype.

Table 4.

Table 4. Primary Archetypes Developed and Templates Built from Them (One to Represent the Data Sent by the Patients in Each Scenario)

Primary Archetypes	Templates
	HBP-sending	HF-sending	OAT-sending	ASTHMA-sending
BP	1	1
Pulse	1	1
Weight	1	1
ECG		1
SpO2		1
INR			1
Spirometry				1
Question YES/NO	7	6	6	4
Question better/same/worse		1		1
Message
Treatment

BP = blood pressure; ECG = electrocardiogram; SpO2 = pulse oximetry; INR = international normalized ratio (a measurement of the prothrombin time).

The questionnaires are different in each one, made up of a set of two types of questions: with a yes/no answer (“Have you ever had a migraine?”) or better/same/worse (“How do you feel today with respect to yesterday?”). The archetypes for the messages sent by the doctors or in order to represent modifications in the treatment are not used in the templates.

Figure 5.

Representation in blocks of the blood pressure archetype.

Figure 6.

Blood pressure archetype in ADL.

Figure 7.

Fragment of an extract (in XML) containing an ENTRY according to the blood pressure archetype described in ▶ (some elements have been closed to improve readability).

In these scenarios, the standard has provided mechanisms to represent both the information and its context. Some of the significant examples that appeared during this development are:

• • The relationship between different parts of the information. In order to show that a change in treatment has been brought about by a modification in the patient’s condition, LINK and its attributes nature (the general semantic category of the link declared between two RECORD_COMPONENTS) and role (the detailed semantic description of the relationship of the target RECORD_COMPONENT to the source) can be used.

• • A possible lack of exactness in the data. Although the majority of the measurements has been taken using electronic apparatuses, some of them (blood pressure monitor, Coagucheck®, etc.) do not communicate directly with the system, as it is the patient who finally provides the numerical data and without the supervision of a health professional. This uncertainty in the exactness of the information can be recorded using the uncertainty_expressed attribute of the ENTRY type.

• • Unknown data. On occasions it is necessary to show why a certain value is unknown. The null_flavor attribute of DATA_VALUE serves for this function.

Discussion

A server was developed for the transfer of extracts of EHRs in accordance with the EN13606 standard, the initial objective of which was to provide a proof of concept; however, owing to the good results obtained, it was decided to install it in a real scenario.

The XML-Schema generated, initially designed as a tool with which to verify the validity of the extracts received prior to processing them in the system, in addition to fulfilling this task, has played an important role in the production of extracts on the part of clients. It was the basis of the development of a “trial and error” mechanism that has made it possible to refine the processes of creating these extracts.

The weakest point of the server was found to be the storage system. The times recorded during its use have demonstrated that, with its present configuration, it cannot operate in a real-time setting, although it performs correctly in a scenario like that in which it has been installed, where the management of the information is offline and automatic. However, once the viability of systems of this type, based on the concepts of the EN13606 standard, has been established, work should be continued for the purpose of optimizing the storage system.

The two most important aspects, regarding the EN13606 standard, that have been able to be checked with this development are as follows:

• • The capacity of the standard to work with the information generated in real scenarios: In the scenarios in which the work was done (homecare, HIV, chronic disease), the EN13606 European Standard has fulfilled its objective of serving as a support for the representation and transfer of the information contained in the electronic patient file, conserving its entire significance and context, in such a way that it can be interpreted correctly at its destination. For this purpose, it was necessary to decide on and generate the archetypes that were to model the concepts of the domain managed in said scenarios.

• • The protection of the systems compatible to the standard against changes in the knowledge: The same EHR system server has been used in four real scenarios (as well as having worked with extracts from other environments) in which different information was managed without suffering any modifications at all. The separation between information and knowledge provided, on the one hand, a relatively simple reference model, made up of generic concepts which will not change over time, which will serve as a basis for the creation of future proof systems, and on the other hand, a knowledge model whose instances, the archetypes, model the domain concepts and restrict the instances of the reference model that are stored in the information system. Thus, a change in the knowledge will generate new archetypes or new versions of them, but no modifications in the reference model and, therefore, neither in the information systems compatible with it.