The GEHR/openEHR initiative was started in 1992 as an EU research project, called “Good European Health Record”, in the 3rd Framework Program. The initiative was later continued under the name “Good Electronic Health Record” with strong participation from Australia. Currently it is maintained by the openEHR Foundation, a non-profit organization defining itself as “an international, on–line community whose aim is to promote and facilitate progress towards EHRs of high quality, to support the needs of patients and clinicians everywhere”. The openEHR is a foundation that supports the development of an open and semantic-connected platform for eHealth systems (www.​openehr.​org). It is based on 15 years research, focused engineering design and real-world implementation experience, rather than being created as a formal consensus standard. However, over the last years it has had a significant influence over the development of EHR standards by the three main international eHealth standards organisations: CEN, HL7 and ISO. The information model covers the EHR architecture and describes classes such as Folder, Composition, Section and Entry, and of the basic data structure and types. The Care Entry class “define the semantics of all the ‘hard’ information in the record” [10], the Admin Entry represents information recorded during administrative issues. Figure 11.2 shows the ontology leading to the Entry model.

The most noteworthy concept introduced by GEHR/openEHR is the “archetype” concept. This approach uses a two-level methodology to model the EHR structure. In the first level, a generic reference model that is specific to the healthcare domain but still very general is developed. This model typically contains only a few classes (e.g. role, act, entity, participation) and must be stable over time. In the second level, healthcare and application specific concepts such as blood pressure, lab results etc. are modelled as archetypes, that is, constraint rules that specialize the generic data structures that can be implemented using the reference model. As an example, a constraint may restrict a generic “Observation” class to, e.g., “Blood Pressure” archetype.

An archetype definition consists of three parts: descriptive data, constraint rules and ontological definitions. The descriptive data contains a unique identifier for the archetype, a machine-readable code describing the clinical concept modelled by the archetype and various metadata such as author, version, and purpose. It also states whether an archetype is a specialization of another archetype. The constraint rules are the core of the archetype and define restrictions on the valid structure, cardinality and content of EHR record component instances complying with the archetype. The ontological part defines the controlled vocabulary (that is, machine-readable codes) that may be used in specific places in instances of the archetype. It may contain language translations of code meanings and bindings from the local code values used within the archetype to external vocabularies such as SNOMED or LOINC. It may also define additional constraints on the relationship between coded entries in the archetype based on the code value. As mentioned above the “Care Entry” concept covers the most common and medically relevant information.

In the openEHR four types of entries can be distinguished: observations, evaluations, instructions, and actions. The “observation” and “action” classes represent statements about the past events of the individual subject of record. The “evaluation” classes represent current assessment by the attending health professional, including “diagnosis” and “prognosis”, as well as the representation of the imagined future, like “goals” and “scenarios”. “Instructions” represents future events that should take place as prescribed by the health professional.

The openEHR framework includes a reference information model, the Archetype Definition Language (ADL) for expressing archetypes, an archetype library, implementation technology specifications (XML schemas, IDL specifications etc.) and a collection of open source implementations of the openEHR specifications.

Health Level Seven HL7 (www.​hl7.​org) is an international organization founded in 1987 and supported by ANSI with the goal of develops global standards related with eHealth. This organization has already defined a set of standards for clinical information interchange, whose name is HL7 standards. Among them HL7 CDA (Clinical Document Architecture) defines the Architecture of electronic documents used within Health domain and it is HL7’s current main strategy for EHR interoperability. Besides, HL7 supports RIM (Reference Information Model), a model of healthcare information as viewed within the scope of HL7 standards, which provides a static view of information needs along with use case models, interaction models, data type models, terminology models, and other types of models to provide a complete view of the requirements and HL7 standards design, thus giving a valid starting point for any HL7-compliant Architecture Design [11].

Meta-classes can be identified in RIM [12], as observed in Fig. 11.3:

Finally, the HL7 v3 Template is “an expression of a set of constraints on the RIM which is used to apply additional constraints to a portion of an instance of data which is expressed in terms of some other Static Model. Templates are used to further define and refine these existing models within a narrower and focused scope”.

