Development of an Electronic Health Record Application

using a Multiple View Service Oriented Architecture

Joyce M. S. Franc¸a

1,2

, Josimar de S. Lima

and Michel S. Soares

Federal University of Uberl

andia, Faculty of Computing, Uberl

andia, Brazil

Federal Institute of Education, Science and Technology of Norte de Minas Gerais, Porteirinha, Brazil

Federal University of Sergipe, Department of Computing, S

ao Crist

ao, Brazil

Keywords:

Service Oriented Architecture, Electronic Health Systems, Software Development, ISO/IEC/IEEE 42010,

SoaML.

Abstract:

Service-Oriented Architecture has been widely adopted in several domains in past years with the purpose of

developing distributed applications. Within the health domain, integration of legacy systems by means of web

services has been applied in order to develop complex applications. However, few approaches in this area

treat complexity by delineating a software architecture to which applications must conform. In most cases

in the literature, SOA applications in the health domain are documented using only one or two architecture

views. This paper proposes a multiple view Service Oriented Architecture which is the basis for development

of an Electronic Health Record (EHR) application. In order to develop the EHR, new requirements as well

as current functionalities obtained from integrating legacy systems by means of web services were considered

in a cohesive approach. Four architecture views, Scenarios, Business Process, Implementation and Logical

View are presented. Each architecture view addresses one speciﬁc concern that organizes important concepts,

facilitates understanding the system, and improves possibilities of communication between stakeholders. As

a result, important software principles such as separation of concerns, component-based development and

modularity are considered for development and integration of legacy systems in order to develop the EHR

application to be deployed in a public hospital.

1 INTRODUCTION

Service-Oriented Architecture (SOA) has emerged as

an architectural approach for developing distributed

applications based on the concept of assembling ser-

vices (Papazoglou et al., 2008). A service is a capa-

bility of the business organization that is implemented

and made available over the Internet so that other

applications can access it. In the past years, SOA

has been widely adopted for developing distributed

applications (Welke et al., 2011) (Marchetta et al.,

2015). According to recent literature, SOA has been

applied to develop applications in various domains

(Soares and Franc¸a, 2016), including automotive in-

dustry (Kabir et al., 2014), serious games (Carvalho

et al., 2015), and learning platforms (Gonz

alez et al.,

2014).

SOA has also been considered for developing

health applications (Monsieur et al., 2012) (Cho et al.,

2010) (Traore et al., 2016) (Franc¸a et al., 2016). One

health application that is considered very complex not

only to develop but also to operate and maintain is

the Electronic Health Record (EHR), which refers to

software systems that stores health information about

patients in a digital format. EHRs are used by differ-

ent health professional teams, including physicians,

nurses, radiologists, pharmacists, laboratory techni-

cians and radiographers. Even patients can add in-

formation into the EHR, provided this is validated by

physicians.

SOA has been chosen as the architecture basis for

developing the EHR in this project due to the neces-

sity of integrating legacy systems in a public hospi-

tal. Currently, the hospital has several legacy systems

used for different purposes. Another issue is that the

hospital maintains patient health records in hard copy

papers manually written by clinicians. This is a prob-

lematic situation for two reasons: large amount of ac-

cumulated paper in several hospital rooms, and dif-

ﬁculty to retrieve patient records in order to check

historical data and evolution of the patient’s clinical

status.

308

França, J., Lima, J. and Soares, M.

Development of an Electronic Health Record Application using a Multiple View Service Oriented Architecture.

DOI: 10.5220/0006301203080315

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 308-315

ISBN: 978-989-758-248-6

A well-known principle in system development is

to describe in early stages of software development

process the overall software architecture (Booch,

2007). According to ISO/IEC/IEEE 42010 (ISO

42010:2011, 2011), a software architecture is a fun-

damental concept of a software system in its environ-

ment embodied in its elements, relationships, and in

the principles of its design and evolution. Typically,

a software architecture description should include

a number of architecture views (ISO 42010:2011,

2011). An architecture view (or simply, view) ad-

dresses one or more of the concerns held by one or

a group of stakeholders.

In the literature, SOA has been considered to

develop several health information systems, includ-

ing clinical decision support (Cho et al., 2010) (El-

Sappagh and El-Masri, 2014), telemedicine services

