See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221324949

Implementing High-Level Query Language Interfaces for Archetype-Based

Electronic Health Records Database

Conference Paper · January 2009

Source: DBLP

CITATIONS READS

15 342

2 authors:

Shelly Sachdeva Subhash Bhalla

National Institute of Technology Delhi The University of Aizu
111 PUBLICATIONS 929 CITATIONS 134 PUBLICATIONS 686 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Shelly Sachdeva on 01 June 2014.

The user has requested enhancement of the downloaded file.

 Implementing High-Level Query Language Interfaces for
Archetype-Based Electronic Health Records Database
Shelly Sachdeva, Subhash Bhalla
Graduate Department of Computer and Information Systems,
University of Aizu, Aizu-Wakamatsu, Fukushima, 965-8580 (Japan)
{d8111107, bhalla}@u-aizu.ac.jp

Abstract paragraphs, measured quantities with values and units,

date, time, date-time, and partial date/time, encapsulated
In contrast to a single doctor-patient relationship, data (multimedia, parsable content), basic types (such as
there are several departments in a hospital. Thus boolean, state variable), container types (list, set) and
health data may be scattered and can be termed uniform resource identifiers (URI).
as islands of information. Electronic health The International Organization for Standardization
records (EHRs) can make healthcare (ISO) has recently approved a new standard ISO 13606,
organizations operate more efficiently. These for the communication and semantic interoperability of
will help in reducing medical errors, and EHR extracts [5]. This standard is based on a dual model
improving health care, in general. The greatest architecture. First a simple and generic reference model is
challenge in the exchange of healthcare data defined for the representation of data at storage level
about patients, concerns efficient and meaningful (physical level). An archetype model is used for the
exchange. A query language is essential for representation of complex domain concepts of the EHR at
health information systems. The proposed study conceptual level (logical level). The Reference model
aims to develop a graphical interface for (RM) has a fixed (small) number of generic classes [4]. It
querying EHR data. The motive of the research represents the generic structures of components of health
is to meet the querying needs of healthcare record information. The software and data are built from
consumers. RM. Thus, healthcare information system can be built
using relatively simple information models and
1. Introduction conceptual database schemas. This reflects the stable
characteristics of the design of EHRs and their
Electronic health record (EHR) is a patient-centric,
components.
longitudinal view of data collected from several source
systems [1]. These help in providing information during
emergencies. In general, EHRs can help as decision 2. EHR and Archetypes
support tool, and in improving quality, security, time and Archetypes provide semantic modelling (independent of
communication among doctors. The demand for software). These are expressed in form of constraints on
Electronic Health Records will increase gradually. In data whose instances conform to a RM. Archetypes are
January 2011, the US government stimulus incentives will language neutral and can be authored and translated into
be enforced [3]. The rapid developments in the field of any language. Archetypes connect information structures
EHR present numerous challenges for data management. to formal terminologies. RM is stable, where as the
Also, determining the needed requirements at each user’s archetypes are dynamic. Every archetype is written with
level is difficult. respect to a particular ‘reference model’. The archetypes
In essence, the proposed Electronic Health Records are used to constrain the valid structures of instances of
(EHRs) have a complex structure that may include data of the generic class belonging to RM. For example, a generic
about 100-200 parameters, such as temperature, blood- class “PARTY” can represent different domain concepts
pressure and body mass index. Individual parameters have such as patient, doctor or nurse. The openEHR foundation,
their own contents (Figure 1.). In order to serve as an CEN/TC251 (European Committee of standardization)
information interchange platform, EHRs use archetypes to and Microsoft aims to generate mechanisms and standards
accommodate various forms of contents [10]. The EHR for sharing health information worldwide, by using these
data has multitude of representations. The contents can be archetype based EHRs [7,8,9].
structured, semi-structured or unstructured, or a mixture
of all three. These can be plain text, coded text, 2.1 Archetype Description Language (ADL)

15th International Conference on Management of Data

