New Approach to an openEHR Introduction in a Portuguese Healthcare Facility
Implementing a new EHR data system is not easy, as the systems already in place and user mentality are very difficult to change. The openEHR architecture introduces a new way of organizing clinical information using archetypes and templates. The present paper focuses on the initial steps of the implementation of an openEHR based EHR in a Portuguese major HealthCare provider. The system comprises operational templates creation through the creation of a validation mechanism and after that storage, a platform for data generation dynamically constructed from templates and an interoperability mechanism through the implementation of an HL7 V3/CDA message system.
KeywordsEHR openEHR Archetypes Operational templates HL7 V3/CDA SNOMED CT Interoperability
An Electronic Health Record (EHR) storages a large amount of medical data, data that must be available throughout the lifetime of a patient. Besides the effort and cost the solution must protect information when data loss occurs and at the same time be persistent and reliable across the years. The problem is often not the quantity of available data, instead the major issue is the fact that most of the information is made up to free text serving for nothing more than registering and consulting information.
Since 2004, the openEHR foundation has published a series of design specifications for semantically interoperable and future-proof EHR systems. The main feature of the openEHR design is the separation between clinical concerns and technical design, the so called, two-level modelling . The first level, Reference Model (RM), represents the technical concerns (information structure and data types). The second level of the model handles the clinical domains (representation of communication of the semantics) . This enables the construction of stable EHR systems without specific clinical content necessary in different fields .
The use of archetyping in openEHR enables new relationships between information and models. An archetype stands for a computable expression of a domain in the form of structured constraint statements, so openEHR archetypes are based on the openEHR Reference Model . These can be composed into larger structures called the templates .
The purpose of the present document is to demonstrate the initial steps taken in the implementation process of an openEHR based EHR in a Portuguese major healthcare unit. The solution composes the creation of templates (modification of archetypes and translation), a system for validation and storage of the previous and the subsequent creation of web forms with basis on that operational templates. The system will also feature the generation and storage of information and exchange of information using HL7 Version 3 guidelines and HL7 V3 CDA. HL7 International specifies several flexible standards, guidelines, and methodologies by which various healthcare systems can communicate with each other. Such guidelines or data standards are a set of rules that allow information to be shared and processed in a uniform and consistent manner. These data standards are meant to allow healthcare organizations to easily share clinical information. Theoretically, this ability to exchange information should help to minimize the tendency for medical care to be geographically isolated and highly variable.
After the introduction, section two is entitled “Background” and is based on an intensive review of the literature on the theme, as well as, in the opinion of several authors, using them as motivations and strengths of the present work. Subsequently, the main section is presented as “System overview” and initially describes the proposed system in a general way, and then each component is described in detail. In the section “Discussion”, through the SWOT analysis, a primary evaluation of the described system was carried out and, in the last section “Conclusion and Future Work”, the main conclusions of the work accomplished, as well as, future steps are mentioned.
Structuring large amount of information is not easy, as noted by several failed attempts reported in the past. According to Rector in “Clinical Terminology: Why is it so hard?” one of main reasons is that structuring requires standardization of the structured element that usually is implemented in a top-down manner . The openEHR architecture presents a new and interesting approach that empowers the local user to decide how they want to structure the EHR .
Although reported in various informatic research projects with considerable success, reports from real large scale implementations are still scarce . This statement highlights the importance and difficulty of this kind of projects. Ellingsen et al. reported the first efforts to implement large-scale EHR in Western hospitals (in Norway) conforming to the openEHR architecture , offering an insight into the first two years of the process, and the socio-technical challenges they met along the way. Wollersheim et al. in “Archetype-based electronic health records: a literature review and evaluation of their applicability to health data interoperability and access” presents an overview of the current archetype literature relevant to Health Information Managers . In this paper, different developments are presented, concerning different settings of healthcare: elder patient care, complementary and alternative medicine, nursing, discharge summary or even security concerns focused on the security of MEDIS. The same work also presents a distribution of works by country, with Australia assuming a leading role in the openEHR implementation.
One of these Australian works belongs to Murat Gok, entitled “Introducing an openEHR-Based Electronic Health Record System in a Hospital”, provides a road map for future implementations of an openEHR system in the Austin Hospital Emergency Department, Melbourne, including history, architecture and relationships to other standards. These relations play a central role on the present work, R. Qamar and A. Rector presented in “Semantic Mapping of Clinical Data to Biomedical Terminologies to Facilitate Data Interoperability” interesting points of view on this subject, stating that interoperability of clinical systems requires integration of data models, such as HL7 messages or openEHR archetypes, with terminologies such as SNOMED-CT or ICD-X .
A key to the success of an EHR system is inevitably its usability. If the Graphical User Interface (GUI) of a system is not intuitive and appealing there will be greater resistance from healthcare professionals, leading to under-use or misuse of the system . Template4EHR (http://template4ehr.azurewebsites.net/) and EhrScape Framework (https://www.ehrscape.com/) are examples of tools that dynamically generate GUI from archetypes for Health applications .
3 System Overview
3.1 Information Workflow
When new data is inserted in a specific case, such as clinical reports or specific messages, is the system requires the use of templates, previously defined and composed of various archetypes. In this case, Medical Observations template combine three independent archetypes, but the Diabetic Checkup use only two. In this new approach, operational templates (OPT) will be used because they have a flexible structure that facilitates the implementation processes, using extensible markup language (XML) or java object notation (JSON). With respect to this, the chosen strategy to save the OPTs in a specific database shall encounter consistency and reasoning. Furthermore, these OPTs can be compiled and transformed into specific artifacts, ready to be used by software developers, messaging systems implementers or data managers .
The proposed system will contain a multi-function support platform that allows one to submit new templates or consult existing ones. When a new template is submitted, it must be approved manually or automatically. In manual mode, a designated professional will accept or not the submitted templates, respecting the governance rules. After this validation, the template will be saved in the repository with a compatible format for the next processes, as aforementioned. In this step, the information conjugated from different HISs generates structured knowledge (Concepts and Definitions), ready to be use and, posteriorly, to create dynamic and responsive web forms. These web forms constitute the User Platform presented in Fig. 1.
3.2 Data Generation
The second part of the system consists in the dynamic generation of GUI from Operational Templates.
A web service will be responsible for reading the operational templates, extract the data and generate the GUIs, creating a webform platform.
It will use two repositories: one for storage of the OPTs (the label and definition of what is being clinically observed, and another for storage of the data inserted by healthcare professionals (the values, or results of the observation).
Semantic interoperability is ensured by binding the SNOMED CT terminology and the informational structures, represented by archetypes.
3.3 HL7 Binding
The trigger event (1) deploys a chain reaction that leads to the share of information or documents from one health system to another. The creation of an interface for TCP or Web sockets will enable the byte stream across the internet. After the trigger event, the interface must assemble the HL7 message v3 or CDA using the EHR in openEHR format, through query methodologies like ADL (2, 3). A XML-like document is created, converted to byte stream and sended to the interface B. This point will require a XSLT transformation in order to convert the XML associated with the HL7 v3 or CDA message to openEHR compatible content. This is based on the templates stored in a openEHR repository, designed specifically for that purpose (5). After that step, the information is ready for storage in openEHR-validated archetypes or templates.
3.4 System Communication: Multi-agent Systems
As the volume of clinical data is very high, it was necessary to build consistent and organized data models. In this case, each repository of the system will be updated through multi-agent systems (MAS) and, consequently, the front-end applications will be synchronized. Being multi-agent architectures a field of research of distributed artificial intelligence, this technology is intrinsically connected to the concepts that define a distributed architecture, while being distinct in the definition of an agent versus the properties of the general middle-wares of many others distributed architectures. A MAS is a computer system with several autonomous agents that that interact with each other to perform certain tasks. Its main characteristics are the autonomous capacity to make decisions, as well as the capacity to interact with other agents through social interaction protocols, reaching the desired levels of coordination and cooperation .
Each health unity already aggregates information under the same roof, through the Agency for Integration, Diffusion and Archive of Medical Information (AIDA) system. AIDA is an agent-based platform with the purpose of ensuring the interoperability among HIS, i.e., is an example of a MAS . On other hand, different health units communicate through hl7 v2 agents.
SWOT analysis for the proposed system.
Better structure of data and interoperability
Connection to the hospital intranet is required
Modernization and organizational development
User resistance of adopting a new system by healthcare professionals
User-friendly and intuitive interface
Manual creation of archetypes by health professionals
Economic benefit of using an open source solution (openEHR)
5 Conclusion and Future Work
Verifying the SWOT analysis, it is possible to conclude that the proposed system is expected to grant significant added value for the Portuguese healthcare unit where it is to be implemented. For a better understanding of the benefits of this new system it is important to design and perform a study that compares this new system with the one previously implemented in the healthcare unit.
In the future could be added to the system a decision support tool with the aim to help the healthcare professionals for example, when a healthcare professional fills the diagnosis field in the form the symptoms field should be automatically filled in.
This work has been supported by Compete POCI-01-0145-FEDER-007043 and FCT - Fundação para a Ciência e Tecnologia within the Project Scope UID/CEC/00319/2013.
- 1.Beale, T., Heard, S.: Archetype definitions and principles. In: Ocean Informatics, p. 15 (2007)Google Scholar
- 2.openEHR Foundation: openEHR - Design Principles. In: Design Principles (2017)Google Scholar
- 3.Rector, A.L.: Clinical terminology: why is it so hard? Methods Inf. Med. 38(4–5), 239–252 (1999)Google Scholar
- 5.Wollersheim, D., Sari, A., Rahayu, W.: Archetype-based electronic health records: a literature review and evaluation of their applicability to health data interoperability and access. Health Inf. Manag. J. 38(2), 7–17 (2009)Google Scholar
- 6.Sciences, P., Qamar, R., Rector, A.: Semantic mapping of clinical model data to biomedical terminologies to facilitate. In: HealthCare Computing Conference 2007, p. 257 (2007)Google Scholar
- 7.Schuler, T., Garde, S., Heard, S., Beale, T.: Towards automatically generating graphical user interfaces from openEHR archetypes. Stud. Health Technol. Inform. 124, 221–226 (2006)Google Scholar
- 8.De Araujo, A.M.C., Times, V.C., Da Silva, M.U., Alves, D.S., De Santana, S.H.C.: Template4EHR: building dynamically GUIs for the electronic health records using archetypes. In: Proceedings of the 16th IEEE International Conferences on Computer and Information Technology (CIT 2016), pp. 26–33 (2017). 6th International Symposium on Cloud Service Computing (IEEE SC2 2016), 2016 International Symposium on Security Privacy in Social NetworksGoogle Scholar
- 9.Oliveira, R.: Transformation of clinical data from HL7 messages to openEHR compositions (2016)Google Scholar
- 11.Peixoto, H., Santos, M., Abelha, A., Machado, J.: Intelligence in interoperability with AIDA. In: 20th International Symposium on Methodologies for Intelligent Systems, World Intelligence Congress, Macau. LNCS, vol. 766. Springer, Heidelberg (2012)Google Scholar