(Traore et al., 2016), and EHR systems (Moor et al.,

2015), (Fabian et al., 2015). Most often these studies

present service architecture describing only one view

(implementation view or process view) or even us-

ing natural language, code snippets and applications

screens.

This paper aims to describe the software archi-

tecture of an EHR application based on SOA, which

has been developed for deployment in a public hos-

pital. Our application has been developed with focus

on software architecture principles from its early de-

sign. Our architecture is described by means of multi-

ple views, which is different from most other studies,

as presented in the following section.

2 BACKGROUND AND RELATED

WORK

According to ISO/TR 20514:2005 (ISO 20514:2005,

2005), EHR means a repository of patient data in dig-

ital form, stored and exchanged securely, and acces-

sible by multiple authorized users. EHR, as a com-

plex software system, contains any health, clinical or

medical record in electronic or digital format in the

context of patient care. A systematic literature review

(Nguyen et al., 2014) proposed recently highlighted

important details about EHR application worldwide.

For instance, according to the authors, the adoption

of EHR will increase signiﬁcantly worldwide due to

its several beneﬁts. This review conﬁrms the potential

EHRs have to aid patient care and clinical documen-

tation.

When system complexity grows, it is commonly

advised to develop applications having a well-deﬁned

software architecture as basis (Bertolino et al., 2013).

Architecture-based development has been applied for

many years to solve issues such as interoperability be-

tween legacy systems and to help the development, in-

tegration and evolution of complex software systems

(Garlan, 2014). However, in health information sys-

tems, such as EHR applications, software architecture

is still not common sense, and when architecture is

considered, it is based on a single view or a mix of

views in only one picture.

Two studies presented in (Cho et al., 2010) and

(El-Sappagh and El-Masri, 2014) propose SOA appli-

cations for clinical decision support. In both studies,

only the implementation view of the EHR architecture

is presented. One study in health domain, presented

in (Traore et al., 2016), addresses telemedicine ser-

vices and its related software architecture. The pro-

posed architecture is, in fact, a model-driven approach

to transform UML models into WSDL source code.

Studies (Moor et al., 2015) and (Fabian et al., 2015)

applied SOA concepts to develop an EHR system. In

these works, the EHR architecture is described as a

whole big picture, in which the views are considered

together. For instance, in (Fabian et al., 2015) the

architecture brings in the same picture dynamic pro-

cesses, structural elements, and deployment infras-

tructure. In addition, application scope and which ser-

vices should be implemented are not described. Work

presented in (Gazzarata et al., 2015) proposes an EHR

SOA application with focus on secure access, and

presents the architecture using only the process view.

Most studies which address the implementation of

an EHR using SOA concepts have focus on the ap-

plication itself, but not on the architectural aspects

for development. Even those studies which present

the software architecture, only describes one or two

views, or even a multiple number of views in only

one box diagram, which may be confusing for most

stakeholders.

Our proposal in this paper is to present an EHR ap-

plication developed under SOA paradigm using multi-

ple views to describe the software architecture, as pre-

conized by ISO/IEC/IEEE 42010. Models presented

in these views are described by means of UML and

SoaML (OMG, 2012) diagrams.

3 A MOTIVATING CASE

The EHR system has been developed due to a demand

from a public hospital. Three main constraints are

considered in this EHR project. First, due to low bud-

get for Information and Communication Technology

in a public hospital, it is hard to apply resources for

modernization of software applications. Thus, there

is no possibility to start from scratch and discard all

Development of an Electronic Health Record Application using a Multiple View Service Oriented Architecture

309

deployed legacy systems.

Second, lack of integration between current legacy

systems makes duplication of data a common side

effect. Most Hospital’s legacy systems are not inte-

grated and thus they do not meet many routine needs

of hospital staff. There are many software systems

for different purposes, including software to automate

exams, to provide primary care, and also to register

patient data. However, these modules do not interact

with each other in an affordable way. Thus, data needs

to be duplicated in two or more different systems.

Finally, important business rules have not yet been

implemented in existing software systems, as discov-

ered after mapping all current business processes in

the hospital. For instance, patients’ data are registered

in and maintained as hard copies. Daily, hundreds