Archetypes for any domain are described using a formal
COMAD 2009, Mysore, India, December 9–12, 2009 language known as Archetype description language
©Computer Society of India, 2009
(ADL) [11]. ADL is path addressable like XML. The standards. A domain knowledge governance tool called
openEHR Archetype Object Model (AOM) describes the Clinical Knowledge Manager has been developed by
definitive semantic model of archetypes, in the form of an openEHR foundation for development of archetypes [13].
object model [12]. The AOM defines relationships which
must hold true between the parts of an archetype for it to
be valid as a whole. In simpler terms, all archetypes
conform to AOM. Since EHR has a hierarchical structure,
ADL syntax is one possible serialisation of an archetype.
ADL uses three other syntaxes, cADL (constraint form of
ADL), dADL (data definition form of ADL), and a
version of first-order predicate logic (FOPL), to describe
constraints on data which are instances of RM [11].
The ADL archetype structure consists of archetype
definition (expressed using cADL syntax), language, Figure 1. Parameter (Blood pressure) in Archetype form
description, ontology, and revision_history (expressed
using dADL syntax), invariant section (expressed using 4. Querying Archetype based EHR
FOPL). The invariant section introduces assertions which
relate to the entire archetype. These are used to make The EHR system must have an appealing and responsive
statements which are not possible within the block query interface that provides a rich overview of data and
structure of the definition section. Similarly, the dADL an effective query mechanism. The overall solution
syntax provides a formal means of expressing instance should be designed with an end to end perspective in
data based on an underlying information Model [11]. The mind. A query interface is required that will support users
cADL is a syntax which enables constraints on data at varying levels of query skills. These include semi-
defined by object-oriented information models to be skilled users at clinics or hospitals.
expressed in archetypes or other knowledge definition
formalisms [11]. 4.1 Archetype Query Language (AQL)
There are many parameters, such as weight, body To query upon EHRs, a query language, Archetype Query
temperature and heart rate in an EHR. The ADL for a Language (AQL) has been developed [15]. It is neutral to
parameter ‘Blood Pressure’ (BP) (also see Figure1) and EHRs, programming languages and system environments.
other parameters are available at common repository [19]. It depends on the openEHR archetype model, semantics
ADL has a number of advantages over XML. It is both and its syntax. AQL is able to express queries from an
machine and human processable, and approximately, archetype-based EHR system. The use of AQL is
takes half space of XML. The leaf data type is more confined to a skilled programmers’ level. It was first
comprehensive set (including interval of numerics and named as EQL (EHR Query Language) which has been
date/time types). ADL adheres to object-oriented enhanced with the following two innovations [14]:
semantics that do not confuse between notions of i) utilizing the openEHR path mechanism to represent the
attributes and elements. In ADL, there are two types of query criteria and the response or results; and
identifiers (from reference model) - the type names and ii) using a ‘containment’ mechanism to indicate the data
attributes. Formally, it is possible to convert ADL into hierarchy and to constrain the source data to which the
XML format and other formats [11]. query is applied.

3. Complexity of EHR data 4.2 High-Level Database Query Interfaces

