ArticlePDF Available

A Migration to an openEHR-Based Clinical Application

DOI:10.3233/978-1-60750-044-5-152
Authors:
Pariya Kashfi at Spotify
Pariya Kashfi
  • Spotify
Olof Torgersson at University of Gothenburg
Olof Torgersson
Download full-text PDFDownload full-text PDF
Read full-text
Download citation

Abstract and Figures

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, have been discussed in this paper.
Figures - uploaded by Olof Torgersson
Author content
All figure content in this area was uploaded by Olof Torgersson
Content may be subject to copyright.
Kashfi, Torgersson - 2009 - A Migration to an openEHR-Based Clinical Application - Unkno
wn.pdf
Content uploaded by Pariya Kashfi
Author content
All content in this area was uploaded by Pariya Kashfi on Jun 10, 2015
Content may be subject to copyright.
MIE2009p01
52.pdf
Content uploaded by Olof Torgersson
Author content
All content in this area was uploaded by Olof Torgersson on May 04, 2015
Content may be subject to copyright.
A Migration to an openEHR-Based
Clinical Application
Hajar KASHFI
1
, Olof TORGERSSON
Department of Computer Science and Engineering,
Chalmers University of Technology and University of Gothenburg, Sweden
Abstract. 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, have been discussed in this paper.
Keywords. openEHR, medical application, two-level modelling, archetype
1. Introduction
MedView
2
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 openEHR architecture, the
MedView project started an investigation to migrate from its framework to openEHR.
Motivations, and issues related to this process, have been discussed in this paper.
2. Comparing MedView and openEHR Approaches
openEHR is an EHR development framework that facilitates the level four of
interoperability [2]. In a two-level modelling approach, which has been used in
openEHR, 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.
1
Corresponding Author: Department of Computer Science and Engineering, Chalmers University of
Technology, SE-412 96 Gothenburg, Sweden; E-mail: hajar.kashfi@chalmers.se.
2
http://medview.se/.
Medical Informatics in a United and Healthy Europe
K.-P. Adlassnig et al. (Eds.)
IOS Press, 2009
© 2009 European Federation for Medical Informatics. All rights reserved.
doi:10.3233/978-1-60750-044-5-152
152
In openEHR 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. openEHR-based system architecture consists of four different layers:
x The Persistence layer includes EHR, an instance of RM, and is the kernel for
openEHR-based system.
x The Knowledge layer includes archetypes and templates, which at run time,
will be used for data validation and presentation.
x 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.
x The Application layer includes application specific services that access EHR
in the persistence layer through the service layer.
Figure 1. Migration from MedView to openEHR: An architectural perspective
While the reference model of openEHR 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 openEHR 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):
x The Data Layer includes medical records and related images.
x The Knowledge Layer consists of templates
3
, terms, and values.
x The Mediator Layer mediates between lower layers, and the application layer.
3
To prevent any confusion between MedView templates and openEHR templates, MedView templates are
written in Italics.
H. Kashfi and O. Torgersson / A Migration to an openEHR-Based Clinical Application 153
x The Application Layer includes application specific services, which can access
medical records through the knowledge and mediator layers.
Motivations for Migration to an openEHR-Based Architecture
In openEHR, 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.
Figure 2. A MedView examination form, generated based on a template
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 openEHR, 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 openEHR, one can put detailed constraints on data. Data is validated
based on corresponding archetypes and the storage of invalid data is not possible.
H. Kashfi and O. Torgersson / A Migration to an openEHR-Based Clinical Application154
Finally, MedView combines demographic and clinical information in examinations,
which decreases privacy. Hence, we started investigating migration from the current
framework to openEHR, which overcomes all deficiencies in MedView.
3. Method and Results of Migration to openEHR-Based MedView
A migration to an openEHR-based MedView consists of several processes (see Figure 1):
x Creating archetypes and templates.
x 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.
x Developing a service layer to connect applications to the kernel. Java is used
for developing required services.
x Extending existing Java-based applications to support openEHR.
4. Discussion and Conclusion
Since MedView is specifically aimed at providing clinicians with useful tools for several
tasks, a switch to openEHR must not lead to severe negative effects on any of these tasks.
For each application, changes required to make them openEHR-enabled should be
investigated.
x Knowledge Management: MedView provides tools that are used for creating
local terminologies and managing forms for data entry. In moving to
openEHR, one could either use the existing openEHR 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 openEHR tools, developing more usable editors will
probably be considered for the future.
x 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.
Further, the GUIs must not only be functional, but also have high usability.
x 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
openEHR, 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.
x Analytical Viewing: In MedView, visual exploration of stored clinical data is
possible using mVisualizer [4]. A move to openEHR will require some re-
thinking when it comes to visualization tools. This is because mVisualizer
H. Kashfi and O. Torgersson / A Migration to an openEHR-Based Clinical Application 155
assumes that the basic unit to visualize is sets of term/value pairs. Further
investigations will be needed to find a suitable visualization model.
x Personal Viewing: In MedView suit, mPhoto helps clinicians to search and
browse through images together with their corresponding examination data. A
move to openEHR would not mean anything for mPhoto in principle, but a
new search mechanism has to be implemented.
4.1. Problems Encountered in Using openEHR
During our efforts to migrate to openEHR we have encountered some problems:
x Complexity of the specifications: The current stable release of the openEHR
specifications is 885 pages. If some relevant specifications are included, the
total is 1,016 pages. Additionally, there are UML-diagrams and
documentation of code. Getting a grip on this is not an easy task.
x Complexity of archetypes: The archetype model is very powerful and allows
expressing complicated clinical concepts. It also takes some time to learn and
we have not found much documentation aimed at helping clinicians develop
archetypes. Further, the existing archetype editors cannot really be said to help
inexperienced archetype developers beyond hiding the actual syntax.
x Lack of implementation: In our preferred language, Java, the openEHR
implementation lacks important parts like templates, persistence, and services.
4.2. Conclusion
Our investigation proved that, a migration from traditional MedView to openEHR-
based MedView is possible in principle. Moreover, in developing the knowledge layer
and persistence layer because of current style of modelling in MedView this migration
is straightforward. Nevertheless, more effort is required for the other two layers;
especially for the service layer as a result of lack of implementation. Further, for
visualization applications a visualization model based on openEHR should be found.
Acknowledgements. We would like to thank openEHR community, technical and Java mailing
list members for their helpful discussions and supports. The work was funded by the Swedish
Governmental Agency for Innovation Systems (VINNOVA), grant 2006-02792.
References
[1] Jontell, M., Mattsson, U., Torgersson, O. (2005) MedView: An instrument for clinical research and
education in oral medicine. Oral Surgery, Oral Medicine, Oral Pathology, Oral Radiology, and
Endodontology 99(1):55–63.
[2] Beale, T., Heard, S. (2007) openEHR Architecture Overview.
http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/overview.pdf.
[3] Beale, T. (2002) Archetypes: Constraint-based domain models for future-proof information systems. In
Baclawski, K., Kilov, H. (Eds.) Eleventh OOPSLA Workshop on Behavioral Semantics: Serving the
Customer, Northeastern University, Boston, 16–32,
http://www.openehr.org/publications/archetypes/archetypes_beale_oopsla_2002.pdf.
[4] Erichson, N., Torgersson, O. (2005) mVisualizer: Easily accessible data exploration for clinicians.
Studies in Health Technology and Informatics 116:725–730.
H. Kashfi and O. Torgersson / A Migration to an openEHR-Based Clinical Application156
... 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. ...
Modeling healthcare authorization and claim submissions using the openEHR dual-model approach
Article
Full-text available
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.
View
... 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]. ...
Mapping a Nursing Terminology Subset to openEHR Archetypes: A Case Study of the International Classification for Nursing Practice
Article
  • Jan 2015
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.
View
... 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]. ...
View
... 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". ...
View
Leveraging the Value of Human Relationships to Improve Health Outcomes: Lessons learned from the OpenMRS Electronic Health Record System
Article
  • Feb 2017
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.
View
Providing Full Semantic Interoperability for the Fast Healthcare Interoperability Resources Schemas with Resource Description Framework
Conference Paper
  • Oct 2015
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.
View
Using the dual-level modeling approach to develop applications for pervasive healthcare
Article
  • Jan 2013
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.
View
Use of XML Schema Definition for the Development of Semantically Interoperable Healthcare Applications
Conference Paper
  • Jan 2014
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.
View
View
TECNOLOGIAS XML PARA A INTEROPERABILIDADE SEMÂNTICA EM SAÚDE: REFERENCIAL TEÓRICO E IMPLEMENTAÇÃO
Article
  • Dec 2013
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.
View
Archetypes: Constraint-based Domain Models for Future-proof Information Systems
Conference Paper
Full-text available
  • Jan 2002