The openEHR supports the creation, storage, maintenance, and querying of complete EHRs. ISO/EN 13606 is a subset of the full openEHR implementation and it is an appropriate standard for exchange of EHR extracts. At the same time, ISO/EN 13606 offers a partial alignment with HL7 Clinical Document Architecture (CDA) (Fig. 11.4).

Release 2.0, which complies with hl7 RIM. e.g., HL7 CDA is based on the HL7 RIM, but it was designed to represent patient summaries, not thinking on providing decision support capabilities. All the aforementioned reference models are archetype-based. HL7v2.x messaging is an appropriate standard, at least in short/medium term, for transmission of information from clinical information systems to EHR systems.

According to European Committee for Standardisation in standards CEN/TC251–ISO/TC215 2010 [6], the EHR is “the persistent longitudinal and potentially multi-enterprise or multinational record of health and care provision relating to a single subject of care (the patient), created and stored in one or more physical systems in order to inform the subject’s future health care and to provide a medico–legal record of care that has been provided”.

Patient data is managed, in current Hospital Information Systems (HIS), as a digital and well-structured record, which contains all individual-related health data, such as, demographic, diseases, allergies, history and activity during illness periods, etc.

The semantic interoperability of health data can be achieved only with the standardization of EHR. During the last 10 years, the international organizations have been driving great efforts to define the architecture for exchanging properly the health information between EHR coming from diverse systems (Munoz et al. 2011).

Coded elements are used in the healthcare environment to precisely define the clinical concepts language-independently. The use of medical terminology is one of the bases to provide semantic interoperability.

The crucial issue regarding the deployment of an EHR product in the medical environment is the ease of mapping to existing local data stores, as well as to national specifications (i.e. as an interface specification, for instance from hl7 v3 to archetypes). In order to provide the semantic interoperability the connection with external health terminology bindings is mandatory to be language independent [18]. The term binding is supported for manual or semi-automatic creation between archetypes and the concepts in terminology systems [19, 20] but the main drawbacks still reside in,

According to an eHealth ERA report related to eHealth priorities and strategies in European countries [21], the achievement of a European EHR is not yet an overarching goal, but collaboration on developing individual countries’ EHR or even basic patient summaries is a first step. Electronic Health Record is a rather fuzzy term, which has various definitions. A long-term objective of most European countries is a system of regional or nationwide summaries, or sometimes even full (occasionally life-long) document-based or deeply structured records for each citizen. Such a summary or record may be viewed by any of the following:

The eventual development of EHR is evident in 25 out of the 32 countries reviewed during the preparation of the above-mentioned report. Six countries report that they currently have widespread local EHR in hospitals and other health provider organisations, which, however, are not yet fully interconnected. Three countries have a national EHR, although they are yet restricted in scope. Luxembourg, for example, maintains radiology records for its citizens; and in Sweden, citizens have a medication record. Germany, Sweden and Turkey are currently developing the structures of a patient summary or minimal data set. Consistent with its regions-based healthcare system, Spain is developing this work on a regional level. Only one country has a fully implemented EHR system of a countrywide scope—the Czech Republic. The Danish MedCom infrastructure supporting the electronic exchange of various healthcare related messages between healthcare and other service providers is expanded towards a countrywide EHR system as well.

Interoperability seems not to be as high on most countries’ agendas as one might expect, given that it is one of the key issues in the EU eHealth Action Plan, it is a core element of current discussions among European Member States, and is also vividly present in international discussions. Only about one-third of the countries’ fact sheets mention interoperability explicitly. With the exception of Italy, Romania and Spain, which have made technical and semantic interoperability priority issues, interoperability is seen as a challenge that needs to be addressed as part of a larger initiative. In Denmark, for example, MedCom has already developed a platform for technical standards and interoperability for eMessages—the Danish Health Data Network—, and SNOMED CT (Systematised Nomenclature of Medicine Clinical Terms) is currently being translated to provide semantic interoperability. Figure 11.6 summarizes the status in several European countries regarding existence of EHR.