For different parameters in EHR, the archetypes are AQL is difficult for semi-skilled users. It requires the
distinct, structured models of domain content, such as, knowledge of archetypes and knowledge of languages
data, state and protocol. For example, ‘data’ may be such as SQL and XML. At the present moment, there is
captured for a blood pressure observation. It contains no easy-to-use query language interface available for
complete knowledge about a clinical context, (i.e., EHRs database. We propose to study a high-level
attributes of data). ‘State’ contains context for interface for querying EHR database based on the
interpretation of data). ‘Protocol’ contains information proposed XQBE [16]. An alternative approach proposed
regarding gathering of data, as shown in Figure 1. A total by Ocean informatics [20] suggests using a query builder
of 187 archetypes have been developed by openEHR till tool, to construct AQL query. It requires form related
date [13]. These are expected to increase in number (may inputs and more skills on the part of the user. The goal is
be thousands or more) as the domain knowledge similar and it is easier to achieve with the help of XQBE.
regarding health expands. Thus, we are able to represent XQBE [16] is a user-friendly, visual query language
the complex EHR data and expanding knowledge for expressing a large subset of XQuery in a visual form.
concepts in a more efficient manner, through accepted It requires all data to be in XML form. Its simplicity,
expressive power and direct mapping to XQuery are some for some users (skilled in use of XML) the step (ii) may
of the highlighting features for its use. Like XQuery, not be needed and XQBE can be used directly for the
XQBE relies on the underlying expressions in XML. It XML file.
presents a user with XML sub-tree expressions for the In order to highlight a contrast between different
items of user interests. XQBE’s main graphical elements query languages, consider the following examples.
are trees. There are two parts, the source part which Query Scenario1. Find all Blood Pressure values, having
describes the XML data to be matched against the set of the systolic_BP and diastolic_BP, (where systolic_BP >=
input documents, and the construct part, which specifies 140 and diastolic_BP >=90).
which parts will be retained in the result, together with Chunlan,et al.[14] gives the AQL syntax for the above
(optional) newly generated XML items. query. By using XQBE approach for querying, we
In order to adopt a XQBE like interface at user level, perform step (i) to step (iii) as explained, on BP parameter.
we propose to convert ADL into XML. ADL can be For each case of query, and for querying different
mapped to an equivalent XML instance. ADL is parameters of EHR, we need to convert each parameter
hierarchical in nature and provides a unique identification (in form of adl) to a corresponding xml for the
to each node. Thus, paths are directly convertible to demonstration. We propose to develop an automated tool
XPath expressions. These can be created. According to in the subsequent phase. The clinical user will be
Beale and Heard [11], the particular mapping chosen may provided with a substituted XQBE interface (Figure 4) in
be designed to be a faithful reflection of the semantics of place of AQL.
object-oriented data. There may be need for some <!ELEMENT adl_version ( #PCDATA ) >
additional tags for making the mapping of nested <!ELEMENT archetype ( original_language,
container attributes since XML does not have a systematic description, archetype_id, adl_version, concept,
definition, ontology ) >
object-oriented semantics. Thus, single attribute nodes <!ELEMENT archetype_id ( value ) >
can be mapped to tagged nodes of the same name. <! ELEMENT assumed_value (terminology_id,
Container attribute nodes map to a series of tagged nodes code_string, magnitude?, units?, precision? ) >
of the same name, each with the XML attribute ‘id’ set to <! ELEMENT attributes (rm_attribute_name,
the node identifier. Type names map to XML ‘type’ existence, children+, cardinality? ) >
<! ATTLIST attributes xsi: type
attributes. (C_MULTIPLE_ATTRIBUTE |
In the present proposal, the patient data description is C_SINGLE_ATTRIBUTE) #REQUIRED >
converted to XML form. It is suitably reformed for <! ELEMENT cardinality (is ordered, is unique,interval)
adoption of XQBE interface. Thus users can directly use > Figure 3. A sample of BP.dtd
XQBE query interface to access patient data. This process XQBE is a visual interface. A user is presented with
eliminates the need to learn and use the AQL language on graphical image of EHR components, for example, blood
the part of the users. The XQBE skills can be learnt with Pressure (BP) in this case. In Figure 4, based on the
ease [16]. selected source data, the user defines a target sub-tree (in
XML form) to express the query (and its outcome). The
5. Mapping ADL to XQBE for EHR data query is expressed by using the graphical elements of
XQBE [16]. The source part of the query is built using the
The queries play a crucial role in decision support and
DTD. A guided construction is provided to the user to add
epidemiological situations. The XQBE approach for
predicates for the query. The construct (or result) part of
archetype-based EHRs is being proposed for semi-skilled
the query is built by the user using the graphical elements
users (such as doctors, physicians, nurses). The mapping
of XQBE by dragging and dropping them. Figure 4 shows
process to create XQBE is shown in following steps
the element nodes and subelement nodes in the source
(Figure 2).
part.
i) The conversion of ADL file into XML file.
The subelements (systolic and diastolic) of the BP
ii) Generation of DTD for the XML file (Figure 3).
element, one systolic and one diastolic satisfy condition1
iii) Generation of XQBE interface structure (Figure 4).
(systolic>=140) AND condition2 (diastolic>=90) are
Subsequently, for the semi-skilled user, this three step
described with the help of XQBE convention. As per the
convention, an arc containing ‘+’ indicates that ‘children’
process will facilitate in querying archetype based EHRs.
element node may exist at any level of nesting (as in
XQBE XML
(i)
ADL Xpath we use ’//’). The construct part consists of element
(ii)
node for BP (set tag T-node), and also element nodes for
(iii) systolic and diastolic, which relates the projected BP
DTD element nodes to its systolic and diastolic subelements.
The fragment node (shown by filled triangle) indicates
Figure 2. Mapping process to present XQBE for EHRs. that the entire fragment of systolic and diastolic must be
The step (ii) in above process will aid in the guided retained in the result. A binding edge between source part
construction of query provided by XQBE [16]. However,
 and construct part indicates to construct as many BP 6. Summary and Conclusions
element nodes (in construct part) as BP element nodes (in
source part). EHRs are becoming a reality, as a consequence a number
of healthcare providers and their partners are responding
to the government and patient demands for better service.
A high level interactive query interface for querying EHR
data is required. The research aimed at developing a query
interface for semi-skilled and skilled healthcare
professionals. It will increase productivity of doctors,
clinicians. The high-level interface has been developed by
mapping ADL to match the XQBE requirements. Skilled
and semi-skilled workers using EHR data can use XQBE,
an easy-to-use query language interface.

References
1. Jens Edlef Møller, Henrik Vosegaard ”Experiences with
Figure 4. BP.XQBE- an XQBE template for query Electronic Health Records” IT Pro, published by IEEE
The XQBE will generate a corresponding XQuery Computer Society, March/April 2008.
2. http://www.bizjournals.com/twincities/stories/2009/08/24/d
expression, which may be executed. aily55.html?s=industry&i=healthcare FierceEMR,3 Sep,09.
Query Scenario2. Find details for all blood pressure 3. http://www.healthdatamanagement.com/news/ARRA-
values with position recorded. 38893-1.html (news Aug 28,2009)
4. Beale T, Heard S., Kalra D., Llyod D., The openEHR
At the user level, in Figure 5, the query is expressed Reference Model: EHR Information Model. The
by using the graphical elements of XQBE. The query openEHR release 1.0.2. , openEHR Foundation, 2008.
indicates the existential quantification, .i.e., in order for 5. ISO 13606-1, Health informatics - Electronic health
BP element to be included, a position element must exist. record communication - Part 1: RM, 1st edition, 2008.
6. ISO 13606-2, Health informatics - Electronic health
record communication - Part 2: Archetype Interchange
Specification, 1st edition, 2008.
7. www.openehr.org (Accessed 02/06/2009)
8. www.cen.eu (European committee for Standardization,
Technical committee on Health informatics, Standard for
EHR communication).
9. http://www.microsoft.com/industry/healthcare/technology/
HealthFramework.mspx (Microsoft Health framework).
10. BealeT,Heard S.,” openEHR Architecture: Architecture
Overview in The openEHR foundation, release
1.0.2.”,published by openEHR Foundation, 2008.
11. Beale T, Heard S.,” The openEHR Archetype Model-
Archetype Definition Language ADL 1.4”, openEHR
release 1.0.2, Issue date 12 Dec 2008.
12. Beale T.,” The openEHR Archetype Model-Archetype
Object Model”, openEHR release 1.0.2, 20 Nov 2008.
Figure 5. An XQBE template for query. 13. http://www.openehr.org/knowledge/ (Clinical knowledge
Manager) (Accessed 07/05/2009).
5.1 Implementation Details and Related Works 14. Chunlan M., Heath F., Thomas B., Sam H.,”EHR
Query Language (EQL)-A Query Language for
The openEHR specifications for AQL and EHR are based Archetype-Based Health Records”, MEDINFO 2007.
on an object-oriented framework. Thus, these allow 15. http://www.openehr.org/wiki/display/spec/Archetype+
multiple representations [14]. Hence, EHRs can be Query+Language+(AQL)+(Ocean) (Archetype Query
Language) (Accessed 28/05/2009)
represented as relational structures (governed by an 16. D. Braga, A. Campi, Stefano Ceri,” XQBE (XQueryBy
object/relational mapping layer), and in various XML Example): A Visual Interface to the Standard XML
storage representations [14].Our aim is to prepare a Query Language”, ACM Transactions on Database
Systems, Vol. 30, No. 2, June 2005, PP. 398–443.
prototype system with query support for the high-level 17. https://wiki.oceaninformatics.com/confluence/display/
interface for the semi-skilled users. An intermediate layer TTL/Archetype+Editor (Archetype editor).
of mappings has being developed in XML to perform the 18. http://dbgroup.elet.polimi.it/xquery/XQBEDownload.ht
conversion of form using an editor [17]. Further, a ml (XQBE 2.0.0).
19. http://www.openehr.org/svn/knowledge/archetypes/dev
mechanism has been developed to convert BP.xml to /html/index_en.html (ADL for archetypes) (Accessed
BP.dtd. Subsequently, XQBE 2.0.0 interface can be used 04/07/2009).
to provide the query interface for the query scenarios [18]. 20. http://www.oceaninformatics.com/Solutions/ocean-
The above steps demonstrate the feasibility of adoption of products/Clinical-Modelling/Ocean-Query-
Builder.html (Query builder, Ocean Informatics)
a XQBE interface for EHR data. (Accessed 10/06/2009).

View publication stats