Most information systems today are built using "single-level" methodologies, in which both informational and knowledge concepts are built into one level of object and data models. In domains characterised by complexity, large numbers of concepts, and/or a high rate of defini- tional change, systems based on such models are expensive to maintain and usually have to be replaced after a few years. However, a two-level methodology is possible, in which systems are built from information models only, and driven at runtime by knowledge-level concept definitions, or "archetypes". In this approach, systems can be built more quickly and last longer, whilst archetypes are authored directly by domain specialists, rather than IT personnel. Executed properly, the approach has the potential for creating future-proof systems and infor- mation. Work in the medical informatics domain on electronic health records (EHRs) has shown that a two-level methodology is implementable, makes for smaller systems, and empowers domain users.
View
mVisualizer: Easily Accessible Data Exploration for Clinicians
Article
Full-text available
In medical research and clinical work, having direct access to a large knowledge base of information about patients is very useful. Software for information visualisation can help the user browse, analyse and learn from such knowledge, thus providing new insights and accelerating research. However, when introducing new software to clinicians, who may have limited computer knowledge, adoption can be hindered by the complexity of the applications and the time investments necessary to learn them. By involving clinicians directly in the design process, we have developed mVisualizer, an application that provides a hands-on workspace to visualise and explore patient data. mVisualizer was designed for accessibility and simplicity, and to encourage users to explore the data in order to make discoveries and pose new questions relevant for knowledge gathering and research. The user-centered approach helped ensure that mVisualizer is understandable and easy to learn for clinicians. The application is in use by clinicians today, and its use has led to new discoveries and theories that will be the subject of future medical research. This leads to the conclusion that information visualisation software for exploring patient data can help clinicians and researchers by making the data more accessible, which stimulates research and learning.
View
openEHR Architecture - Architecture Overview
Article
  • Jan 2007
