enabling agents to retrieve openehr- based health data ...oci openehr composition instance pdf...
TRANSCRIPT
Enabling agents to retrieve openEHR-based health data through
implementing HL7 communication with departmental information systems
Paulo Roberto da Silva Ferreira
OCT|2012
5th ed
Enabling agents to retrieve openEHR-based health data through
implementing HL7 communication with departmental information systems
Paulo Roberto da Silva Ferreira
OCT|2012
Ricardo João Cruz Correia Pedro Manuel Vieira Marques
5th ed
“Standardized access to knowledge systems and bibliographic systems must support
scripting and data-entry mechanisms to ensure that a data system can properly and accurately
provide a response.”
“User queries will need to identify the patient and either request or transmit data elements
to other components of the distribution environment.”
“Vendors may interpret the use of a data field differently, depending on their perspective or
orientation.”
W. E. Hammond and J. J. Cimino in (Garber, et al., 2006)
Acknowledgements
To my thesis advisor and friend Prof. Dr. Ricardo Cruz Correia, for his
guidance during the development of this work, especially his scientific input
was very helpful to me in my long learning in these past years. Thank you to
believing in my capabilities and mainly to empower them.
To Dr. Pedro Manuel Vieira Marques, whose dedication, motivation and
perseverance were essential to the achievement of this work.
To the Prof. Dr. Luis Filipe Coelho Antunes, for his always innovative
vision as director of the Master in Medical Informatics.
To my master colegues Bruno Santos, Alexandre Santos, Carlos Vicente,
Liliana Leite and Fernando Almeida.
To the CIDES, Faculty of Medicine, University of Porto, the Centre for
Research in Information Systems and Technologies Health (CINTESIS) and
project PTDC/EIA-EIA/105352/2008 "SAHIB - Enhancing multi-
institutional health data availability through multi-agent Systems", funded by
the Foundation for Science and Technology, for providing the means and
resources needed for this work.
To my friends, for understanding the continuous absence of my company.
To my family, for always believing in my work.
To the last but not the least most important, the most important women in
my live, my wife and my daughter, for your presence in my life, for their
constant and ever-present motivation without which it would be more difficult
to overcome the difficulties that have arisen throughout this thesis.
Sumário
Proporcionar a todos os profissionais de saúde o acesso aos dados de saúde
dos pacientes de forma completa, transparente e em tempo real é um grande
desafio para as organizações de saúde. Portanto, a entrega eficiente e integrada
de registos de saúde electrónicos, a fim de melhorar a qualidade do processo de
comunicação entre profissionais de saúde é um grande compromisso.
A integração sistemas de informação de saúde com o propósito de melhorar
a comunicação de dados, a pesquisa e gestão desses dados é um grande esforço.
A razão para a enorme dificuldade na resolução destes problemas de
interoperabilidade entre diferentes instituições de saúde, nomeadamente em
Portugal, podem estar relacionados com a mesma dificuldade encontrada
dentro de cada instituição ao nível departamental. Atingir uma ampla
interoperabilidade entre dentro de cada instituição de saúde em Portugal é um
problema relevante.
Há um crescente interesse e implementação de normas de saúde. O HL7
tem uma aceitação global e é actualmente e amplamente utilizado. O foco na
interoperabilidade aumenta a capacidade do openEHR para responder e se
adaptar à evolução tecnológica.
Este trabalho tem como objectivo definir uma arquitectura que permita que
os agentes pesquisem e extraiam dados de saúde a partir de um sistemas de
informação de saúde baseado em HL7 presentes numa instituição de saúde
externa, contribuindo para a melhoria na disponibilização de dados de saúde no
local de prestação de cuidados de saúde.
É descrito uma forma de integrar pesquisas de dados baseadas em
openEHR a partir de mensagens HL7 para consultar um repositório local de
informações do pacientes numa instituição de saúde externa, permitindo um
sistema multi-agente desenhado para a obtenção de dados multi-institucionais
procurando e extraindo dados essenciais no processo de prestação de cuidados
de saúde.
Com as normas de saúde e tecnologias livres foi desenvolvido um modelo
de modo a melhorar a descoberta e extracção de dados de saúde do paciente.
Este modelo harmoniza a fonte de dados de saúde (HL7). A qual é modelada
através de modelos metabólicos com a mesma estrutura de um modelo de
arquétipo, concebendo composições openEHR. Consequentemente a
construção de um repositório openEHR com as várias composições permite
aos agentes a utilização de Archetype Query Language para pesquisa e
extracção de dados clínicos baseados em arquétipos.
Abstract
Providing all healthcare professionals complete, transparent and real-time
access to patient information is a major challenge facing healthcare
organizations. Therefore, there is a major commitment to deliver efficient
integrated electronic patient records in order to increase the quality of
communication process between health professionals.
Integrating clinical information systems improving communication and
healthcare delivery data, research and management is a major effort. The reason
for the enormous difficulty in solving interoperability problems between
different institutional information systems in Portugal may be related with the
same difficulty found within each institution departmental information systems.
Achieving a broad interoperability between information systems in Portuguese
health institutions is a major problem.
There is growing interest and employment of health standards. The HL7 has
a global acceptance and is currently and widely used. The focus on
interoperability enhances the ability of openEHR to respond and adapt to
technological developments.
This work aims to define an architecture that allows agents to seek and
collect health data from an HL7 based information systems that exist in
external health institutions, contributing for the improvement of health data
availability at the point of care
This paper describes a way to integrate openEHR queries with HL7
messages to query a local repository of patient information at an external
institution, enabling a multi-agent system designed for the retrieval of multi-
institutional data to search for and retrieve patient data essential for the process
of care delivery.
With health open standards and technologies a model was developed in
order to enhance the discovery and retrieval of patient health data. This model
have harmonized health data source input (HL7). This is modelled through
metabolic templates with the same structure of an archetype template,
providing openEHR compositions. Consequently building an openEHR
repository with the modelled compositions allows the agents to use the
Archetype Query Language for searching and retrieving the clinical data found
in archetype-based.
Preamble
My academic background is computer science, having a wide professional
experience in the area of medical informatics, predominantly in health
information systems interoperability and standards for the exchange of health
data (6 years in Glintt Healthcare Solutions SA and currently in Serviços
Partilhados do Ministério da Saúde EPE). This eventually become my
professional passion.
Since the beginning of the master classes I guided most of my works for this
passion and naturally I was invited to join the project team of the SAHIB in the
scope of my master's thesis. The work presented in this thesis concerns one of
eight tasks recognized in the FCT project (PTDC/EIA-EIA/105352/2008),
which given title is “Enhancing multi-institutional health data availability thru multi-
agent systems”, which principal research unit is the Department of Health
Information and Decision Sciences in Faculty of Medicine, University of Porto.
Table of contents
Acknowledgements ................................................................................... v
Sumário .................................................................................................... vi
Abstract .................................................................................................. viii
Preamble.................................................................................................... x
Table of contents ...................................................................................... xi
Acronyms ................................................................................................ xiv
List of figures......................................................................................... xvii
List of tables ......................................................................................... xviii
Organization of the document ............................................................... xix
Outcomes ............................................................................................... xxi
Published articles ............................................................................................... xxi
Unpublished articles ......................................................................................... xxi
1. Introduction .....................................................................................1
Providing high-quality healthcare services is an information-dependent
process ......................................................................................................................... 1
Safeguarding clinical meaning across high-interoperable heterogeneous
systems ......................................................................................................................... 2
Binding Multi-agent systems features with healthcare vast exposed
environment ................................................................................................................ 2
The importance of using common standards for interoperability ............... 3
The timeline of Health Level 7 history ............................................................. 5
Overview of the health standard openEHR formalism ................................. 6
Available archetype persistence methodologies .............................................. 9
2. Aim ................................................................................................ 12
SAHIB aim .......................................................................................................... 12
3. State of art ...................................................................................... 13
HL7 and openEHR worldwide........................................................................ 13
Transform HL7 messages into openEHR composition instances ............ 15
Analysing and express intra and inter institution workflows ...................... 15
Compliance of health standards employed .................................................... 16
4. Material and methods .................................................................... 17
Open source interoperability framework ....................................................... 17
Software development process methods........................................................ 19
Predicting some storyboards and use cases ................................................... 20
5. Results .......................................................................................... 22
General architecture .......................................................................................... 22
Intra-institution designing architecture approach ......................................... 23
Consuming HL7 messages as data source input ........................................... 24
Achieving data integration through template data schema ......................... 25
Using template data schema to produce a template data document ......... 26
Designing of the conversion module activity statechart .............................. 27
Metabolic template data schema to produce a template data document .. 29
Conversion of a template data document into an openEHR composition
instance ...................................................................................................................... 30
Link patient to openEHR composition instances ........................................ 32
Conversion HL7 template data schema configuration ................................ 32
6. Difficulties .................................................................................... 34
7. Discussion .................................................................................... 36
Introductory objectives discussion .................................................................. 36
Feasibility of HL7 messages as input .............................................................. 36
Archetyped conversions customized through template data schema........ 37
Necessity of storing queryable EHR data ...................................................... 37
Yet another conversion approach ................................................................... 37
8. Conclusions and recommendations ............................................. 39
9. Future work .................................................................................. 40
10. References ..................................................................................... 41
Annexes ................................................................................................... 49
Published articles ................................................................................................ 49
Unpublished articles .......................................................................................... 56
Generated prototype classes model ................................................................ 62
Acronyms
AM Archetype Model
ANSI American National Standards Institute
API Application Programming Interface
AQL Archetype Query Language
ASCII American Standard Code for Information Interchange
CINTESIS Center for Research in Technology and Health Information Systems
CKM Clinical Knowledge Manager
DB Database
DIS Departmental Information System
EHR Electronic Health Record
ESB Enterprise Service Bus
FCT Fundação para a Ciência e a Tecnologia
FILE File System
FIPA Foundation for Intelligent Physical Agents
FTP File Transfer Protocol
GUI Graphical User Interface
HI Health Institution
HIS Health Information System
HL7 Health Level Seven
IHE Integrating the Healthcare Enterprise Organization
IS Information System
JADE Java Agent Development Framework
JAR Java Archive
JMS Java Message Service
MLLP Minimal Lower Layer Protocol
MAS Multi-Agent System
MLM Multi-Level Modelling
MPI Master Patient Index
OCI openEHR Composition Instance
PDF Portable Document Format
POM Project Object Model
RM Reference Model
RIM Reference Information Model
SAHIB Secure Agent-based Health Information Brokering System
SFTP SSH File Transfer Protocol
SOAP Simple Object Access Protocol
SSH Secure Shell
TDD Template Data Document
TDS Template Data Schema
TDDP Test Driven Development Process
UML Unified Modelling Language
XML Extensible Markup Language
XSD XML Schema
XSL Extensible Stylesheet Language
List of figures
Figure 1 – Health Level 7 timeline. ............................................................................ 6
Figure 2 – Schematic representation of the openEHR Multi-Level Modelling
Paradigm. ........................................................................................................................ 7
Figure 3 – The openEHR information model from the openEHR site
http://www.openehr.org/. .......................................................................................... 8
Figure 4 – ADL representation of the Archetype structure. ................................ 10
Figure 5 – Standards development organizations (Ganslandt, 2009). ............................ 14
Figure 6 – Mirth channel architecture. ..................................................................... 17
Figure 7 – Different approaches for data flow in Mirth. ...................................... 18
Figure 8 – Parent prototype project pom.xml. ....................................................... 19
Figure 9 – Intra-institution environment use case. ................................................ 21
Figure 10 – Inter-institution environment use case. .............................................. 21
Figure 11 – Multi-agent System for the exchange of healthcare data. ................ 22
Figure 12 – Intra-Institution designing architecture. ............................................. 23
Figure 13 – SAHIB reception module components diagram. .............................. 24
Figure 14 – Schema of the message source system transformation into
templates data documents. ......................................................................................... 27
Figure 15 – Activity statechart of the receiving and conversion module. .......... 28
Figure 16 – Metabolic TDD conversions snapshot............................................... 29
Figure 17 – openEHR CKM mindmap of the archetype openEHR-EHR-
OBSERVATION.lab_test.v1. ................................................................................... 30
Figure 18 – Schema of the Template Data Document into an openEHR
composition. ................................................................................................................. 31
Figure 19 – openEHR Reference Model XSL. ....................................................... 31
Figure 20 – Key Value Store approach to store OCI entries. .............................. 40
List of tables
Table 1 – ADL language representation. ................................................................. 10
Table 2 – AQL example retrieved from (Beale, 2012)................................................... 11
Table 3 – Intra-institution storyboard narrative. .................................................... 20
Table 4 – Inter-institution storyboard narrative. .................................................... 20
Table 5 – JavaScript code to invoke java classes in Mirth. ................................... 25
Table 6 – Common elements present in two specifications. ................................ 26
Table 7 – XML configuration file for HL7 XSL’s transformers association. .... 33
Organization of the document
Introduction: The initial section of this document plays a very important
role, since it defines the starting point of the scientific problem concerning this
research work. Furthermore addresses comprehensively the several concepts
and components inherent to this work. Specifically addresses the following
matters: health information systems, heterogeneous systems, interoperability,
multi-agent systems health environment and health common standards;
Aim: Conventionally this section should be short and exact, notwithstanding
I had the initiative of detaching the aim of SAHIB aim from my thesis aim to
contextualize my personal target within the project;
State of art: This chapter presents the related literature relevant for each
work area. The state of the art is distributed according to the research outlines
which were followed in the preparation of this thesis, namely the employment
of the health standards HL7 and openEHR worldwide and the potential
approaches to transform HL7 messages into openEHR composition instances;
Material and Methods: At beginning of this work it was decided to analyse
and document the functionality of this system with UML use cases as well as
activity diagrams to describe the comprehensive workflows and procedures. It
was appropriate to perform a state of art about data integration among HIS’s
and interoperability concerns inside hospitals;
Results: This section intends to describe the relevant topics collected from
the several outcomes of this work. Such as UML diagrams, related to
architecture and workflows and even some examples as well;
Difficulties: In this section it will be listed the several difficulties faced along
these months of work. These difficulties have a technical and subjective nature;
Discussion: This chapter deals with all the main findings and the possible
interpretations of such findings. It is discussed the feasibility of using the
solution based on the result obtained from the prototype;
Conclusions and recommendations: The responses to the well-defined aim
are described in this section as well as a personal opinion about the use of
standards worldwide;
Future work: This work was a starting point consequently are described in
this section some considerations of future work to complement or even
improve what has been developed so far.
Outcomes
Published articles
Silva-Ferreira, P. R., Patriarca-Almeida, J. H., Vieira-Marques, P. M., &
Cruz-Correia, R. J. (2012). Improving expressiveness of agents using openEHR
to retrieve multi-institutional health data: Feeding local repositories through
HL7 based providers. Information Systems and Technologies (CISTI), 2012
7th Iberian Conference on (pp 1-5).
Unpublished articles
Silva-Ferreira, P. R. (2012). Avoid isolated knowledge concerning an
archetyped computerized physician order entry: An approach based on
metabolic transformations regarding distinct information reference models.
Center for Research in Health Information Systems and Technologies, Faculty
of Medicine - University of Porto.
1
1. Introduction
The initial section of this document defines as starting point to the scientific
problem concerning this research work. Furthermore addresses the several
concepts and components inherent to this work. Specifically addresses the
following items: health information systems, heterogeneous systems,
interoperability, multi-agent systems health environment and health common
standards.
Providing high-quality healthcare services is an information-dependent process
Physicians spend over a quarter (Audit Commission, 1995) and nurses half (Korpman &
Lincoln, 1998) of their time producing patient medical records. The sources required
for the exercise of evidence-based medicine are patient medical records, the
patient and published scientific evidence (Wyatt & Wright, 1998). The most honourable
usage of electronic health records is the improvement of the quality of clinical
decisions. The clinical information technologies introduced the capability to
improve the hospital medicine. Amarasingham wrote that among patients with
4 medical conditions (myocardial infarction, congestive heart failure, coronary
artery bypass grafting, and pneumonia) in a diverse group of Texas hospitals
Under inherent conditions, the reductions in mortality, complications, and costs
might be correlated with a high-level of HIS automation (Amarasingham, et al., 2009).
Providing all healthcare professionals complete, transparent and real-time
contact to patient information is a major challenge facing healthcare
organizations. Therefore, there is a major commitment to deliver efficient
integrated electronic patient records in order to increase the quality of
communication process between health professionals.
2
Safeguarding clinical meaning across high-interoperable heterogeneous systems
Typically within a healthcare organization, for supporting organization’s
processes exist numerous tools and there is a necessity to integrate these tools
in order to achieve an integrated and on-going process (Land & Crnkovic, 2003).
Nevertheless, integrating clinical IS improving communication and healthcare
delivery data, research and management, several distinct questions must be
addressed (Littlejohns, et al., 2003). Combining data from heterogeneous sources
consistently is a major effort, since the source information systems usually
contrast between themselves, such as appearance, functionality, terminology,
data representation and semantics (Lenz & Kuhn, 2002).
Is common-sense that nowadays healthcare is broadly shared. The increase
of prevailing integrated IS’s increases the patient information accessibility.
Distinct technological solutions coexist to integrate patient data, using different
standards and data architectures, which may decrease further interoperability
levels (Cruz-Correia, et al., 2007).
The reason for the enormous difficulty in solving interoperability problems
between different institutional IS in Portugal may be related with the same
difficulty found within each institution departmental IS. Achieving a broad
interoperability between IS in Portuguese HI’s is a major problem, essentially
because there are on average 21 different IS in Portuguese HI’s (Ribeiro, et al., 2010),
as well as the communication limitations between HI’s, deriving from untrusted
relations transforming them into isolated HI’s (Santos-Pereira, et al., 2012).
Binding Multi-agent systems features with healthcare vast exposed environment
An agent is a self-sufficient computer system positioned in a particular
environment, in order to accomplish its design objectives (Wooldridge & Jennings, 1995).
Reactivity, pro-activity and also their social ability is a well-known range of
characteristics reachable in agents. In recent years Multi-agent systems (MAS)
has materialized as an alternative approach to address the concerns in software
systems. The profit of MAS ascends from the inherent complexity of large
software systems, raising design concerns that orthodox software engineering
technology cannot handle like complex interaction and dynamic environments
3
(Lin, 2007). In distributed systems, interactive agents represent enhanced ways for
distributed problem solving.
Agents can process local data efficiently and communicate with other agents
when required if the tasks that they are executing are beyond their current
capabilities or resources. Several examples can be found regarding the use of
agents in the healthcare environment. In (Moreno & Nealon, 2004) the relation between
healthcare and agents is described as a “vast open environment, characterized by shared
and distributed decision making and management requiring the communication of complex
and diverse forms of information between a variety of clinical and other settings, as well as the
coordination between groups of healthcare professionals with very different skills and roles
making it an ideal ground to explore agent characteristics”. In Portugal it was
successfully implemented an agents-based systems which decreased human
organizational responsibilities, and significantly reduced the clinical data access
time as well as corrupted clinical data (Cruz-Correia, et al., 2005). Nowadays there are
several initiatives in Portugal of implementing interoperable services bases in
agents systems. Miranda designed multi-agent based HL7 interoperation
service, incorporated in an integration platform, which is implemented in
several HI' (Miranda, et al., 2010) s.
In the SAHIB development context, the MAS was developed with the Java
Agent Development Framework (JADE), which is an open source platform
written in Java to simplify the implementation of multi – agent systems (Jade, 2012)
through a middleware that complies with the Foundation for Intelligent
Physical Agents (FIPA) specifications and through a set of graphical tools that
supports the debugging and deployment phases (IEEE Foundation for Intelligent Physical
Agents, 2012).
The importance of using common standards for interoperability
Interoperability concerns arise from the sharing of clinical information,
which among healthcare professionals and IS’s in a healthcare environment (Chronaki, et al., 2003) (Blobel, et al., 2006) is assigned a significant degree of importance in
order to increase effectiveness and efficiency of medical services. To achieve
this, IS’s need to be integrated and be capable to exchange messages, i.e., to
interoperate.
The communication and collaboration can occur at distinct levels of
interoperability (Blobel, et al., 2006) (Beyer, et al., 2004). Bayer identified three fragments of
4
compatibility that allow IS’s with different data structure interoperate, which
are: data structure and encoding (syntactical compatibility), semantics level
(ontological compatibility) and instance semantics level (terminological
compatibility) (Beyer, et al., 2004). Syntactic compatibility defend that different
systems might use different encoding rules to bind their data structure; thus
syntactical transformation is essential to exchange data (Beyer, et al., 2004). Semantic
heterogeneity is challenging since two semantically different information
ontologies cannot be automatically integrated. In some cases requires the
revision of database schemas or further type of information ontology (Beyer, et al.,
2004). The employment of standards is the enhanced approach to achieve
semantic interoperability. Unquestionably, there are different standards for each
different range of software platforms, so it required the use of complementary
standards to achieve high-level of interoperability (Indarte & Gutiérrez, 2011).
To resolve the interoperability problematic in healthcare environment,
several standards are currently under development, in order to provide
specifications for exchange of clinical information (Yong, et al., 2008). In the vision of
Sean Muir “to enable a ubiquitous ecosystem where members of the Health and IT
professions can collaborate to build open, standards-based interoperable systems that enable
patients and their care providers to have access to vital and reliable medical information at the
time and place it is needed” (Muir & Lord, 2012). The European Commission report on
interoperability explains further that successful interoperability will be based on
common standards "Commission shall, in accordance with the procedure referred to in
Article 40(2), adopt detailed rules for the implementation of paragraph 1 of this Article with
a view to facilitating the interoperability of information systems and use of procedures by
electronic means between Member States, taking into account common standards developed at
Community level." (European Commission, 2010). Furthermore, to attain interoperability in
the context of e-Health services, guidance needs to focus on open standards.
The European Commission claims that the focus of the e-Health services
characterization should be concentrated on the definition of the interoperability
framework instead of the choice of technology.”epSOS LSP participants should
render access to e-Health services independent of any specific technology or product. This is the
purpose of choosing standards and protocols when deciding the interoperability framework” (European Commission, 2010).
5
The timeline of Health Level 7 history
Health Level 7 (HL7) is a well-established message-based standard
developed (in a full consensus process) by the American National Standards
Institute (ANSI) accredited standards developing organization Health Level 7
Inc. The ANSI goals are related with develops comprehensive and extended
standards for the exchange, management and integration of electronic
information in the clinical and administrative domain (Health Level Seven International,
2007). Level 7 of HL7 refers to the Application Level of the OSI seven layer
model. This level describes how data are exchanged and the timing of the
interchange as well as the handling communication of errors (Health Level Seven
International, 2007) (Datta, 2010). In the USA over than 90% of healthcare facilities (Shaver,
2007) use HL7 as well as 32% (Datta, 2010) of the total HL7 membership are from
USA. According to Health Level Seven International, HL7 version 2.5 is the
most widely implemented standard for the healthcare information worldwide.
Before HL7 was introduced, HIS’s were developed with low degree of
interoperability, i.e. there was no cooperation between the various vendors and
consequently for two HIS’s to interoperate, where implemented specific
customized interfacing systems (Corepoint Health, 2010) (Shaver, 2007). HL7 develops and
preserves two messaging standards: HL7 version 2.x and 3.0. HL7 version 3.0 is
a 2.x version an improvement (Health Level Seven International, 2007) without backwards
compatible, since the legacy issues were excluded (Corepoint Health, 2010).
HL7 comprehends various uncompelled data segments, therefore is a very
flexible specification. However, is unbearable to guarantee a standard
conformance of any vendor’s implementation. Consequently there is an
increase of implementation effort, since the vendors might dispense further
resources to analyse and plan both parties interface (Health Level Seven International, 2007).
The high consumption of HL7 version 2.x addressed to HL7 version 3.0 a set
of inconsistencies and absences presents in the previous model, such as in the
application data model, the lack of a formal methodology to model artefacts
and the absence of a well-defined application user roles (Corepoint Health, 2010). HL7
version 3.0 leverages an object-oriented development methodology based on a
data model, the Reference Information Model (RIM) to create plain messages.
RIM provides an explicit representation regarding semantic and lexical
relationship which occurs between the information transmitted through HL7
version 3.0 messages (Health Level Seven International, 2007).
6
Figure 1 – Health Level 7 timeline.
The Figure 1 shows the extended Health Level 7 timeline that began in 1986
with the HL7 membership board first meeting (Datta, 2010).
This work outcome addresses only the HL7 version 2.5.1 which is a widely
adopted ANSI standard.
Overview of the health standard openEHR formalism
OpenEHR refers to the openly accessible engineering specifications to build
full driven EHR systems and also to the governing entity – the openEHR
Foundation (Kalra, et al., 2005). The openEHR formalism is focused in the Archetype
paradigm which is an approach of assembling formal domain models through
implementation of constraints addressed to a common reference information
model (RM) (Beale & Heard, 2007). Consequently the methodology is conventionally
known as Two-Level or Multi-Level Modelling (MLM) (Kalra, 2006). A current
analogy to understand how RM, archetypes and terminologies are related to
each other is consuming a partial set of standard LEGO® blocks to assemble
several different structures (Figure 2) (Beale, 2007) (Verlinden & Siegert, 2012). The domain
knowledge is clearly disjointed from the technical environment enabling to
isolate responsibilities of developers and domain specialists (Garde, et al., 2007). The
main foundation of the formalism regarding the GUI is that openEHR MLM
delivers the standard resources to manage GUI and persistence layers
consistently in HIS.
7
Figure 2 – Schematic representation of the openEHR Multi-Level Modelling Paradigm.
Contrasting hard-coded definitions, the MLM are expressed through RM,
Archetypes and Templates to generate runtime functions and GUI software in
real time. Therefore if there is a necessity to perform modifications to GUI
software is not necessary to be redesigned, coded, tested and deployed (Beale, 2002).
RM comprises a trivial set of object oriented classes which portrays the
generic data structures and types of health records, as well as the instruments to
describe context information to meet ethical, medico-legal and provenance
requirements (Mulligan, et al., 2006) (Kalra, et al., 2001).The well-known use case of the blood
pressure measurement will be represented as an instance of RM
OBSERVATION class, which is a sub-class of ENTRY class (Ocean Informatics, 2008).
These classes can reliably capture results of all collected medical entries with
essential contextual information such as cuff size of a sphygmomanometer and
position (i.e. sitting, lying) in order to perform an accurate medical
interpretation (Garde, et al., 2007) (Schloeffel, et al., 2006). The established and well-defined
RM objects are usually associated to individual GUI widgets; such as a
CLUSTER container data structure which can be designed with a frame around
its children elements, or the DV_TEXT data type which corresponds to a text
box control or a drop down list (Ocean Informatics, 2008). Therefore is expected that
the employment of standardized visual elements delivers GUI consistency and
extensibility.
8
Figure 3 – The openEHR information model from the openEHR site http://www.openehr.org/.
Archetypes provide the full semantics and structure of clinical domain
concepts by constraining pertinent classes from the RM (Leslie, 2008) and
consequently these are employed as building-blocks to comprehend a computer
processable clinical model (Verlinden & Siegert, 2012). Essentially are described specific
record entry names, data structures, data types, prescribed value ranges and
values for some of the context characteristics (Ocean Informatics, 2008). Archetypes
provide two critical features GUI production: a) assists domain specialists in the
requirements specification of the information apprehension with developer’s
independency; i.e. definition of clinical forms; b) allows powering the massive
amount of standardized terms and semantics through biomedical terminologies
networking – consequently guaranteeing consistency within and among HIS
which may be predictable an increase of control of the changeability and
variability in Medicine (Linden, et al., 2009) (Garde, et al., 2007) (Chen, 2009). Above Archetypes
layer could exist one or more layers. Templates which assemble several
Archetypes and further constrain them. During the implementation phase,
the templates deliver the resources to automatically generate the GUI. These
9
combine a set of archetypes, terminologies, language and further details for
confined employability. Templates can be employed for designing screen forms
as well as persistence models (Linden, et al., 2009).
Available archetype persistence methodologies
As explained above, archetypes allow describing specific clinical concepts
through constraint rules. The collected clinical information through the
archetypes templates produce a Composition, which corresponds to one clinical
document. Beale (Beale, 2002) describes how the template guides the design of the
GUI used to create and edit a well-defined chunk of clinical information. This
chunk of information is known as a composition (e.g. blood pressure). The
storage of this composition along with other additional template-based
compositions (e.g. demographic details) stems a complete EHR. Thereby is
possible to capture as much information about a specific and distinct clinical
concept as conceivable. An example of a simple archetype is WEIGHT, which
can be applied in multiple circumstances, wherever is required within an EHR.
In order to achieve persistence with openEHR Archetypes it could be
consumed by EHR systems the Archetype Definition Language (ADL)
representation (The openEHR Foundation, 2007). ADL is a language specifically developed
for a word-based representation of archetypes. Therefore with ADL is possible
to describe the components of an archetype: descriptive data, constraint rules
and ontological definitions (Figure 4).
10
Figure 4 – ADL representation of the Archetype structure.
The ADL representation has exclusive formal language, which can be
interpreted through ADL parsers. Another possibility is the representation of a
openEHR composition though XML, which can be converted into the ADL
formal language and vice versa (The openEHR Foundation, 2007).
Table 1 – ADL language representation.
ADL Syntax
archetype (adl_version=1.4) openEHR-EHR-OBSERVATION.blood_pressure.v1 concept [at0000] -- Blood Pressure language original_language = <[ISO_639-1::en]>
XML Syntax <archetype xmlns="http://schemas.openehr.org/v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <original_language> <terminology_id> <value>ISO_639-1</value> </terminology_id> <code_string>en</code_string> </original_language>
11
Archetypes are placed between knowledge resources in a computing
environment, such as terminologies and ontologies, and runtime data in
production systems. Their primary purpose is providing a reusable,
interoperable method of handling data production, validation and querying (The
openEHR Foundation, 2007). There is a specific language for querying archetype-based
EHR’s. Archetype Query Language (AQL) (Beale, 2012) has been developed by
openEHR for querying archetype-based EHRs. AQL is used by developer level
users (skilled users). Its syntax is complex. It requires more skills than SQL and
XQuery, which are at application level. It also requires the knowledge of ADL
path (Sachdeva, et al., 2011).
Table 2 – AQL example retrieved from (Beale, 2012).
AQL example SELECT o/data/events[at0002]/data[at0003]/items[at0004]/value FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnitude>n AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min'
The query statement exemplified in the Table 2 extracts all the respiratory
rate of the observations instances with respiratory rate greater than n. The
single letter 'o' is the observation class variable name,
"/data/events[at0002]/data[at0003]/items[at0004]/value" is the archetype path
to respiratory quantity node.. '$ehrId' is the parameter name which can be
substituted with real EHR ehr_id value at run time. The query language
supports parameterization.
12
2. Aim
The objective of this work is to define an architecture that allows agents to
seek and collect health data from an HL7 based IS that exist in external HI.
This objective is sub-divided in: a) being able to have a semantically rich
description of what data the agent is seeking (openEHR); b) querying and
returning data of the existing IS with common communication standards
(HL7).
SAHIB aim
Since this work was developed within the SAHIB project, is significant to
reveal his investigation goal. So the objective of the project is to contribute for
the improvement of health data availability at the point of care. “The question to
be investigated in this project is how to build applications that find, retrieve and deliver patient
information to the point-of-care in a secure and timely fashion, even though it is distributed
across multiple healthcare institutions, whilst safeguarding the different agendas and
constraints of the different actors. In a regional or nationwide scale scenario where a multitude
of IS coexist there is still currently a lack of supporting architectures that can provide an
efficient way for clinical data finding and retrieving making it available at the point-of-care.” (Cruz-Correia, 2012).
13
3. State of art
This chapter presents the related literature relevant for each work area. The
state of the art is distributed according to the research outlines which were
followed in the preparation of this thesis, namely the employment of the health
standards HL7 and openEHR worldwide and the potential approaches to
transform HL7 messages into openEHR composition instances.
HL7 and openEHR worldwide
The Figure 5 shows an overview of the main health standards worldwide,
with special focus on the HL7 and openEHR. In accordance with Ganslandt (Ganslandt, 2009), the openEHR is a standard that can achieve a huge success rate.
He says also that the open development of standards and specifications delivers
immediate feedbacks to technological progress and ensures that standards will
encounter the market demands. The focus on interoperability enhances the
ability of openEHR to respond and adapt to technological developments. Hoy (Hoy, et al., 2007) wrote that “There is growing interest in the development of standards which
structure information round discrete clinical concepts, in a way that supports system
development and interoperability. Most notable are the openEHR Archetypes and Templates,
and HL7 Templates”. This sentence is very relevant considering the current
background of the existing health standards.
14
Figure 5 – Standards development organizations (Ganslandt, 2009).
Datta (Datta, 2010) reveals that HL7v2 (in its various subversions, usually
represented generically as HL7v2.x) has a global acceptance and is currently and
widely used within the several national health systems for messaging
applications. Notwithstanding openEHR are being embraced by several
countries like Brazil (The openEHR Foundation, 2011), Australia (The openEHR Foundation , 2010),
Sweden, etc. (The openEHR Foundation, 2007). Schloeffel (Schloeffel, et al., 2006) confirms that a
couple years ago: “a proposal has recently been made to the Standards Australia IT-14
Health Informatics Technical Committee to develop an Australian Standard for a Shared-
EHR system architecture based on openEHR”. Hajar (Kashfi, 2011) reveals some
interesting conclusion in his literature review. He wrote that the HL7 has a
higher level of adoption than openEHR. In fact, he affirms that applying
openEHR in development of clinical applications is nevertheless uncommon.
He describe as well a list of the possible barriers faced in the low adoption of
the openEHR, for instance "…openEHR is naturally complex, and this complexity is
not unexpected since openEHR is considered to be a solution for a complicated problem (i.e.
interoperable future-proof EHR) in a complex domain (i.e. the clinical domain). For instance
the powerful archetype model allows expressing complex clinical concepts, therefore, an
inexperienced archetype developer should expect to spend some time on learning the openEHR
concepts. Additionally, getting a grip on the current specifications (more than 1000 pages),
UML diagrams and code documentation is challenging…" (Kashfi, 2011).
15
Transform HL7 messages into openEHR composition instances
The relation between these standards is brand-new, nevertheless there are
already several efforts related to this matter. For instance, in 2011 it took place
a meeting in Sydney, generating a closer cooperation between HL7 and
openEHR (Ringholm, 2011). Regarding the conversions between these two standards,
there are several related works as well. Through a brief and straight research are
easily found two common and distinct approaches, the first is based on
ontologies mapping and the second is based on metabolic conversions. The
first approach focus on ontology matching tools to resolve the data level
heterogeneities between different healthcare standards and achieve message
schema level conversion (Khan, et al., 2012) (Ryan & Eklund, 2009). The second approach
pursuit for harmonize the two models through metabolic templates with the
same structure of an archetype template, providing openEHR compositions (Frankel, 2011) (Leslie, 2009).
Although these approaches are completely distinct they are entirely valid and
reasonable, therefore the second approach was engaged as instance in order to
accomplish this work.
Analysing and express intra and inter institution workflows
The beginning of this work it was decided to analyse and document the
functionality of the implementation communication module with other systems
though UML use cases and activity diagrams to describe the comprehensive
workflows and procedures in the intra and inter HI’s environments. UML is a
standardized modelling language which concerns object-oriented software
engineering, used to specify, visualize, modify, construct and document the
artefacts of an object-oriented software-intensive system under development (Booch, et al., 2000).
16
Compliance of health standards employed
The requirement to manage common input data brought us to a well-known
standard, HL7 is a healthcare standard developed by the Integrating the
Healthcare Enterprise organization (IHE), which provides a shared data model
and communication between HIS’s without losing the clinical significance (IHE
International, 2012). This standard permits exchanging semantic information between
heterogeneous HIS’s. A wide range of materials as well as information about its
standards are available on the openEHR foundation website (openEHR, 2007). The
Clinical Knowledge Manager (Ocean Informatics, 2007-2010) is a recognized portal for
those who wish to contribute at any level in the authoring of clinical archetypes.
In this portal anyone can verify what has already been developed, as well as
participate in the development/update of the existing archetypes. The
compliance between these standards is more than an unassuming manifest,
currently there are several energetic collaboration initiatives between these
distinct standards organizations, e.g. like in Australia which is conducted by
HL7 Australia (“HL7 Australia Inc. is a not-for-profit Association incorporated in the
Australian Capital Territory under the Associations Incorporation Act 1991.”) (HL7 Australia
Inc, 2006).
17
4. Material and methods
At beginning of this work was decided to analyse the functionality of this
system with UML use cases as well as activity diagrams to describe the
comprehensive workflows and procedures in the intra and inter HI’s
environments. It was also performed a state of art about data integration
among HIS’s and interoperability concerns inside hospitals.
Open source interoperability framework
Mirth is an open source ESB (Lapeira, 2010) independent platform, oriented to
HL7 messaging. Transmission of data is designed through channels, which are
configured in a graphical interface. These channels are input and output
connectors, filters and transformers (Mirth Corporation, 2012). Currently the supported
connectors are: MLLP, DB, JMS, SOAP, FILE, PDF, FTP, and SFTP. Using
the GUI is possible to select which filters and transformations are applied to
the incoming message before sending it as output (Gutierrez & de Barros, 2008).
Figure 6 – Mirth channel architecture.
18
It is possible to define filters using Java/JavaScript code, as well as access
the contents of a message thru templates. This can be very useful if is intended
to filter, e.g. HL7 messages as a specific attribute. The Transformers (custom or
not custom) are used to extract information from the message, after the XML
conversion. The Mirth provides the ability to create not only simple channels
(one input connector, and one output), but multichannel output connectors,
enabling the design of broadcast or simple routing. The broadcast is prepared
by sending the message, after filtering and transformed, to several output
connectors. The message routing to different applications, could be
accomplished by defining for the same input connector, a set of output
connectors each with its filters and transformers. Achieve more complex
routing and transformations is feasible, like organize internal connectors linking
to Mirth, i.e. defining an output connector to send the message to one of the
input connectors defined.
Figure 7 – Different approaches for data flow in Mirth.
For the realization of this project was chosen the Mirth as ESB due his
simplicity in the integrations developments, since it is possible to define the
communication channels through the interface, and also monitor the posted
messages and errors. Moreover, to define validation rules easily and filtering
messages according to data coming defined in HL7 specification.
19
Software development process methods
The suitable development method for this project seemed to require Agile
characteristics, since we need to have software development methods based on
iterative and incremental development (Barlow, et al., 2011). So was adopted the
Maven philosophy which apply patterns to a project's build infrastructure in
order to promote comprehension and productivity by providing a clear path in
the use of best practices (The Apache Software Foundation, 2002-2012). Maven is a project
management software instrument based on the concept of model object-
oriented projects (POM) which simplifies the management of dependencies as
well as software availability and distribution. The Maven Build empowers the
concept of software building, allowing specifying the profiles and the goals of
the software project build, like test, install and generate-sources.
Maven provides sustained support for such a project organization though
multi-modular projects. Multi-modular projects consist of a "Parent Project
which contains “Child Projects" or "Modules" (Figure 8). The parent project's
POM file contains references to all these sub-modules. Each module can be of
a different type, with a different packaging value.
Figure 8 – Parent prototype project pom.xml.
Maven makes unit testing and integration testing an integral part of build
lifecycle, thus enabling individual programmers and teams to easily implement
the practice of test driven development process (TDDP), which introduced
little iterative development cycles, that means that we first wrote a failing test
case, then we building each software functionality by code refactoring. “The test
20
driven development process involves producing automated unit tests for production code before
you write that production code. Instead of writing tests afterward (or, more typically, never
writing those tests), you always begin with a unit test. For every small chunk of functionality
in production code, you first build and run a small, focused test that specifies and validates
what the code will do.” (Agile Sherpa, 2012). In accordance with these development
methodologies, it was developed a prototype in Java (within Maven plugin (The
Apache Software Foundation, 2012)) of the SAHIB conversion and storage module.
Predicting some storyboards and use cases
One of the initial tasks was to describe some storyboards more real as
possible. It were described some scenarios for two distinct scopes: intra-and
inter-institution. Despite the inter-institution scenario not be included towards
the primary goal of this project was however taken into consideration.
Consequently is described in the Table 3 and Table 4 the two distinct scope
scenarios.
Table 3 – Intra-institution storyboard narrative.
Intra-institution storyboard A victim of a car accident enters the emergency department at the Hospital São Rafael Porto. After the appointment the doctor orders blood tests in clinical pathology service and a radiology exam to radiology service. The information resulting from the information systems of both services, respectively Laboratory Information System and Radiology Information System, is sent automatically via Health Level Seven (HL7) to the HL7 server which converts this structured information in the openEHR repository.
Table 4 – Inter-institution storyboard narrative.
Inter-institution storyboard An orthopedic physician attends a patient at the Hospital José Nascimento in Penafiel. That appointment is a follow-up visit to a victim of a road accident postop right leg. The doctor decides to check the results of radiological images to the right leg of the patient before the operation to compare the radiological examination after surgery in possession of the patient. The doctor accesses the images on the openEHR repository in the Hospital of St. Raphael of Porto, due to the availability of health data multi - institutional through the multi - agent systems.
The intra-institution environment concerns with the procedures of
collection and storage of clinical information that is generated by the HIS’s in a
particular HI. The inter-institution environment is related to the access and
21
availability of the information generated by HIS’s presents in the previous
environment.
In the Figure 9 and Figure 10 are exposed the two UML use cases which
correspondingly define the cases and communications existent in the previous
storyboards.
Figure 9 – Intra-institution environment use case.
Figure 10 – Inter-institution environment use case.
22
5. Results
This section intends to describe the relevant topics collected from the
several outcomes of this work. Such as UML diagrams, related to architecture
and workflows and examples.
General architecture
An HL7 compliant system cannot directly communicate with an openEHR
compliant system. Therefore it was essential to design a methodology for
metabolic transformations of data. This occurs from HL7 messaging in order to
produce compositions openEHR. The intention was to retrieve and deliver
EHR, using openEHR with MAS. The challenge was to explore agent’s mobile
capabilities of network travelling and retrieve patient data at each institution.
The use of openEHR standard information model enables the employment of
AQL and an openEHR Repository at each institution for patient data.
Figure 11 – Multi-agent System for the exchange of healthcare data.
23
The MAS will have local agents that will represent different actors and a set
of query mobile agents that will travel to other HI, searching for patient data.
An actor (user or process) will trigger the search and retrieval of patient data.
When the search is triggered the MAS will create and attribute a local agent to
the actor. Depending on the profile of the actor, e.g. its department, role,
context of care, etc., a specific openEHR template will be associated with the
actor along with a set of queries that will be derived from that template and the
demographic data for the current patient, that will be retrieved from the
Hospital Information System (HIS). The generated queries will be attributed, by
the local agent, to a set of query agents that will be created at this moment for
the searching tasks. The query/mobile agents will search in multiple HI,
traveling to the agent platforms of the various HI and communicating with
local agents. The mobile agents will query a local agent for patient data using
AQL queries. The local agent will receive the mobile agent's queries and query
the institutional openEHR repository, responding with the patient data.
Intra-institution designing architecture approach
The architecture approach takes advantage of exploring the feasibility of
computing transformation methods applied to a clinical data source model in
order to store this information into an openEHR repository, enhancing multi-
institutional health data availability through MAS developing a structured and
standard EHR repository with formal capabilities of AQL, supporting MAS in
patient data search.
Figure 12 – Intra-Institution designing architecture.
24
In the public Portuguese HIs there are a substantial and heterogeneous set
of IS with low interoperability capabilities, in fact there isn't any standards
usage evidence in IS implementation (Ribeiro, 2011), becoming significant concerns
towards our architecture. Our approach was to import health data from the
several local departmental information systems (DIS) from a common data
source input. Therefore this platform will interact with the DIS using the HL7
messaging standard.
Consuming HL7 messages as data source input
In order to process machine-readable format, the received HL7 ASCII
messages are converted to HL7 XML, generating a representation of the HL7
message data structure. This was accomplished using the integration
component such as Mirth and invoking the implementation environment with
the HL7 XML as argument. The implementation knowledge environment is
composed with a Mirth server for receive HL7v2.x messages and Java packages
(JAR's) that constitute the conversion module, converting the HL7 messages
into OCIs. The Figure 13 illustrate the several components presents in the
module with the respectively Maven packaging types.
Figure 13 – SAHIB reception module components diagram.
Since Mirth allows invoking Java classes from a JavaScript connector, it was
relatively simple to deploy these classes in order to use them in Mirth. It
25
required just releasing the JAR packages into Mirth custom libraries folder and
after a reboot these classes are completely available. The invocation of Java
classes is prepared with the code presented in Table 5.
Table 5 – JavaScript code to invoke java classes in Mirth.
Mirth JavaScript invocation code var ud = new Packages.pt.cintesis.conversion.engine.Invoke("messageConversion"); var ret = ud.executeCommand( messageObject.getRawData().toString());
In order to read, parse, serialize and validate HL7 messages it was used an
open source HL7 API for Java (HAPI). HAPI is an open-source, object-
oriented HL7 2.x parser for Java in conformance with HL7 specification (University Health Network, 2012).
Achieving data integration through template data schema
A Template Data Schema (TDS) is a XML schema representation of a
clinical template using domain concepts (Frankel, 2011). TDS is used by non-
Archetyped based systems as an intermediate data format to communicate
Archetype-based Clinical Documents, which is derived from a Clinical
Template using generic rules based on Archetypes and Reference Model (RM).
The TDS assigns the effort of mapping data from the reference model
concepts to the domain (clinical) concepts, performing semantic
transformations. Enables consistency and integrity of the domain concepts to
be maintained during the course of the data integration process and supports
semantic interoperability between systems using different Reference Models.
26
Table 6 – Common elements present in two specifications.
hl7v2.5 oml^o21 openehr-ehr-instruction.request-lab_test.v1.
orc.2 placer order identifier
entity identifier text requestor identifier
orc.3 filler order identifier
entity identifier text receiver identifier
obr.4 universal service identifier
coded element text test requested
orc.7.6 quantity/timing priority
timing/quantity coded text urgency
obr.6 requested date/time
time stamp date/time datetime test preferred
orc.1 order control orc.5 order status
coded values for hl7 tables
text request status
Comparing between an Instruction Archetype regarding the request of a
laboratory test and the xml schema of the message HL7v2.5 OML^O21, are
clearly identified several common elements that aim to identify the same type of
information. In the Table 6 are enumerated some common elements of the two
specifications. This table reveals some findings concerning direct mappings
between the several elements that constitute the two distinct specifications. The
openEHR RM data types can be straightforwardly mapped to the HL7v2.x data
types, as well as the concepts related in each elements.
Using template data schema to produce a template data document
The Template Data Document (TDD) is an XML document (e.g. laboratory
report) populated with data from the content source, in compliance to a
template data schema. The TDD is validated against the Template Data
Schema (TDS) generated from a template designer, which extends the
document with fixed and default values defined in the schema.
27
Figure 14 – Schema of the message source system transformation into templates data documents.
The Figure 14 exemplifies the schema of the input and output of the
content – based transformation mechanism. The TDD conversion could be
overlooked but using it provides a more concrete domain model of the
converted message which allows the use of standard XML schema validation
tools to catch about 95% of the structural errors without the constraint for
specialized openEHR validation tools (Frankel, 2012).
Designing of the conversion module activity statechart
The state machine designed for the prototype is shown in Figure 15. This
diagram expresses the different states, decision points and transitions relative to
the SAHIB conversion module. To make interpretation easier of this diagram,
it was separated in 3 groups. The first is related to the reception and validation
of HL7 messages which are received by the Mirth and subsequently are
converted into HL7 XML. The second group is responsible for the
transformations (two distinct types of transformations) designed to transform
an HL7 message XML into an OCI. The third refers to different states and
transitions present in the storage of clinical data into an openEHR repository.
28
Figure 15 – Activity statechart of the receiving and conversion module.
29
Metabolic template data schema to produce a template data document
The metabolic transformations from a HL7 ASCII input message using a
TDD conversion, are associated to its nature applied in this context should be
interpreted as metamorphose or transformation, have a logic sequence
presented in the Figure 16 by a snapshot with small fragments of a Unsolicited
Observation Results (ORU^R01) message (HL7) and consequently fragments
of the sequence. The first phase implies to transform HL7 ASCII into a HL7
XML message, which in this case is valid against a ORU^R01 XML schema.
The second phase involves applying the TDS towards the HL7 XML content.
Figure 16 – Metabolic TDD conversions snapshot.
The second phase produces a TDD instance that is validated against its own
XSD, for instance Laboratory_report.xsd. Analysing more concretely this
image, the snapshot converted is the HL7 Observation Request Segment
(OBR) which identifies the requestor of the observation as well as the
observation identification (Universal Observation Service Identifier). The
highlight of this example is to exemplify the Placer Order Identifier which is
equivalent to the value 356102 (OBR.2.1). Notice that the Placer Order
Identifier was converted in the TDD instance to the element named Request
Identifier with the same value (356102).
30
Figure 17 – openEHR CKM mindmap of the archetype openEHR-EHR-
OBSERVATION.lab_test.v1.
To better understand the relation, a mindmap of the archetype openEHR-
EHR-OBSERVATION.lab_test.v1 was taken from the openEHR CKM (openEHR, 2010). Notice that the first element of the archetype Protocol is the
Requestor Order Identifier, which CKM description for this element is “The
local ID assigned to the order by the order requester. Equivalent to the Placer Order
Identifier“. This archetype component is equivalent to the TDD element Request
Identifier, because the TDS provides a transformation based on a XML schema
which is a representation of an openEHR archetype template.
Conversion of a template data document into an openEHR composition instance
The conversion to an openEHR Composition Instance (OCI) is the second
transformation of this method. The validated TDD is then transformed using a
TDD to openEHR composition transform that can be used for any template
exported. This TDS is a generic openEHR RM XSL converter.
31
Figure 18 – Schema of the Template Data Document into an openEHR composition.
The generic openEHR RM XSL converter is a generic map from any
template data document to openEHR instance, developed with the
openEHR.NET project which is a C# implementation of openEHR Reference
Model (RM) and Archetype Model (AM) specifications (Frankel , 2011).
Following the example given in the Figure 16 it is possible to observe in the
Figure 19 the last transformation that occurs in the reception module. The
exposed openEHR RM XSL slice tries to match XML elements of the type
ELEMENT and select the value and name of the element. This in this case is
related with the Archetype Protocol component requestor order identifier.
Figure 19 – openEHR Reference Model XSL.
32
Link patient to openEHR composition instances
Since the storage of openEHR compositions leads to the storage of clinical
information from multiple clinical data sources, it is essential that each of these
compositions is linked to a patient, since each instance is assigned to a patient.
It is essential the identification of the clinical information of a patient, so the
demographics data could be discarded keeping exclusively the unique patient
identifier such as the number (e.g. Portuguese national health system). This
identifier could be the Master Patient Index (MPI) that provides openEHR
instances indexation. The rule is reasonably simple and makes sense within this
framework, i.e., for each instance stored should correspond a MPI binding,
enabling an evolution of information indexed by MPI.
Conversion HL7 template data schema configuration
Since TDS is customized for each HL7 v2.x type of message and version it
was necessary to associate a TDS to a message type and version thru
configuration. Therefore it was developed a XSD for the association between a
particular TDS and an HL7 message. This file allows also configuring the active
openEHR RM XSL for a given HL7 message.
33
Table 7 – XML configuration file for HL7 XSL’s transformers association.
ConversionHL7TemplateDataSchema.xml <ConversionHL7TemplateDataSchema Version="1.0.0" xmlns="http://cides.med.up.pt/Projects/SAHIB/openEHR/ConversionTemplateDataSchema"> <ConversionHL7TemplateDataSchemaItem> <HL7MessageHeader xmlns="http://cides.med.up.pt/Projects/SAHIB/openEHR/ConversionTemplateDataSchemaDataTypes"> <MessageType>ORU</MessageType> <MessageEvent>R01</MessageEvent> <MessageVersion>2.5</MessageVersion> </HL7MessageHeader> <TemplateDataSchemaHeader Version="1.0.0" Active="true" xmlns="http://cides.med.up.pt/Projects/SAHIB/openEHR/ConversionTemplateDataSchemaDataTypes"> <TemplateName>OruToLaboratoryReport.Hl7.xsl</TemplateName> <TemplateUri>/template.data.document.adapters/xslt/</TemplateUri> <TemplateUTC>2012-03-6T14:56:00</TemplateUTC> </TemplateDataSchemaHeader> <TemplateCompositionSchemaHeader Version="1.0.0" Active="true" xmlns="http://cides.med.up.pt/Projects/SAHIB/openEHR/ConversionTemplateDataSchemaDataTypes"> <TemplateName>TDD_to_openEHR.xsl</TemplateName> <TemplateURI>/open.ehr.adapters/</TemplateURI> <TemplateUTC>2012-03-16T14:56:00</TemplateUTC> </TemplateCompositionSchemaHeader> </ConversionHL7TemplateDataSchemaItem> </ConversionHL7TemplateDataSchema>
When Mirth invokes the Java module to execute a command (reception of
an HL7 message), this file is loaded and serialized to the Java class
ConversionHL7TemplateDataSchema. After parsing, validating and serializing
the HL7 message in order to execute a search for the active XSL files related
with the HL7 message type and version. Notice that this configuration file is
employed in the reception component group presented in the Figure 15.
34
6. Difficulties
In this section it will be listed the several difficulties faced along these
months of work. These difficulties have a technical and subjective nature.
Related with personal difficulties I consider that I faced only one, which was
the lack of knowledge in openEHR contrasting with 6 years of experience in
the implementation of HL7 interoperability interfaces. The first contact made
with the openEHR, was in several disciplines of the masters course. These
contacts caused me curious enough to consequently begin to produce some
works around this subject. During the period of developed work, I decided to
accomplish an openEHR online course in order to strengthen my knowledge in
the openEHR standard, which was needed to develop this work.
In relation to technical difficulties, these were more than many. I describe
what I think the most relevant and tried to be careful about their chronological
order: a) since early I noticed my poor experience in scientific research. I
realized how challenging and demanding is to seeking scientific literature,
moreover if you know in advance that this theme is underexplored. Yet the
discipline of initiation into scientific research was very helpful. I tried to apply
the retained knowledge of research which supported a methodically literature
research; b) having chosen the prototype architecture approach I stumbled in
the XSL transformations complexity. Regarding that the HL7 XML to TDD
transformation requires a single XSL, which just transforms one HL7 message
type/version, I early concluded that it required a great effort and knowledge in
the implementation on this type of conversion; c) when I was testing small
blocks of code through unit testing (TDDP), namely transforming HL7 XML
into a TDD, the configuration of this test comprised the assignment to an input
variable of a XML representative of a HL7 message in conformance and
validated by HL7 XSD's. For each Maven build this test was succeeded (Maven
has the capacity to execute the JUnit (Java unit tests) tests in the project. If the
output of the tests is failure then Maven gives compilation error). When I
35
developed a component responsible for processing HL7 ASCII to HL7
(through the Hapi library) I found that the transformation from XML to HL7
TDD was not successful concluded. So I noticed that the unique available XSL
applied in this transformation was prepared to transform only an XML
unofficial, whose schema owns to Mirth. To overcome this problem I
generated a XSL from the original, but instead to be prepared to read a valid
HL7 XML; d) another difficulty which I think is interesting to reveal, is related
with the questions towards the presentation of the paper at CISTI'12. This
question was said by a conference moderator: “Although the worldwide employment
of the HL7 standard, the implementation between different HIS's could be a problem. How
do you prepare for this circumstance?” This question is more than obvious, certainty
that the implementation of this type of systems leads to HIS's vendors own
interpretation and implement the standard in a suitable way. In the prototype
implementation approach this problem may be overcome if the XSL's
incorporate various possible values and condition rules for a given field.
36
7. Discussion
This chapter deals with all the main findings and the possible interpretations
of such findings. It will be discuss the feasibility of using the solution based on
the result obtained from the prototype.
Introductory objectives discussion
We conceived and tested a solid architecture that allows storing health data
designed for each HI. All the data generated by the several HIS’s existing in the
various health hospital departments are collected, converted and stored using
openEHR. Using this standard allows data storage and querying regarding full
semantics and structure of clinical domain concepts.
As previously mentioned, this work scope is related with the task
“Implement communication with other systems” of the SAHIB project.
Through HL7 message-based integrations it is possible to established
asynchronously interactions, enabling HIS’s sharing health information. Using
HL7 standard empowered this communication since allows to predict syntax
and semantic of all received health data.
Feasibility of HL7 messages as input
As initial prototype there was the necessity to homogenize the data source,
the purpose was to define a single standard for the conversion into openEHR.
In this sense we selected the HL7 standard having in mind three factors:
nowadays is a standard widely used in the Portuguese panorama; we have
previous knowledge of this standard; sustain for clinical data representation.
We decided to implement communication of the health data thru a health
standard (HL7). Initially one of the possible methods described in the SAHIB
37
to implement this task was thru web services. Despite its high-competence to
integrate several independent systems, there is an assumption that every system
will be speaking the exact same language and dialect. Implement
communication between two different systems could be straightforward, but
making these systems understand each other isn’t. This was the main reason
choosing the HL7 standard, in order to implement communication with other
systems.
Archetyped conversions customized through template data schema
The HL7 XML documents populated against a Template Data Schema are
turned into pure openEHR, without losing any semantics. The schema provides
enough constraints to get a non-openEHR developer started. A template is a
technical knowledge artefact designed for a particular use case, to support the
implementation. Since the TDS is basically a set of XML elements with
archetypes names and with the same structure of an archetype template, which
does offer full benefits of using archetypes and makes the system more
adaptive.
Necessity of storing queryable EHR data
An important requirement in our work was to provide agents with a
common language for the EHR retrieval, sharing knowledge using an agreed
language, within system's constraints like time period. The decision of using an
openEHR repository guided us to the appliance of a declarative query language
developed specifically for expressing queries used for searching and retrieving
the clinical data found in archetype-based EHRs.
Yet another conversion approach
This work was performed according to one of the possible approaches. I
think that should be notice that in addition to those described above there is
another feasible approach. Since we are interested in the received HL7
messages data and we know afterward the data structure that you want to
convert could be achievable a common straight objects conversion by
38
computational methods. That is, having access to objects that support the
generated clinical information, it is possible to create generic mappings between
different domains objects. This approach can have more sustainability since
there are computational libraries that implement the different domains related
to the HL7 and the openEHR. In the case of HL7 was used in this prototype a
Java library (Hapi), concerning openEHR, as already mentioned there are
various implementations of the reference model written in several
programming languages, including Java as well.
39
8. Conclusions and recommendations
Our approach allows the harmonization amongst openEHR queries carried
by agents and hl7 compliant systems enabling the discovery and retrieval of
clinical patient data between multiple HI. Implementing intra-institution
openEHR repositories improve agent’s features empowerment with exploration
methods of EHR data through AQL. The appliance of the openEHR standard
will embrace the complexity and evolving nature of medical knowledge,
enabling search and retrieval of clinical data information, maintaining the
semantic.
As a personal opinion I think that the existence and employment of the
various health standards in the scope of medical informatics encourage the
interoperability between different healthcare information systems. Furthermore
the wide range of these different standards increases the difficulty on the
implementation of interoperable systems. This can occurs because the higher
the standards catalogue is the higher is the workload of these systems suppliers.
This circumstance is critical since is directly related with success rate in any
initiative to make a HIS interoperable.
40
9. Future work
This work was a starting point consequently are described in this section
some considerations of future work to complement or even improve what has
been developed so far.
As future work we aim to test an openEHR specification of a service
interface to support accessing and storing of the EHR content. It could be used
the LiU EEE project of Department of Biomedical Engineering, Linköping
University, in Sweden (Linköping University, 2012), which project aims to provides
mechanisms of openEHR storage, retrieval, and version-handling semantics
and related services (Sundvall, et al., 2012). Furthermore it is being developed an
openEHR repository by the Center for Research in Health Information
Systems and Technologies of the Faculty of Medicine - University of Porto
simultaneous with this project which can be suitable as well. The building
database model follows a Key Value Store (Seeger, 2009) approach into order to
store each openEHR composition instance value. The key / value pair it will
correspond to the path of the openEHR composition instance of the XML
leafs with the matching value.
Figure 20 – Key Value Store approach to store OCI entries.
41
10. References
Agile Sherpa, 2012. Test Driven Development. [Online] Available at: http://www.agilesherpa.org/agile_coach/engineering_practices/test_driven_development/ [Accessed in 2012].
Amarasingham, R. et al., 2009. Clinical Information Technologies and Inpatient Outcomes: A Multiple Hospital Study. s.l., Arch Intern Med, pp. 108-114.
Audit Commission, 1995. For your information: a study of information management and systems in the acute hospital. In: London: HMSO.
Barlow, J. B. et al., 2011. Overview and Guidance on Agile Development in Large Organizations. Communications of the Association for Information Systems, Volume 29 (1), p. 25–44.
Beale, T., 2002. Archetypes: Constraint-based domain models for future-proof information systems. Seattle, Washington, USA: Northeastern University, s.n., pp. 16-32.
Beale, T., 2007. HL7 CDA, Clinical Modelling andopenEHR, Scotland: NHS.
Beale, T., 2012. Archetype Query Language Description. [Online] Available at: http://www.openehr.org/wiki/display/spec/Archetype+Query+Language+Description [Accessed in 2012].
Beale, T. & Heard, S., 2007. An Ontology-based Model of Clinical Information. MEDINFO 2007 - Proceedings of the 12th World Congress on Health (Medical) Informatics – Building Sustainable Health Systems, Volume 129, pp. 760-764.
Beyer, M. et al., 2004. Towards a exible, process-oriented IT architecture for an integrated healthcare network. Volume roceedings of the 2004 ACM symposium on Applied computing, pp. 264-271.
Blobel, B., Engel, K. & Pharow, P., 2006. Semantic interoperability--HL7 Version 3 compared to advanced architecture standards.. Methods Inf Med, Volume 45(4), pp. 343-53.
42
Booch, G., Jacobson, I. & Rumbaugh, J., 2000. OMG Unified Modeling Language Specification, s.l.: Object Management Group, Inc.
Chen, R., 2009. Towards Interoperable and Knowledge-Based Electronic Health Records Using Archetype Methodology. Linköping University Electronic Press.
Chronaki, C. E. et al., 2003. An eHealth platform for instant interaction among health professionals. Computers in Cardiology, pp. 101-104.
Corepoint Health, 2010. The HL7 Evolution: Comparing HL7 Version 2 to Version 3, Including a History of Version 2. p. 16.
Cruz-Correia, R. J., 2012. SAHIB Executive Summary. [Online] Available at: http://www.sahib.gim.med.up.pt/ [Accessed in 2012].
Cruz-Correia, R. J. et al., 2005. Integration of hospital data using agent technologies - a case study. AI Communications, Volume 18, p. 191–200.
Cruz-Correia, R. J. et al., 2007. Reviewing the integration of patient data: how systems are evolving in practice to meet patient needs. s.l., BMC Med Inform Decis Mak, p. 7: 14.
Datta, G., 2010. HL7 International Health Level Seven Introduction. HL7 Ambassador Presentation, Issue Health Informatics & HL7.
Dias, R. D., Cook, T. W. & Freire, S. M., 2011. Modeling healthcare authorization and claim submissions using the openEHR dual-model approach. BMC Medical Informatics and Decision Making.
European Commission, 2010. Smart Open Services for European Patients. In: Open eHealth initiative for a European large scale pilot of Patient Summary and electronic Prescription. s.l.:epSOS, pp. 12-20.
Foundation, T. E., 2012. Maven Integration (m2e). [Online] Available at: http://eclipse.org/m2e/
Frankel , H., 2011. openEHR.NET. [Online] Available at: http://openehr.codeplex.com/ [Accessed in 24 01 2012].
Frankel, H., 2011. Using Archetypes with HL7 Messages and Clinical Documents. s.l., HL7 Working Group Meeting.
Frankel, H., 2012. Building software to convert HL7 v2/v3 messaging into archetypes & templates, s.l.: Ocean Informatics.
Ganslandt, M., 2009. OpenEHR case study. [Online] Available at: http://www.talkstandards.com/openehr-case-study/ [Accessed in 2012].
43
Garber, A. M., Owens, D. K., Singer, S. J. & Enthoven, A. C., 2006. Computer Applications in Health Care and Biomedicine 3rd Edition. In: E. H. Shortliffe & J. J. Cimino, edits. Biomedical Informatics. s.l.:Springer, pp. 307-308.
Garde, S. et al., 2007. Towards sustainability of health information systems: how can we define, measure and achieve it?. Studies in Health Technology and Informatics, Volume 129(2).
Garde, S., Knaup, P., Hovenga, E. J. & Heard, S., 2007. Towards Semantic Interoperability for Electronic Health Records. Methods of Information in Medicine, Volume 46, pp. 332-343.
Gutierrez, P. P. & de Barros, S., 2008. Arquitectura Orientada a Servicios para Sistemas que utilizan HL7. Instituto de Computación Facultad de Ingeniería, Universidad de la República.
Health Level Seven International, 2007. About HL7. [Online] Available at: http://www.hl7.org/about/index.cfm [Accessed in 2012].
HL7 Australia Inc, 2006. Statement of Collaboration. [Online] Available at: http://www.hl7.org.au/docs/Statement%20of%20Collaboration%20-%20openEHR.htm [Accessed in 2012].
HL7, 2011. About HL7. [Online] Available at: http://www.hl7.org/about/index.cfm [Accessed in 24 07 2011].
Hoy, D., Hardiker, N. R., McNicoll, I. T. & Westwell, P., 2007. A feasibility study on clinical templates for the National Health Service in Scotland. Stud Health Technol Inform, pp. 770-4.
IEEE Foundation for Intelligent Physical Agents, 2012. Welcome to FIPA!. [Online] Available at: http://www.fipa.org/ [Accessed in 2012].
IHE International, 2012. About IHE. [Online] Available at: http://www.ihe.net/About/ [Accessed in 2012].
IHE, 2011. About IHE. [Online] Available at: http://www.ihe.net/About/ [Accessed in 23 07 2011].
Indarte, S. & Gutiérrez, P. P., 2011. Estándares e interoperabilidad en salud electrónica: requisitos para una gestión sanitaria efectiva y eficiente. In: Santiago de Chile: CEPAL.
44
Informatics, O., 2012. Archetype Query Language Description. [Online] Available at: http://www.openehr.org/wiki/display/spec/Archetype+Query+Language+Description [Accessed in 14 01 2012].
Jade, 2012. Java Agent DEvelopment Framework is an Open Source platform for peer-to-peer agent based applications. [Online] Available at: http://jade.cselt.it/index.html [Accessed in 2012].
Kalra, D., 2006. Electronic Health Record Standards. Method Inform Med, Volume 45, pp. 136-44.
Kalra, D. et al., 2001. Design and Implementation of a Federated Health Record Server. Medical Records Institute: Boston, Towards an Electronic Health Record Europe, pp. 1 - 13.
Kalra, D., Beale, T. & Heard, S., 2005. The openEHR Foundation. Stud Health Technol Inform, pp. 115:153-73.
Kashfi, H., 2011. The Intersection of Clinical Decision Support and Electronic Health Record: A Literature Review. Sweden, IEEE.
Khan, W. A. et al., 2012. Achieving interoperability among healthcare standards: building semantic mappings at models level. New York, ACM.
Korpman, R. & Lincoln, T., 1998. The computer-stored medical record: For whom?. JAMIA 259, pp. 3454-3456.
Land, R. & Crnkovic, I., 2003. Software systems integration and architectural analysis - a case study. Amsterdam, The Netherlands, s.n.
Lapeira, R., 2010. ESB is an architectural style, a software product, or a group of software products?. [Online] Available at: http://www.consultoriajava.com/articulos/esb_arquitecture_software_product.shtml [Accessed in 2012].
Lenz, R. & Kuhn, K. A., 2002. Integration of Heterogeneous and Autonomous Systems in Hospitals. s.l., s.n.
Leslie, H., 2008. International developments in openEHR archetypes and templates. Health Inf. Manag. J, Volume 37, pp. 38-39.
Leslie, H., 2009. A Clinical Perspective on Standardizing the Electronic Health Record. Kuala Lumpur, HIMSS
45
Linden, H. . v. d., Austin, T. & Talmon, J., 2009. Generic screen representations for future-proof systems, is it possible? There is more to a GUI than meets the eye. Elsevier, Volume 95, p. 213–226.
Lin, H., 2007. Architectural Design of Multi-Agent Systems: Technologies and Techniques. In: s.l.:Information Science Reference, p. 442.
Linköping University, 2012. Electronic Health Records (EHR). [Online] Available at: http://www.imt.liu.se/mi/ehr/ [Accessed in 20 02 2012].
Littlejohns, P., Wyatt, J. C. & Garvican, L., 2003. Evaluating computerised health information systems: hard lessons still to be learnt. s.l., British medical journal: 356, pp. 860-3.
Miranda, M. et al., 2010. Modelling Intelligent Behaviours in Multi-agent Based HL7 Services. International Conference on Computer and Information Science, Volume 317, pp. 95-106.
Mirth Corporation, 2012. How to invoke Java code from Mirth. [Online] Available at: http://www.mirthcorp.com/community/wiki/display/mirth/How+to+invoke+Java+code+from+Mirth [Accessed in 2012].
Mirth Corporation, 2012. What is Mirth Connect?. [Online] Available at: http://www.mirthcorp.com/products/mirth-connect#0 [Accessed in 2012].
Mirth, 2011. Powering Healthcare Interoperability. [Online] Available at: http://www.mirthcorp.com/products/mirth-connect/faq#0 [Accessed in 12 06 2011].
Moreno, A. & Nealon, J. L., 2004. Applications of Software Agent Technology in the Health Care Domain (Whitestein Series in Software Agent Technologies and Autonomic Computing). s.l.:Birkhäuser Basel.
Muir, S. & Lord, K., 2012. Lowering the Bar for Healthcare Interoperability using Open Standards and Open Source. Interconnected Health.
Mulligan, E., Rogers, W. A. & Braunack-Mayer, A., 2006. Research within the Privacy Regulations: Problems and Solutions for Database Custodians. electronic Journal of Health Informatics, Volume 1.
Ocean Informatics, 2007-2010. Clinical Knowledge Manager. [Online] Available at: http://www.openehr.org/knowledge/ [Accessed in 2012].
Ocean Informatics, 2008. openEHR Architecture Overview. In: T. Beale & S. Heard, edits. s.l.:Ocean Informatics.
46
openEHR, 2007. Welcome to openEHR. [Online] Available at: http://www.openehr.org [Accessed in 2012].
openEHR, 2010. Clinical Knowledge Manager. [Online] Available at: http://www.OpenEHR.org/knowledge/ [Accessed in 20 07 2011].
Pollock, J., 2002. The Web Services Scandal—How Data Semantics Have Been Overlooked in Integration Solutions. EAI J, pp. 20-23.
Ribeiro, L., 2011. Interoperabilidade nos Sistemas de Informação de Saúde - das convicções à realidade. Faculdade de Medicina da Universidade do Porto.
Ribeiro, L., Cunha, J. P. & Cruz-Correia, R., 2010. Information Systems Heterogeneity and Interoperability Inside Hospitals - a survey. Healthinf, p. 108(2).
Ringholm, 2011. HL7 and openEHR are cooperating (finally). [Online] Available at: http://www.ringholm.com/column/HL7_openEHR_finally_cooperating.htm [Accessed in 2012].
Ryan, A. & Eklund, P., 2009. Ontology Mapping between HL7 Versions 2 and 3 and OpenEHR for Observations Messages. Canberra, HIC.
Sachdeva, S., Yaginuma, D., Chu, W. & Bhalla, S., 2011. Dynamic Generation of Archetype-Based User Interfaces for Queries on Electronic Health Record Databases. Berlin, Springer-Verlag.
Santos-Pereira, C., Antunes, L., Cruz-Correia, R. & Ferreira, A., 2012. One Way to Patient Empowerment - The Proposal of an Authorization Model. Healthinf.
Santos-Pereira, C. et al., 2012. A Mobile Based Authorization Mechanism for Patient Managed Role Based Access Control. In: Information Technology in Bio- and Medical Informatics. s.l.:Springer Berlin / Heidelberg, pp. 54-68.
Santos-Pereira, C., s.d. A mobile based authorization mechanism for patient managed role based access control.
Schloeffel, P. et al., 2006. The relationship between cen 13606, hl7, and openehr. In Health Informatics Conference.
Seeger, M., 2009. Key-Value stores: a practical overview, Stuttgart, Germany: Computer Science and Media Ultra-Large-Sites SS09.
Shaver, D., 2007. Hl7 101: A beginner's guide. [Online] Available at: http://www.fortherecordmag.com/ [Accessed 2007].
Sundvall, E. et al., 2012. Applying Representational State Transfer (REST) Architecture to Archetype-based Electronic Health Record Systems. 20 02.
The Apache Software Foundation, 2002-2012. What is Maven?. [Online] Available at: http://maven.apache.org/what-is-maven.html [Accessed in 2012].
The Apache Software Foundation, 2012. The Maven Integration for Eclipse. [Online] Available at: http://maven.apache.org/eclipse-plugin.html [Accessed in 2012].
The openEHR Foundation , 2010. openEHR - The World's Record. [Online] Available at: http://www.openehr.org/301-OE.html [Accessed in 2012].
The openEHR Foundation, 2007. Archetype Object Model. [Online] Available at: http://www.openehr.org/releases/1.0.1/architecture/am/aom.pdf [Accessed in 2012].
The openEHR Foundation, 2007. Governments and openEHR. [Online] Available at: http://www.openehr.org/shared-resources/usage/government.html [Accessed in 2012].
The openEHR Foundation, 2007. The Archetype Definition Language Version 2 (ADL2). [Online] Available at: http://www.openehr.org/releases/1.0.1/architecture/am/adl2.pdf [Accessed in 2012].
The openEHR Foundation, 2011. Brazil re-affirms commitment to openEHR. [Online] Available at: http://www.openehr.org/340-OE.html [Accessed in 2012].
University Health Network, 2012. The free, Open and Best HL7 Parser and Library for Java. [Online] Available at: http://hl7api.sourceforge.net/ [Accessed in 2012].
Verlinden, J.-M. & Siegert, A., 2012. Clinical workflows and generic output based requirements for advance imaging applications. High Profile.
Wooldridge, M. J. & Jennings, N. R., 1995. Intelligent Agents: Theory and Practice. s.l., The Knowledge Engineering Review, pp. 115-152.
Wyatt, J., 1994. Part 1: Data and medical records.. In: Clinical data systems. s.l.:Lancet, pp. 344:1543-7..
48
Wyatt, J. C. & Wright, P., 1998. Design should help use of patients' data. The Lancet: 352, pp. 1375-8.
Yong, H., Jinqiu, G. & Ohta, Y., 2008. A prototype model using clinical document architecture (CDA) with a Japanese local standard: designing and implementing a referral letter system. Acta Medica Okayama, Volume 62, p. 15–20.
49
Annexes
Published articles
50
51
52
53
54
55
56
Unpublished articles
57
58
59
60
61
62
Generated prototype classes model
63
This attachment reveals the UML documentation a automatically generated
by UModel UML Editor http://www.altova.com/umodel from Altova. This
documentation was deployed to a website which comprises UML class
diagrams, UML component diagrams, etc. It also provides full access to the
Java code written in the prototype. Since this type of documentation does not
suit for this manuscript due its size, a web link is available for public access:
Prototype workspace model UML documentation.
64
5th ed