of patients are treated at the hospital and all data and

evolution are noted in physical medical records. In

addition to this, these records should be kept for long

periods (most often 20 years), to allow access to in-

formation stored on it at any time by the patient or

his/her legal representative. Therefore, this scenario

causes a big impact regarding storage space of this

large amount of physical records. The large amount

of paper occupies several rooms and it promotes dif-

ﬁculty in retrieving patient’s records when clinicians

need to consult past ﬁles to analyze patient evolution.

Due to the constraints presented before, the pro-

posed solution is to use Service Oriented Architecture

principles and techniques to gather all important in-

formation from legacy systems on services to be con-

sumed by the EHR application.

After analyzing the current difﬁculty of retrieving

patient data, this work proposes the development of an

EHR application that maintains and automates access

to information. The EHR application aims to store

and provide medical records about patients in a pub-

lic hospital. These patient data can be accessible by

doctors, nurses, health professionals in general and

also patients. Access to patient’s data can be realized

by devices such as desktops, laptops, tablets and mo-

biles.

Another important module implemented in the

EHR application deals with centralizing and control-

ling appointments. Currently, appointments’ manage-

ment requires that a hospital employee has to access

several systems. EHR application provides an impor-

tant requirement that enables appointment scheduling

in one single application. Therefore, the other sys-

tems will be accessed by the EHR through web ser-

vices.

After performing all records veriﬁcation proce-

dures, patients with scheduled appointment are for-

warded to the doctor’s ofﬁce according to the medi-

cal specialty needed. The appointment is carried out

and the doctor is responsible for updating the patient’s

record in the EHR in accordance with doctor’s ob-

servations. For each case, the doctor can prescribe

medicines, request exams and mark further appoint-

ments.

4 ARCHITECTURAL VIEWS

According to ISO/IEC/IEEE 42010 (ISO

42010:2011, 2011), an Architecture View refers

to a work product expressing the architecture of a

software system from the perspective of speciﬁc

system concerns. The EHR architecture proposed

as follows is the basis to develop the application in

a public hospital. The multiple views architecture

is important to describe the different aspects of the

architecture. This set of views is useful to describe

the entire system for different stakeholders, including

doctors, nurses, hospital managers and software

developers, from different perspectives. Parts of the

most representative views are presented as follows.

4.1 Scenarios View

Figure 1: UML Use Case diagram.

One part of the EHR functionalities is presented

in Fig. 1. The EHR developed in this research is able

to schedule medical appointments, register appoint-

ments, store patient records, visualize entire patient

records history, present results for patients’ exams,

and checking recommendations prescribed by doctors

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

310

or health professionals. Several requirements and Use

Cases were documented in this EHR project. How-

ever, due to space limitation, only a small number is

listed as follows. This set of Use Cases can provide

a glimpse of how the EHR improves automation of

hospital business processes.

UC1 Authentication

UC1.1 User login.

UC1.2 User logout.

UC1.3 Password recovery.

UC2 Insert electronic medical records about patient.

UC3 View electronic medical records.

UC4 View patient exam results.

UC5 Schedule medical appointments.

UC6 Seek medical appointments scheduled for spe-

ciﬁc dates.

UC7 Schedule exams.

UC8 Seek exams scheduled for speciﬁc dates.

UC9 Validate health card.

UC10 Seek patient diets and medical recommenda-

tions.

4.2 Business Process View

Fig. 2 depicts an Activity diagram which presents

the process for a medical appointment in the hospi-

tal. This process is detailed in the next paragraphs.

In most cases, appointments are scheduled by pa-

tients through the Basic Health Unit (BHU) located

near their residence sector. Each patient has one BHU

near to his/her house to request assistance when med-

ical care is needed. Some basic health services are

solved by clinicians in the BHU. Other more com-

plicated health situations are forwarded to the public

hospital.

On the appointment’s day, patient is received in

the hospital by an attendant at reception. The atten-

dant is a hospital employee who has login to access

the system and register the patient’s arrival. Hospital

attendant requests the number of the patient’s Health

Card, and then search in the EHR patient’s registra-

tion that contains date of appointment and medical

specialty.

Patients are received by the physician and then the

appointment is performed. Physician reports patient

