A Dynamic Extensible Personal Health Record
Pedro Catré
, Alcides Marques
, João Quintas
and Jorge Dias
Instituto Pedro Nunes, Coimbra, Portugal
University of Coimbra, Coimbra, Portugal
Keywords: Personal Health Record, Informal Healthcare, e-Health, Databases.
Abstract: This paper presents a system that enables the configuration of a Personal Health Record supporting informal
care services in a way that is extremely flexible and simple and allows the development of dynamic
extensions even in a production environment. With this system powering the Personal Health Record it is
possible to modify the repository’s data structure, clinical data viewer and business logic, adapting the
system to new requirements in a fast and easy manner without the need for redeploy.
TICE-Healthy is a research and development project
supported by a consortium of 24 companies and
R&D institutions that aims to design and create
innovative e-health products. The first line of action
of this initiative is to create an information and
interaction channel for selling products and health
services, which will provide a Personal Health
Record (PHR) – a repository of clinical information
of an individual whose maintenance and updating
can be performed by himself or by his caregivers.
This PHR will have to satisfy the needs of
several service providers with evolving
requirements. Even though typical clinical data is
very standardized, this repository will also store data
for informal care services which are not uniform.
Moreover, there is a great overhead associated with
the change in requirements which usually force not
only revisions to the data access and business layers,
but also to the interface. The code produced in these
types of scenarios is repetitive; its development is
slow and potentially subject to many mistakes and
changes would not be directly applied in a
production environment as would be desirable.
To satisfy the requirements of the platform’s
healthcare management system we implemented a
module called TICE-GenericEntity that administers
entities and generates components to visualize and
manipulate entity records. Additionally, it allows the
creation from scratch and dynamic modification of
entire web applications for data visualization and
manipulation, with menus containing web
components, and it generates a REpresentational
State Transfer (REST) Create, Read, Update and
Delete (CRUD) Application Programming Interface
(API) for the clinical entities that are defined.
This paper presents a system that enables the
configuration of a PHR supporting informal care
services in a way that is flexible and simple and
allows the development of extensions even in a
production environment.
Any system seeking the extensibility described
needs mechanisms to save the settings of the clinical
entities that are created, which can include: the
mapping of entity attributes to database columns; the
properties of the attributes; the different web views
for inserting, updating, showing and listing entity
records; and the events and business rules to validate
submitted records and perform operations when
specific conditions are met. The decision was to
store all the entity configurations in a field of a
database table using the JavaScript Object Notation
format. This way it is possible to apply automatic
serialization, it is easy to manage versions of the
configurations as they evolve and allows good
performance given that a single database access is
required to acquire all the metadata pertaining to an
entity. Custom server-side rules are also stored in a
field of the database and compiled at runtime using
Catré P., Marques A., Quintas J. and Dias J..
TICE-Healthy - A Dynamic Extensible Personal Health Record.
DOI: 10.5220/0004244903480351
In Proceedings of the International Conference on Health Informatics (HEALTHINF-2013), pages 348-351
ISBN: 978-989-8565-37-2
2013 SCITEPRESS (Science and Technology Publications, Lda.)
JBoss Drools business rules engine. The result of the
compilation is stored and it is only recompiled when
changes to the rules occur.
Figure 1 presents the logical organization of the
Figure 1: Overview of the system’s main components.
The figure identifies 5 major components:
Core Module – is responsible for the storage and
provision of the entities’ configuration and records
to the viewer and external applications;
Viewer Module – interprets the configuration
and creates the views;
The Menu and Entity Manager – is a back-office
where system administrators can manage entities
and define which menus make up the PHR’s
website, what components (for example: forms, list
of records, charts of the data) appear in each menu,
how are the components related (for example editing
a record can cause an automatic update in a list of
records or a chart, or even trigger a health alert
Entity Editor – allows the creation of new
entities and editing of existing entities in a visual
App Website (in this case the PHR Viewer) – is a
rendering of the configurations that were previously
described that uses client-side routing and
templating together with Asynchronous JavaScript
and XML (AJAX) requests to provide a comfortable
and rich user experience.
Note that the Menu Manager, Entity Editor and PHR
Viewer are client-side applications created using the
JavaScript framework Backbone. The Generic Entity
Core and Viewer are server side applications created
using the Java web framework Play. The databases
are implemented in PostgreSQL. Together, the 5
components presented allow a database schema to be
mapped to a user interface.
In this section we will analyse four methods for
storing data in the repository and present the strategy
implemented by our system. The aim was to have a
flexible repository that handles new data types and
attributes without the need to change the physical
database schema, while still supporting efficient and
easy to construct ad-hoc queries to the data.
A classic approach is to use a text format like
Extensible Markup Language (XML) or JSON to
store the keys (entity’s attribute) and corresponding
values (Xie et al., 2010). This method would require
the database management system to support
Structured Query Language (SQL) over XML fields
in order to apply ad-hoc queries, which is an unusual
and costly operation.
Another approach frequently employed in
clinical scenarios and other cases where the number
of attributes, properties or parameters that can be
used to identify an entity is potentially unlimited, is
to use an Entity-Attribute-Value (EAV) model
(Gilchrist et al., 2011). An EAV design usually
involves a central table with three columns that
contain data referring to: the entity, the attribute and
the value of that attribute. While this approach
allows ad-hoc queries, they are not straightforward
and would typically require a resource consuming
transform/pivot operation.
Alternatively the system can use a flexible
schema strategy involving the dynamic creation of a
table with specific fields for each new entity that
needs to be defined. In this case the majority of
changes to entities would lead to Alter Table
operations which are usually blocking and can be
slow if the table is storing a lot of data.
Another solution we call Generic Table involves
the use of a sufficiently generic table with pre-
created columns of various types. For example a
table may contain 80 text fields, 20 integer fields
and so on, and there will be a mapping for each
entity specifying which columns it uses for its
attributes. An illustration of this approach is
presented in Figure 2.
Figure 2: Example of a generic table.
Using this technique all records corresponding to
each entity may be stored in the same table and we
avoid the runtime alteration of the data structure.
Microsoft SharePoint platform uses a similar
approach (Krause et al., 2010). The main
disadvantages of this solution is that it will result in
sparsely populated columns with many null values,
something that is not elegant and usually leads to a
waste of space, and ad-hoc queries become less
intuitive since the names of the database columns
will not correspond to the names of the entity
TICE-GenericEntity supports the last two
strategies. By default it uses a Generic Table for
storage but the developer can also choose to create
and configure custom tables. Therefore, it is possible
to use our solution on top of a regular database
schema by adding a few specific configuration
columns to each table used by an entity.
Since the solution presented in this paper is highly
configurable and flexible it was expected that it
would display a significantly lower performance
than static solutions. Therefore, it was important to
analyze whether the overhead of this solution would
have a manageable impact on the overall context of
a web application.
The goal of these tests was to compare the
performance of the solution developed against a
typical Object Relational Mapping (ORM)
implementation using the same web framework. For
that purpose we created two applications with the
Java web framework Play: one that used this
framework’s ORM mechanisms and another that
used our solution (TICE-GenericEntity).
The tool used for the tests was Apache JMeter
and the tests were executed with the following
With and without the use of cache mechanisms;
With an empty database and a database
populated with 100.000 records created at random,
but equal for both applications being compared;
In TICE-GenericEntity we used the system’s
generic table with 138 pre-created columns (30
strings, 14 booleans, 12 texts, 13 dates, 13 floats, 13
longs, 14 integers, 13 numbers, 12 reals and 4
With entity A composed of 5 attributes (3
strings, 1 integer and 1 text) and entity B with 15
attributes (8 strings, 2 integers, 1 text, 1 date, 1 float,
1 long and 1 time);
Each test result is the average of 500 test runs.
In these tests we chose not to use concurrent
requests (multiple users) since the first tests showed
that this caused considerable deviations between
identical runs and it did not help in the comparison
of approaches.
4.1 Record Insertion and Retrieval
Figure 3 presents the average time needed for the
insertion of 50 records in the two applications being
compared, for both entities A and B. Since the test is
executed 500 times and each test inserts 50 records,
the database becomes increasingly populated. These
tests are executed in an originally empty database
and on a database that is initially populated with
100.000 records. We also performed the tests
caching the requests to the database for entity
Figure 3: Comparison of the average time needed to insert
50 records.
The results obtained were surprising and better
than anticipated. It was expected that our approach
would be significantly slower since it had to
iteratively build the object to insert in the database
verifying each parameter received in the Hypertext
Transfer Protocol request against the attributes
defined in the configuration and also create the
insertion statement using a dynamic configuration.
According to the results these extra operations
exhibited very low overhead.
The tests using the extended entity B showed a
negligible impact. Therefore, the solution does not
appear to show limitations related to the number of
attributes defined in the entity.
Figure 4 presents the average time needed along
with the standard deviations for the retrieval of 50
records from the database.
Figure 4: Comparison of the average time needed to obtain
50 records.
Both applications show a low variance in their
response times. The results also indicate that TICE-
GenericEntity is slower running the tests on a
populated database. The difference is less than 10
milliseconds and it is due to the fact that the ORM
based application does not have to retrieve as many
attributes (for example it does not have the
timestamp of creation or last update of the object)
and it does not order the results before returning
them, while by default TICE-GenericEntity orders
the results by timestamp of creation since it always
returns them paginated because of salability
4.2 Form Generation
The purpose of these tests is to compare the average
time needed by TICE-GenericEntity to generate and
return an insertion form against the time needed for
a normal application to return the same form already
created. In other words, our solution will interpret
the configuration of an insertion view in order to
generate it while the ORM application will simply
return the same form (pre-created) as static content.
Figure 5 shows the results of the tests performed.
Figure 5: Comparison of the average time it takes to return
an insertion form.
In these tests the creation of the form is roughly
10 times slower than presenting a static form. Once
again this result was surprisingly positive given the
nature of the comparison. In fact, it was clear that
the solution that had to dynamically generate the
form would be slower and it is perfectly acceptable
for it to be 10 times slower since there are
mechanisms to mitigate this difference. Using cache
in both applications the results were, naturally,
As shown, despite its dynamism and flexibility our
solution does not display a great overhead when
compared with a traditional approach. Naturally, the
generation of views is slower than the simple return
of static content, but it is a relatively insignificant
overhead when taking into account factors such as
network latency. It is also import to state that the
applications comprising our solution are stateless so
it is simple to apply a load balancing pattern to scale
the system. Moreover, the tests revealed that using
cache mechanisms to mitigate the extra resource
usage is extremely effective.
In summary this paper presents a module that
enables the configuration of a PHR supporting
informal care services in a way that presents major
benefits for the entire TICE-Healthy initiative. With
this component powering the PHR it is possible to
modify the repository’s data structure without
redeploy and it is easy to make changes to the data
viewer and business logic with minimal coding.
In the future we will explore non-relational
alternatives for storing data that may prove to be
more flexible and perform better. Specifically,
migrating the system to such a data store might free
us from the limitations of having pre-created
columns. However, several concerns will have to be
addressed first, such as the security mechanisms
provided, the ability to execute ad-hoc queries and
the support for transactions.
The TICE.Healthy project is co-financed by the
European Community Fund through COMPETE -
Programa Operacional Factores de Competitividade.
Gilchrist, J., Frize, M., Ennett, C. M. & Bariciak, E., 2011.
“Performance Evaluation of Various Storage Formats
for Clinical Data Repositories,” IEEE Transactions on
Instrumentation and Measurement, vol. 60, no. 10, pp.
3244–3252, viewed 5 March, 2012,
Krause, J., Langhirt, C., Sterff, A., Pehlke, B. & Doring,
M., 2010. SharePoint 2010 as a Development
Platform, Apress; 1 edition, p. 800, viewed 24
November, 2011, <http://www.amazon.com/
Xie, L., Yu, C., Liu, L. & Yao, Z., 2010. “XML-based
Personal Health Record system,” 2010 3rd
International Conference on Biomedical Engineering
and Informatics, IEEE, pp. 2536–2540, viewed 24
October, 2011, <http://ieeexplore.ieee.org/xpl/