This document provides an overview of the openEHR architecture in terms of a model overview, key global semantics, deployment and integration architectures, relationship to published standards, and finally the approach to building Implementation Technology Specifications (ITSs). Semantics specific to each information, archetype and service model are described in the relevant specification. Full text: https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html
View
MedView: An instrument for clinical research and education in oral medicine
Article
The etiology for many of the mucosal lesions we encounter in clinical practice is frequently uncertain or unknown and there is reason to believe that multicausality plays an important role. To detect multicausal relationships, the analysis must include multiple variables and large amounts of data. A traditional retrospective analysis is often based on a limited number of variables and frequently entails methodological errors where vital information may be missing. Prospective studies may be hampered by the fact that the prevalences of many conditions are relatively low. The search for new knowledge in oral medicine should therefore be facilitated by prospective use of formalized information gathered in multicenter studies. MedView is a computer program that is based on formalized input and registration of all clinical information. The output applications are focused on visualization and statistical analysis. MedView is aimed at clinical research and is well suited for multicenter studies. It also contains applications for education and distant consultations.
View
mVisualizer: Easily accessible data exploration for clinicians Kashfi and O. Torgersson / A Migration to an openEHR-Based Clinical Application 156
  • 725-730
  • N Erichson
  • O Torgersson
Erichson, N., Torgersson, O. (2005) mVisualizer: Easily accessible data exploration for clinicians. Studies in Health Technology and Informatics 116:725–730. H. Kashfi and O. Torgersson / A Migration to an openEHR-Based Clinical Application 156