Content uploaded by Pariya Kashfi
Author content
All content in this area was uploaded by Pariya Kashfi on Jun 10, 2015
Content may be subject to copyright.
Supporting openEHR Java Desktop
Application Developers
Hajar KASHFI a,1, Olof TORGERSSON b
aDepartment of Applied Information Technology, Chalmers University of Technology,
SE-412 96, Gothenburg, Sweden
bDepartment of Applied Information Technology, University of Gothenburg
Abstract.
While generating GUIs from openEHR archetypes/templates has advantages,
when it comes to maintenance of large scale systems, creating good, and not just
mediocre, user interfaces from underlying domain models is a non-trivial problem.
During the time mature generation techniques are being developed, hooking up de-
signed GUIs to openEHR backends is an interesting alternative. In this study, a
framework for binding a pre-designed GUI to an openEHR-based backend is pro-
posed. The proposed framework contributes to the set of options available for de-
velopers. In particular we believe that the approach of combining GUI components
with an openEHR backend in the proposed way might be useful for various small
scale and experimental systems as well as systems where the quality of the user
interface is of great importance.
Keywords. openEHR, clinical application, opereffa, application development
framework, data binding
Introduction
With the growing presence of electronic healthcare record (EHR) systems developed
by various vendors, it becomes increasingly important to agree upon standards that can
overcome the resulting interoperability problems [1]. The goal of the openEHR initiative
is to develop an open standard that can serve as the basis for both developing EHR sys-
tems and to guarantee semantic interoperability between systems [2]. openEHR suggests
a two-level architecture for managing data in clinical applications. The top-level is made
up of archetypes, which are domain specific models that should be developed by domain
experts. The lower level is the openEHR reference model (RM), which is a very generic
model for managing clinical data [2] .
Different approaches can be used to develop openEHR applications. The typical ap-
proach is to automatically generate the graphical user interface (GUI) from openEHR
archetypes/templates. In contrast, there is an approach in which no generation of GUI
based on archetypes is done but instead the interface is designed by experts based on
the demands of the users of the application. There is then a need to connect this user
1Corresponding Author: Hajar Kashfi, Department of Applied Information Technology, Chalmers University
of Technology, SE–412 96 Gothenburg, Sweden; E-mail: hajar.kashfi@chalmers.se.
Archetype
Archetype
Archetype
Template
Template
Template
translated to
GUI artefacts
GUI
......
...... User
RM
object
RM
object
RM
object
RM
object
RM
object
AOM
object
validated by
AOM instances
openEHR-based
EHR
Data
Developer
Manual
adjustment
expert
create
Archetype
Archetype
Archetype
User
RM
object
RM
object
AOM
object
validated by
AOM instances
openEHR-based
EHR
Developer
create deisgn
is mapped to GUI
......
......
RM
object
RM
object
RM
object
Data
data binding
expert
A B
Figure 1. The two development models. Left side model is supported by opereffa
interface to the archetypes designed in parallel by domain experts. Unfortunately, the
current frameworks do not provide enough support for this type of application develop-
ment. To fill this gap, we have developed an extension to one of the existing openEHR
frameworks to help developers easily connect a user interface created by a GUI-designer
to an openEHR based backend.
1. Background
Regardless of the advantages offered by openEHR, the standard suffers from a rather
low adoption rate. While this is not the place to make a proper analysis of the reasons
for this, some possible reasons are the complexity of the standard, lack of documenta-
tion and training for developers, and a limited set of tools and frameworks available to
ease application development. Most of the focus of the community seems to have gone
into representing and modeling domain concepts and perfecting the specifications. How-
ever, to make openEHR more practical, application developers need to be supported with
APIs, frameworks and tools.
Of course, a number of application development projects exist. Some of the more
mature are: the open source health information platform [3] (OSHIP), the open EHR-Gen
framework [4], GastrOS [5], and the openEHR reference framework and application [6]
(opereffa). To our knowledge, current openEHR frameworks and tools are compatible
with the model depicted in Figure 1-A. The idea is that clinicians design and create
archetypes (and templates) using existing tools. Based on these a GUI, or GUI artifacts
are generated from the given archetypes/templates. To improve the GUI design, manual
adjustment of the GUI or its style files is often required. The typical openEHR application
is web based.
In contrast to this automatic or semi-automatic approach to creating GUIs to
openEHR-based applications, there is an alternative illustrated in Figure 1-B. Here, there
is no generation of GUI based on archetypes but instead the interface is designed by ex-
perts based on the demands of the users of the application. There is then a need to con-
Java open source
RM implementation
Java open source
framework
Persistent (PostgreSQL)
Automatic GUI generation
etc.
Open source
clinical Application
Web based GUI (JSF)
Document
Document
Archetype
openEHR-based
EHR
PostgreSQL
ADL parser
AOM classes
RM classes
'Data validation
etc.
Medical application
Java open source
RM implementation
Java open source
framework
User interface data binding
Figure 2. opereffa has introduced
nect this user interface to the archetypes designed in parallel by domain experts. Unfortu-
nately, the current frameworks do not provide enough support for this type of application
development. What is needed is a simple and efficient data binding framework connect-
ing an application’s front end to its back end (or the business logic). Usually, the idea of
data binding is that when the data changes, the changes are reflected automatically by the
bound elements on the user interface. In the same manner, if the “outer representation” of
data changes, then the corresponding data in back end should be automatically updated
as well to reflect the change [7].
2. Results
We have developed an extension, a Java desktop user interface data binding layer, to one
of the openEHR application development frameworks, opereffa (compare left and right
sides of the Figure 2). opereffa is a initiative for creating an open source clinical appli-
cation and is built on top of a Java-based open source framework. Services such as GUI
generation, and persistence are supported in opereffa. opereffa generates web-based user
interface artifacts using Java Server Faces (JSF) [8] and also makes use of the data bind-
ing capabilities of JSF. The new data binding layer on top of opereffa provides a single
entry point for connecting Java desktop GUIs to an archetype-enabled backend. To make
the desktop connection framework as easy to use as possible for application develop-
ers, it is designed using a facade pattern [9]. This means that there is one single class,
ArchetypeDatahandler, which hides all the details of archetype-based data management
and therefore is the only class someone using the framework needs to know anything
about. To further improve ease of use in applications, the ArchetypeDataHandler is a
singleton, meaning that there is only one instance of it in an application and it can easily
be accessed anywhere. To connect a pre-designed GUI to the openEHR backend the only
steps required are: (i) creating an xml-file specifying the connection between GUI com-
ponents and archetypes (ii) adding each component in the GUI to the ArchetypeData-
Handler, i.e., calling the method add(JComponent c) on the ArchetypeDataHandler.
Underlying the implementation is the assumption that each GUI component is logi-
cally in relation to one and only one item in an archetype (an item in an archetype can be
Figure 3. Sample entries showing the connection between GUI components and archetypes
Figure 4. The demo application sc
visually presented in several places on a screen though). This means that for each com-
ponent there exists an archetype name, and a unique path for the item in that archetype.
This information is stored in an xml file, which is used by the ArchetypeDataHandler to
decide to which data item a certain GUI component should be connected. A sample of
entries in the xml file is shown in Figure 3.
Internally, the actual functionality is provided by a class named GUIMapper, with
support from other mapper classes. The role of this class is to keep track of all GUI
components, their archetypeWrappers and the path of the item in the archetype to which
this component is mapped. The synchronization of data shown in the GUI and what is
stored in the GUIMapper is realized using various listeners. If data changes on the GUI
this change is reflected in the GUIMapper in the backend. On the other hand, if data is
loaded from the DB, the GUIMapper updates the GUI as well. All data is kept in memory
to be persisted at the right time using opereffa persistance services.
To evaluate the functionality of the data binding framework, a demo application
was created using the graphical GUI-editor of NetBeans. In the demo application, four
different archetypes are used and connected to 39 GUI components. The archetypes are
both special archetypes developed for a decision support system for Xerostomia [10]
and adaptations of common archetypes such as openEHR-EHR-OBSERVATION.lab_
test.v1. A snapshot of the demo application is depicted in Figure 4. The screen shows a
field where one can search for a patient, a list where one can select one of the patient’s
recent sessions and the data recorded at that session. The part of the code that enables
it to load and store archetyped data is only a few lines that adds components to the
ArchetypeDataHandler. The rest is provided by the framework.
3. Discussion and Conclusion
The proposed framework for binding a pre-designed GUI to an openEHR-based backend
contributes to the set of options available for developers. In particular we believe that
the approach of combining GUI components with an openEHR backend in the proposed
way might be useful for various small scale and experimental systems as well as systems
where the quality of the user interface is of great importance.
The generic proposed model for building openEHR applications was illustrated in
Figure 1-A. While generating GUIs from archetypes and templates has advantages when
it comes to maintenance of large scale systems, creating good, and not just mediocre, user
interfaces from underlying domain models is a non-trivial problem. During the time ma-
ture generation techniques are being developed, hooking up designed GUIs to openEHR
backends is an interesting alternative. The use of designed GUIs is also interesting from
another point of view. GUIs based on a domain model are by necessity rather close to
the implementation model of the system. However, when a GUI is designed the goal of
the developers should always be to have an on-screen representation that is as close as
possible to the users’ mental model [11]. Therefore, having a simple way of replacing
parts of a system with GUIs designed by hand in accordance with the users’ mental mod-
els is valuable to handle the situations where generation cannot produce an appropriate
solution.
The main disadvantage of the approach used in this paper is maintenance. A gen-
erated GUI can change automatically if the underlying archetypes/templates change
whereas a manually created GUI has to be updated manually. A related problem is that in
complex systems the number of GUI components that need to be connected to the back-
end will be very large. The current implementation is rather limited since it only supports
a small number of GUI components. A more complete implementation must of course
support all commonly used standard components and perhaps even provide some special
controls tailored towards clinical applications. This however is work for the future.
References
[1] P. Schloeffel, T. Beale, G. Hayworth, S. Heard, and H. Leslie, “The relationship between CEN 13606,
HL7, and openEHR,” in In Health Informatics Conference (2006), vol. 7, p. 24, Health Informatics
Society of Australia, 2006.
[2] T. Beale and S. Heard, “openehr architecture overview, http://www.openehr.org/,” 2009.
[3] “OSHIP.” Website, 2011. http://www.oship.org/.
[4] “Open-EHR-Gen.” Website, 2011. http://code.google.com/p/
open-ehr- gen-framework/.
[5] “GastrOS.” Website, 2011. http://sourceforge.net/projects/gastros.
[6] “opereffa.” Website, 2011. http://opereffa.chime.ucl.ac.uk/introduction.jsf.
[7] “Data Binding Overview.” Website, 2010. http://msdn.microsoft.com/en- us/library/
ms752347.aspx.
[8] E. Burns, N. Griffin, and C. Schalk, JavaServer faces 2.0: the complete reference. McGraw Hill Profes-
sional, 2009.
[9] S. Stelting and O. Maassen, Applied Java patterns. USA: Sun Microsystems Inc., 2002.
[10] H. Kashfi, “Applying a user centered design methodology in a clinical context.,” Studies in health tech-
nology and informatics, 2010.
[11] A. Cooper, R. Reimann, and D. Cronin, About face 3: the essentials of interaction design. Wiley-India,
2007.
