Figure 1 - uploaded by Olof Torgersson
Content may be subject to copyright.
Source publication
MedView is a suit of clinical applications for recording, retrieving and visualizing patient records, which has been developed and in use for more than ten years. By the introduction of the openEHR architecture, the MedView project started an investigation to migrate from its locally developed framework to openEHR. Issues related to this process, h...
Contexts in source publication
Context 1
... content should be defined by clinicians and the medical concepts can change without requiring any modifications to software. MedView architecture consists of these layers (see Figure 1): ...
Context 2
... migration to an openEHR-based MedView consists of several processes (see Figure 1): ...
Context 3
... due to the high complexity of existing openEHR tools, developing more usable editors will probably be considered for the future. N Data Collection: MedRecords automatically generates data entry forms based on XML templates (see Figure 1). In an openEHR MedView, this application should generate GUIs based on archetypes and templates, a non-trivial task. ...
Context 4
... focuses on understanding and implementing the chain “formalize-collect- view-analyse-learn” in oral medicine, in other words, using computing technology to handle clinical information such that clinicians more systematically can learn from gathered data [1]. Several tools have been developed for formalization, acquisition, visualization and analysis and sharing of data. As of January 2009, the main database at the clinic of oral medicine in Gothenburg contains data and digital images from well over 20,000 examinations making it a unique collection of information in its area. MedView is based on its own locally developed framework. In a time when data sharing is becoming increasingly important, this limits the possibilities for its development and expansion. By the introduction of the open EHR architecture, the MedView project started an investigation to migrate from its framework to open EHR. Motivations, and issues related to this process, have been discussed in this paper. open EHR is an EHR development framework that facilitates the level four of interoperability [2]. In a two-level modelling approach, which has been used in open EHR, a system is built from a general model that describes the basics of the system, and provides stable implementation for the parts that do not change often [3]. This stable basic system is then complemented with specialized artefacts that are created from tools or models provided by the basic system. In open EHR two-level modelling, the first level is the reference model (RM) [2] that describes all basic data structures, overall organization of the EHR, etc. The second level is made up of archetypes, which enables the creation of meaningful domain- models of clinical knowledge from the reference model building blocks. Archetypes specify valid EHR entries, their sequence, and structure. The division of systems into two levels provides for a clear division between the technical and medical parts of the system, and makes it possible to develop the clinical part independently of the system implementation. open EHR-based system architecture consists of four different layers: N The Persistence layer includes EHR, an instance of RM, and is the kernel for openEHR-based system. N The Knowledge layer includes archetypes and templates, which at run time, will be used for data validation and presentation. N The Service layer includes services required for creating, storing and retrieving EHR. Moreover, services for connecting to terminologies and online archetype repositories are in this layer. N The Application layer includes application specific services that access EHR in the persistence layer through the service layer. While the reference model of open EHR is rather elaborate including, for instance, details about time and versioning, MedView uses a very simple model. Clinical records are described as being made up of a number of examinations that are connected through a patient identifier. Each examination then consists of a number of sections defining different clinical concepts like “Biopsy” in terms of sets of term/value pairs (see Figure 2). The second level in MedView is made up of the actual definitions of clinical content that is very similar to open EHR conceptually. Clinical content should be defined by clinicians and the medical concepts can change without requiring any modifications to software. MedView architecture consists of these layers (see Figure 1): N The Data Layer includes medical records and related images. N The Knowledge Layer consists of templates 3 , terms, and values. N The Mediator Layer mediates between lower layers, and the application ...
Context 5
... open EHR, archetypes are re-usable maximal models of clinical concepts like blood- pressure examination. An existing archetype can be re-defined or extended through sub-classing. A template can combine several archetypes but also allows modifications like excluding parts of an archetype. In MedView, a simpler model is used where clinicians define templates by combining agreed upon basic units called terms. For instance, “The type of local anaesthetic” is represented by the term “Anest-type”. When a new notion needs to be introduced, a new term is defined that can then be used in future templates . Figure 2 shows an instance examination entry form generated from a template . A clear limitation in MedView is that it is impossible to combine several templates to form larger units. In open EHR, the idea of maximal data sets, redefining and extending existing archetypes and combining several archetypes to templates facilitates sharing of clinical data. Further, the quality of data in MedView is not sufficiently high since validation of data is basic. For instance, for the term “Anest-type” two possible values specified in the template are “Citanest-octapressin” and “Xylocian-adrenalin” though clinician at the time of data entry can enter a different value or even leave it empty. That results in data inconsistency, and makes sharing even harder. By using archetypes in open EHR, one can put detailed constraints on data. Data is validated based on corresponding archetypes and the storage of invalid data is not possible. Finally, MedView combines demographic and clinical information in examinations, which decreases privacy. Hence, we started investigating migration from the current framework to open EHR, which overcomes all deficiencies in MedView. A migration to an open EHR-based MedView consists of several processes (see Figure 1): N Creating archetypes and templates. N Translating MedView records to EHRs in openEHR and creating a persistence layer. For this purpose, the most convenient option, XML, is used. Up to now, more than 20,000 clinical examinations have been recorded. Each examination is stored in a text file including term/value pairs. In this translation, a mapping from current terms to nodes in archetypes is required. This has to be created, at least partly, by hand, but the actual translation will be done automatically. N Developing a service layer to connect applications to the kernel. Java is used for developing required services. N Extending existing Java-based applications to support open EHR. Since MedView is specifically aimed at providing clinicians with useful tools for several tasks, a switch to open EHR must not lead to severe negative effects on any of these tasks. For each application, changes required to make them open EHR-enabled should be investigated. N Knowledge Management : MedView provides tools that are used for creating local terminologies and managing forms for data entry. In moving to open EHR, one could either use the existing open EHR archetype and template editors, or create new ones better adapted to MedView. Because of lack of time, the second option is not a solution for now. However, due to the high complexity of existing open EHR tools, developing more usable editors will probably be considered for the future. N Data Collection : MedRecords automatically generates data entry forms based on XML templates (see Figure 1). In an open EHR MedView, this application should generate GUIs based on archetypes and templates, a non-trivial task. Further, the GUIs must not only be functional, but also have high usability. N Clinical Viewing : MedView makes a clear separation between entering and viewing clinical data. The tool MedSummary, aimed at clinical viewing, uses natural language generation to create a summary of one or more examination records and associated images. The style and contents of the text can be defined by the clinicians themselves, using a special editor. In moving to open EHR, there are no hard technical problems related to using the same kind of presentation. All that is required is knowledge about what kind of data is available, and some software glue retrieving archetype-based data. N Analytical Viewing : In MedView, visual exploration of stored clinical data is possible using mVisualizer [4]. A move to open EHR will require some re- thinking when it comes to visualization tools. This is because ...
Context 6
... open EHR, archetypes are re-usable maximal models of clinical concepts like blood- pressure examination. An existing archetype can be re-defined or extended through sub-classing. A template can combine several archetypes but also allows modifications like excluding parts of an archetype. In MedView, a simpler model is used where clinicians define templates by combining agreed upon basic units called terms. For instance, “The type of local anaesthetic” is represented by the term “Anest-type”. When a new notion needs to be introduced, a new term is defined that can then be used in future templates . Figure 2 shows an instance examination entry form generated from a template . A clear limitation in MedView is that it is impossible to combine several templates to form larger units. In open EHR, the idea of maximal data sets, redefining and extending existing archetypes and combining several archetypes to templates facilitates sharing of clinical data. Further, the quality of data in MedView is not sufficiently high since validation of data is basic. For instance, for the term “Anest-type” two possible values specified in the template are “Citanest-octapressin” and “Xylocian-adrenalin” though clinician at the time of data entry can enter a different value or even leave it empty. That results in data inconsistency, and makes sharing even harder. By using archetypes in open EHR, one can put detailed constraints on data. Data is validated based on corresponding archetypes and the storage of invalid data is not possible. Finally, MedView combines demographic and clinical information in examinations, which decreases privacy. Hence, we started investigating migration from the current framework to open EHR, which overcomes all deficiencies in MedView. A migration to an open EHR-based MedView consists of several processes (see Figure 1): N Creating archetypes and templates. N Translating MedView records to EHRs in openEHR and creating a persistence layer. For this purpose, the most convenient option, XML, is used. Up to now, more than 20,000 clinical examinations have been recorded. Each examination is stored in a text file including term/value pairs. In this translation, a mapping from current terms to nodes in archetypes is required. This has to be created, at least partly, by hand, but the actual translation will be done automatically. N Developing a service layer to connect applications to the kernel. Java is used for developing required services. N Extending existing Java-based applications to support open EHR. Since MedView is specifically aimed at providing clinicians with useful tools for several tasks, a switch to open EHR must not lead to severe negative effects on any of these tasks. For each application, changes required to make them open EHR-enabled should be investigated. N Knowledge Management : MedView provides tools that are used for creating local terminologies and managing forms for data entry. In moving to open EHR, one could either use the existing open EHR archetype and template editors, or create new ones better adapted to MedView. Because of lack of time, the second option is not a solution for now. However, due to the high complexity of existing open EHR tools, developing more usable editors will probably be considered for the future. N Data Collection : MedRecords automatically generates data entry forms based on XML templates (see Figure 1). In an open EHR MedView, this application should generate GUIs based on archetypes and templates, a non-trivial task. Further, the GUIs must not only be functional, but also have high usability. N Clinical Viewing : MedView makes a clear separation between entering and viewing clinical data. The tool MedSummary, aimed at clinical viewing, uses natural language generation to create a summary of one or more examination records and associated images. The style and contents of the text can be defined by the clinicians themselves, using a special editor. In moving to open EHR, there are no hard technical problems related to using the same kind of presentation. All that is required is knowledge about what kind of data is available, and some software glue retrieving archetype-based data. N Analytical Viewing : In MedView, visual exploration of stored clinical data is possible using mVisualizer [4]. A move to open EHR will require some re- thinking when it comes to visualization tools. This is because ...
Citations
... The openEHR specifications were chosen for being the original proposal for multilevel modeling which have been implemented in a verifiable manner in the scientific literature [17], and because the specifications and modeling tools are open and freely available for use. The openEHR archetypes are defined as the maximum data set for a particular healthcare concept [18], which means that all data elements that are part of a healthcare concept should be represented in the correspondent archetype [16,19]. ...
Background:
Healthcare information technologies have the potential to transform nursing care. However, healthcare information systems based on conventional software architecture are not semantically interoperable and have high maintenance costs. Health informatics standards, such as controlled terminologies, have been proposed to improve healthcare information systems, but their implementation in conventional software has not been enough to overcome the current challenge. Such obstacles could be removed by adopting a multilevel model-driven approach, such as the openEHR specifications, in nursing information systems.
Objectives:
To create an openEHR archetype model for the Functional Status concepts as published in Nursing Outcome Indicators Catalog of the International Classification for Nursing Practice (NOIC-ICNP).
Methods:
Four methodological steps were followed: 1) extraction of terms from the NOIC-ICNP terminology; 2) identification of previously published openEHR archetypes; 3) assessment of the adequacy of those openEHR archetypes to represent the terms; and 4) development of new openEHR archetypes when required.
Results:
The "Barthel Index" archetype was retrieved and mapped to the 68 NOIC-ICNP Functional Status terms. There were 19 exact matches between a term and the correspondent archetype node and 23 archetype nodes that matched to one or more NOIC-INCP. No matches were found between the archetype and 14 of the NOIC-ICNP terms, and nine archetype nodes did not match any of the NOIC-ICNP terms.
Conclusions:
The openEHR model was sufficient to represent the semantics of the Functional Status concept according to the NOIC-ICNP, but there were differences in data granularity between the terminology and the archetype, thus producing a significantly complex mapping, which could be difficult to implement in real healthcare information systems. However, despite the technological complexity, the present study demonstrated the feasibility of mapping nursing terminologies to openEHR archetypes, which emphasizes the importance of adopting the multilevel model-driven approach for the achievement of semantic interoperability between healthcare information systems.
... On the other hand, the adoption of the multilevel modelling strategy, using openEHR implementations has been proven to be effective for the acquisition of semantic interoperability between healthcare applications [12]. However, there are significant technical difficulties reported in the literature regarding the implementation of healthcare applications for routinely use [13]. In the current specification of the Archetype Definition Language (ADL) specifications, binding openEHR or ISO 13606 archetypes to controlled vocabularies has been reported as a complex task [14], resulting in the adoption of extra layers of modelling (e.g., the openEHR templates) [15] or reduced performance in the persistence mechanisms of implementations [16]. ...
... By using a stable RM and concepts expressed through archetypes, every change to the standard is carried out by simply designing new archetypes, or by specializing or creating new versions of the existing ones. Systems that adopt the openEHR architecture are supposed to accommodate the standard evolution much more easily than those that follow the traditional one-level model [22,[43][44][45][46][47]. ...
... The openEHR Foundation focus is mainly in the development of specifications for building what are called future-proof EHR systems. At present there are still few system implementations based on openEHR, mainly dealing with the clinical model [46][47][48][49]. This reflects in slower developments in the demographic and administrative areas and also in the communication of EHR extracts. ...
The TISS standard is a set of mandatory forms and electronic messages for healthcare authorization and claim submissions among healthcare plans and providers in Brazil. It is not based on formal models as the new generation of health informatics standards suggests. The objective of this paper is to model the TISS in terms of the openEHR archetype-based approach and integrate it into a patient-centered EHR architecture.
Three approaches were adopted to model TISS. In the first approach, a set of archetypes was designed using ENTRY subclasses. In the second one, a set of archetypes was designed using exclusively ADMIN_ENTRY and CLUSTERs as their root classes. In the third approach, the openEHR ADMIN_ENTRY is extended with classes designed for authorization and claim submissions, and an ISM_TRANSITION attribute is added to the COMPOSITION class. Another set of archetypes was designed based on this model. For all three approaches, templates were designed to represent the TISS forms.
The archetypes based on the openEHR RM (Reference Model) can represent all TISS data structures. The extended model adds subclasses and an attribute to the COMPOSITION class to represent information on authorization and claim submissions. The archetypes based on all three approaches have similar structures, although rooted in different classes. The extended openEHR RM model is more semantically aligned with the concepts involved in a claim submission, but may disrupt interoperability with other systems and the current tools must be adapted to deal with it.
Modeling the TISS standard by means of the openEHR approach makes it aligned with ISO recommendations and provides a solid foundation on which the TISS can evolve. Although there are few administrative archetypes available, the openEHR RM is expressive enough to represent the TISS standard. This paper focuses on the TISS but its results may be extended to other billing processes. A complete communication architecture to simulate the exchange of TISS data between systems according to the openEHR approach still needs to be designed and implemented.
... Archetype Editor are quite user-friendly, there is still a substantial element of data modelling and data awareness that is required to design and produce a good quality archetype. This is consistent with studies such as Kashfi et al., 2009 which stated that the tools "cannot be said to help inexperienced developers beyond hiding the actual syntax". ...
Objectives:
Despite significant awareness on the value of leveraging patient relationships across the healthcare continuum, there is no research on the potential of using Electronic Health Record (EHR) systems to store structured patient relationship data, or its impact on enabling better healthcare. We sought to identify which EHR systems supported effective patient relationship data collection, and for systems that do, what types of relationship data is collected, how this data is used, and the perceived value of doing so.
Materials and methods:
We performed a literature search to identify EHR systems that supported patient relationship data collection. Based on our results, we defined attributes of an effective patient relationship model. The Open Medical Record System (OpenMRS), an open source medical record platform for underserved settings met our eligibility criteria for effective patient relationship collection. We performed a survey to understand how the OpenMRS patient relationship model was used, and how it brought value to implementers.
Results:
The OpenMRS patient relationship model has won widespread adoption across many implementations and is perceived to be valuable in enabling better health care delivery. Patient relationship information is widely used for community health programs and enabling chronic care. Additionally, many OpenMRS implementers were using this feature to collect custom relationship types for implementation specific needs.
Conclusions:
We believe that flexible patient relationship data collection is critical for better healthcare, and can inform community care and chronic care initiatives across the world. Additionally, patient relationship data could also be leveraged for many other initiatives such as patient centric care and in the field of precision medicine.
The Fast Healthcare Interoperability Resources (FHIR) is an open suite of specifications and software implementations of the Health Level 7 version 3 (HL7v3) standard. It has been proposed to provide a consistent API for the HL7v3 CDA. However, the core issues of HL7v3 are not solved at the API level. The community around the project are proposing the adoption of RDF technologies to overcome the current challenges in interoperating with linked data. However, RDF triples nor ontologies provide semantic interoperability by themselves, a more robust information infrastructure, such as the Multilevel Model-Driven (MMD) approach, is required. An XML implementation of the MMD was used to model the FHIR Schemas as Domain Models (DMs) against a generic Reference Model (RM) to provide syntactic validation. RDF triples were included in the domain models to provide missing semantics. The XML data instances were validated against their Domain Models. The DMs do not create any new types, they only express constraints of the RM types, this provides consistent query and data analysis capability across all DMs. RDF triples were extracted from the DMs and added to a triple store graph with the RM ontology. The XML data is also expressed as Literals in the graph. This study shows the feasibility of using MMD solutions to provide full operational semantic interoperability for the FHIR ecosystem.
Health information technology is the area of IT involving the design, development, creation, use and maintenance of information systems for the healthcare industry. Automated and interoperable healthcare information systems are expected to lower costs, improve efficiency and reduce error, while also providing better consumer care and service. Pervasive Healthcare focuses on the use of new technologies, tools, and services, to help patients play a more active role in the treatment of their conditions. Pervasive Healthcare environments demand a huge amount of information exchange, and specific technologies have been proposed to provide interoperability between the systems that comprise such environments. However, the complexity of these technologies makes it difficult to fully adopt them and to migrate Centered Healthcare Environments to Pervasive Healthcare Environments. Therefore, this paper proposes an approach to develop applications in the Pervasive Healthcare environment, through the use of dual-level modeling based on Archetypes. This approach was demonstrated and evaluated in a controlled experiment that we conducted in the cardiology department of a hospital located in the city of Marilia (São Paulo, Brazil). An application was developed to evaluate this approach, and the results showed that the approach is suitable for facilitating the development of healthcare systems by offering generic and powerful capabilities.
Multilevel modeling has been proven in software as a viable solution for semantic interoperability, without imposing any specific programming languages or persistence models. The Multilevel Healthcare Information Modeling (MLHIM) specifications have adopted the XML Schema Definition 1.1 as the basis for its reference implementation, since XML technologies are consistent across all platforms and operating systems, with tools available for all mainstream programming languages. In MLHIM, the healthcare knowledge representation is defined by the Domain Model, expressed as Concept Constraint Definitions (CCDs), which provide the semantic interpretation of the objects persisted according to the generic Reference Model classes. This paper reports the implementation of the MLHIM Reference Model in XML Schema Definition language version 1.1 as well as a set of examples of CCDs generated from the National Cancer Institute – Common Data Elements (NCI CDE) repository. The set of CCDs was the base for the simulation of semantically coherent data instances, according to independent XML validators, persisted on an eXistDB database. This paper shows the feasibility of adopting XML technologies for the achievement of semantic interoperability in real healthcare scenarios, by providing application developers with a significant amount of industry experience and a wide array of tools through XML technologies.
Introducao e Objetivo : Descrever a implementacao do Modelo de Referencia das especificacoes Multilevel Healthcare Information Modeling (MLHIM) em tecnologias XML, bem como um conjunto de exemplos de conceitos de saude gerados a partir do repositorio do National Cancer Institute – Common Data Elements . Material e Metodo : As especificacoes MLHIM adotaram XML Schema Definition 1.1 como base para a sua implementacao de referencia, uma vez que as tecnologias XML sao consistentes em todas as plataformas e sistemas operacionais, apresentando ferramentas disponiveis para todas as linguagens de programacao convencionais. Resultados : Nas especificacoes MLHIM, a representacao do conhecimento de saude e definida pelo modelo de dominio, expressa em Concept Constraint Definitions (CCDs), que fornecem a interpretacao semântica dos objetos persistidos de acordo com as os tipos genericos do modelo de referencia. O conjunto de CCDs foi a base para a simulacao de instâncias de dados semanticamente coerentes, de acordo com validadores XML independentes, persistidos em um banco de dados XML. Conclusoes : Este trabalho mostra a viabilidade da adocao de tecnologias XML para a realizacao da interoperabilidade semântica em cenarios reais de saude, provendo os desenvolvedores de aplicativos com uma quantidade significativa de experiencia acumulada e um vasto leque de ferramentas disponiveis.