records including clinical status and medicines pre-

scription. Finally, physician describes exams and new

appointments.

This process is responsible for scheduling and

managing appointments. This is a small part of the

Figure 2: UML Activity diagram - Medical appointment

process.

EHR scope and, currently, it is required to access ﬁve

different legacy systems to perform this task. In addi-

tion to this, patient record is manually written which

makes it difﬁcult further access by doctors. The de-

veloped EHR centralize this process, and also makes

it possible to use only one system because the other

systems are integrated by web services. Another ad-

vantage provided by the EHR is the fact that all in-

formation about patient health is stored in the system,

which facilitates medical diagnostic.

4.3 Implementation View

The EHR architecture proposes that users access the

application by using computers (desktops, laptops)

and also mobile devices such as tablets. Portability is

an important requirement requested by health profes-

sionals. According to the systematic review (Nguyen

et al., 2014) on EHR, portability and support for mo-

bile work have emerged as important system quality

attributes because several patients in hospitals have

difﬁculties to move. Applications running on portable

devices facilitates the transmission of information, for

example, doctors can explain an exam result for a pa-

tient showing images from the mobile device.

Development of an Electronic Health Record Application using a Multiple View Service Oriented Architecture

311

Figure 3: EHR Implementation View.

The EHR implementation view of the architecture

proposed in Fig. 3 is designed as a multi-layered

style. First layer, called Presentation, is about presen-

tation components that provide or receive information

to users. A web portal is developed to represent this

ﬁrst layer. According to previous decisions, as the

EHR application can be executed on different devices,

this layer must be independent from the lower layers.

Application layer is composed by an application

server where the user information inputs will be col-

lected and processed. This middle layer is composed

by the services layer that resolves technical issues for

the integration of different applications, solving prob-

lems of different data structures, connectivity to dif-

ferent protocols and speciﬁc needs of the involved

systems. Typically, components transformation, and

Routing Adapter are used.

The middle layer is composed by web services.

Within Service-Oriented Applications, it is extremely

important to clearly deﬁne some settings such as

which services should be implemented, which sys-

tems are providers and/or consumers, deﬁnition of

how to establish the interaction between systems and

which data types will be supplied in requests and re-

sponses.

The Data layer abstracts the contact point of the

SOA bus with legacy systems. Services providers

will supply the EHR application with patient data re-

quested by users.

Diagram depicted in Fig. 4 provides a global view

of system services. In addition to this, SoaML Service

Architecture diagram clearly presents all services that

should be implemented, which systems are involved

and which consumers and providers interact with the

application. Figure 4 presents eight services, which

are represented by an ellipse. Each service represents

one functionality of a legacy system that is exposed in

an Enterprise Service Bus (ESB) to be consumed by

a system consumer, the EHR in this case.

Figure 4 presents ACONE, CADWED, AGHU,

Medlynx and Imhotep, which are legacy systems in-

volved in this project as providers of services. Each

legacy system has important information about pa-

tients that will be consumed by the EHR. The EHR

system has been developed for consuming several ca-

pabilities scattered across multiple systems. Within

the SoaML Service Architecture diagrams it is possi-

ble to note that the EHR is a main consumer of data.

These important data about patients is exposed by ﬁve

legacy systems used as systems providers.

Another diagram presented in Figure 5, a SoaML

Participant diagram, represents logical or real peo-

ple or organizational units that participate in ser-

vices architectures and/or business processes. The

full speciﬁcation of a participant includes ports for

every service contract in which the participant par-

ticipates within the services architecture. Fig. 6

presents EHR participant diagram showing the use of

ports. Ports can be classiﬁed as  RequestPoint 

or  ServicePoint . System providers offer func-

tionalities exposing services and thus this partici-

pant type uses  ServicePoint  to represent ser-

vices in participant diagram. On the other hand,

 RequestPoint  is used when a system consumer

requests a service.

Figure 5 allows to visualize all legacy systems

involved and which services they should expose.

Within Service-Oriented Applications, it is extremely

important to clearly deﬁne settings such as which

services should be implemented, which systems are

providers and/or consumers, deﬁnition of how to es-

tablish the interaction between systems and which

data types will be supplied in requests and responses.

4.4 Logical View

Logical view is described by means of two different

and complementary diagrams, UML Class diagram

and SoaML Participant diagram. The UML Class di-

agram, as depicted in Fig. 7, is applied as a basis for

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

312

Figure 4: Service Architecture diagram representing legacy systems.

Figure 5: Participant diagram representing ports.

Figure 6: Data exchange between systems through services.

developing the EHR system. Fig. 6 presents another

Participant Diagram that depicts two systems that can

communicate with each other through a service. The

SoaML Participant diagram describes this situation.

This diagram has been chosen as it presents structural

view of services.

The EHR is a consumer system that request for a

valid health card service exposed by a legacy system

Development of an Electronic Health Record Application using a Multiple View Service Oriented Architecture

313

Figure 7: UML Class Diagram.

named CADWEB. EHR gives a request containing a

health card number and CADWEB receives this pro-

vided number as request. Then, the valid health card

service is executed and provides a conﬁrmation as re-

sponse that is captured by the EHR.

5 CONCLUSIONS

This paper presents an architectural description using

multiple views for an EHR system based on SOA. The

EHR application developed is a demand of a public

hospital that has several legacy systems for different

purposes. In most cases, literature proposes SOA ap-

plication in EHR domain without addressing archi-

tectural concepts. As presented in Section 2, some

studies propose EHR architecture using natural lan-

guage and some using informal draws. This scenario

can represent that there is focus on the application it-

self. However, in software development process, it is

necessary to address architectural elements as well.

Some other studies concerned on EHR architecture

presents the software architecture by describing only

one or two architectural views, or even two views

described on the same diagram, making it difﬁcult

for most stakeholders to understand the architectural

models.

Contrary to most other works found in the litera-

ture, this work proposed EHR architecture using mul-

tiple views. Four architectural views, Scenario, Busi-

ness Process, Logical and Implementation, are pre-

sented to provide an overview of the development of

a SOA application in the health domain. Each view

presents different elements, improving separation of

concerns. Software architecture is documented in

multiple views in order to help stakeholders to better

understand the future software system. In addition,

architecture description using multiple views allows

managing complexity and risks during software de-

velopment.

This paper describes part of the EHR architec-

ture, which is applied to gather requirements by hos-

pital stakeholders such as doctors, nurses, reception-

ist and health professionals in general. The proposed

architecture has been proven to be extremely impor-

tant to validate EHR scope by stakeholders because

they could understand what would be developed. Ar-

chitecture views presented are important because, in

general, hospital stakeholders are not experts in infor-

mation technology technical concepts. Thereby, sce-

narios and business process views are fundamental to

facilitate understanding of future system functionali-

ties through diagrams such as Use Cases and Activity

diagrams.

In addition, the proposed EHR architecture has

been crucial for software developers. They clearly

could understand through multiple scenarios, busi-

ness processes, layers, and architectural decisions

what should be implemented. Documenting software

architecture facilitates the development but also fur-

ther maintenance. As a conclusion of this case study,

after development of the EHR application using SOA,

it is clear that investing time and effort documenting

the software architecture is beneﬁcial to the system

development process. Multiple architectural views

enable most stakeholders to understand the project

scope, even if they are not expert in software devel-

opment.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

314

ACKNOWLEDGEMENTS

The authors would like to thank the Brazilian re-

search agency CNPq (grant 445500/2014-0) for ﬁnan-

cial support.

REFERENCES

Bertolino, A., Inverardi, P., and Muccini, H. (2013).

Software Architecture-based Analysis and Testing:

A Look into Achievements and Future Challenges.

Computing, 95(8):633–648.

Booch, G. (2007). The Economics of Architecture-First.

IEEE Software, 24(5):18–20.

Carvalho, M. B., Bellotti, F., Berta, R., Gloria, A. D., Gaz-

zarata, G., Hu, J., and Kickmeier-Rust, M. (2015). A

Case Study on Service-Oriented Architecture for Se-

rious Games. Entertainment Computing, 6:1–10.

Cho, I., Kim, J., Kim, J., Kim, H. Y., and Kim, Y. (2010).

Design and Implementation of a Standards-Based In-

teroperable Clinical Decision Support Architecture in

the Context of the Korean EHR. Int. J. of Medical

Informatics, 79(9):611–622.

El-Sappagh, S. H. and El-Masri, S. (2014). A Distributed

Clinical Decision Support System Architecture. Jour-

nal of King Saud University - Computer and Informa-

tion Sciences, 26(1):69–78.

Fabian, B., Ermakova, T., and Junghanns, P. (2015). Col-

laborative and Secure Sharing of Healthcare Data in

Multi-Clouds. Information Systems, 48:132–150.

Franc¸a, J. M. S., de S. Lima, J., and Soares, M. S. (2016).

A Case Study on SoaML to Design an Electronic

Health Record Application Considering Integration of

Legacy Systems. In 40th IEEE Annual Computer Soft-

ware and Applications Conference, COMPSAC 2016,

pages 353–358.

Garlan, D. (2014). Software Architecture: A Travelogue. In

Proc. of the on Future of Software Engineering, FOSE

2014, pages 29–39.

Gazzarata, G., Gazzarata, R., and Giacomini, M. (2015).

A Standardized SOA Based Solution to Guarantee the

Secure Access to EHR. Procedia Computer Science,

64:1124–1129.

Gonz

alez, M.

A. C., Garc

ıa-Pe

nalvo, F. J., Forment, M. A.,

Mayol, E., and Llamas, C. F. (2014). Implementa-

tion and Design of a Service-Based Framework to In-

tegrate Personal and Institutional Learning Environ-

ments. Science of Computer Programming, 88:41–53.

ISO 20514:2005 (2005). ISO 20514:2005 Health informat-

ics, Electronic health record - Deﬁnition, scope and

context. Technical report, ISO, Geneva, Switzerland.

ISO 42010:2011 (2011). ISO 42010:2011 Systems and soft-

ware engineering Architecture description.

Kabir, M. A., Han, J., and Colman, A. W. (2014).

SocioTelematics: Harnessing Social Interaction-

Relationships in Developing Automotive Applica-

tions. Pervasive and Mobile Computing, 14:129–146.

Marchetta, P., Natale, E., Pescap

e, A., Salvi, A., and San-

tini, S. (2015). A Map-Based Platform for Smart

Mobility Services. In Symposium on Computers and

Communication, ISCC 2015, pages 19–24.

Monsieur, G., Snoeck, M., and Lemahieu, W. (2012). Man-

aging Data Dependencies in Service Compositions.

Journal of Systems and Software, 85(11):2604–2628.

Moor, G. D., Sundgren, M., Kalra, D., Schmidt, A., Dugas,

M., Claerhout, B., Karakoyun, T., Ohmann, C., Las-

tic, P.-Y., Ammour, N., Kush, R., Dupont, D., Cug-

gia, M., Daniel, C., Thienpont, G., and Coorevits, P.

(2015). Using Electronic Health Records for Clinical

Research: The Case of the EHR4CR Project. Journal

of Biomedical Informatics, 53:162–173.

Nguyen, L., Bellucci, E., and Nguyen, L. T. (2014). Elec-

tronic Health Records Implementation: An Evaluation

of Information System Impact and Contingency Fac-

tors. Int. J. of Medical Informatics, 83(11):779–796.

OMG (2012). Service Oriented Architecture Modeling

Language (SoaML) Speciﬁcation. Technical report,

http://www.omg.org/spec/SoaML/1.0/PDF.

Papazoglou, M. P., Traverso, P., Dustdar, S., and Leymann,

F. (2008). Service-Oriented Computing: a Research

Roadmap. Int. J. Cooperative Information System,

17(2):223–255.

Soares, M. S. and Franc¸a, J. M. S. (2016). Characterization

of the Application of Service-Oriented Design Prin-

ciples in Practice: A Systematic Literature Review.

Journal of Software, 11(4):403–417.

Traore, B. B., Kamsu-Foguem, B., and Tangara, F.

(2016). Integrating MDA and SOA for Improving

Telemedicine Services. Telematics and Informatics,

33(3):733–741.

Welke, R., Hirschheim, R., and Schwarz, A. (2011). Ser-

vice Oriented Architecture Maturity. IEEE Computer,

44(2):61–67.

Development of an Electronic Health Record Application using a Multiple View Service Oriented Architecture

315