information is not allowed, the delete operation was
not implemented. This is one of the fundamental
rules that must not be violated in order to ensure
coherence and consistency of the stored information.
Queries are important features to bear for any
information system. This importance becomes even
more critical when the volume, complexity and
variability of the stored data increase.
Considering the Archetypes modelling approach
and the variability of the Archetypes structure
becomes critical the existence of specific search
syntax sufficiently flexible to answer the needs of
the final information consumers (i.e. applications).
Therefore, we propose a domain specific language
with adequate syntax to formalize flexible queries.
A search is formalized through a Search
operation that contains a Query or a Filter
mechanism.
The Query mechanism is prepared to be used
when searching free text fields, which is extremely
useful for research in fields with long text, or when
the result should be sorted by relevance. On the
other hand, it is recommended to use the Filter
operations in binary searches (i.e. searches that
return yes or no results), exact value searches (i.e.
filtering by a certain value) and recurrent searches
that need to be optimized by caching mechanisms.
The formalization of a Filter or a Query search
can be refined with additional criteria including
different types of operators (e.g. Boolean, exact,
range or fuzzy).
Archetypes are complex structures and,
therefore, the platform provides dedicated services
to create and edit them. Furthermore, the support
services provide search functions for the selection,
within the existing Archetypes, the one that must be
edited, and the required operations to manage the
information introduced by the application domain
experts and to manage the different Archetypes
versions.
The developed support services use the LiU
Archetype Editor of the openEHR framework, which
has been complemented by a parser able to adjust to
RIM.
The Archetypes processed by the parser can be
included in an Archetypes repository. This is an
application that allows all the required Archetypes
operations, namely, searching and publishing,
authentication, versioning and ownership
management.
Once the applications that can be supported by
the platform We.Can necessarily have a broad range
of requirements in terms of user interfaces and that
these interfaces must evolve over time with the help
of domain experts and the end users themselves, it is
important to have a support development services
based on the Archetypes formulations for the
extension of the presentation features.
The presentation service provides a generic
interface to create, access, modify and delete records
based on existing Archetypes without the need to
change the persistence layer. The selected
development environment was the Play Framework,
which is a web framework based in Java and the
configurations of generic entities are stored in
JSON.
The created custom fields are dynamic so that
they can be modified at runtime. Depending on the
predefined configurations there is a code generation
component that is able to create a visual
representation of the Archetype contents and
implement the business rules that govern them.
Among the features provided by the module it
should be pointed the following: i) abstraction of
data access and business rules; ii) customization of
fields and web components (e.g. data type,
maximum size or validation constrains); iii)
automatic update of the template whenever there is a
definition of new components; iv) automatic
generation of custom forms for viewing, entering
and editing data; and v) versioning management.
There are four types of views that can be
configured, namely: i) insertion view; ii) edit view;
iii) presentation view (i.e. a view to present data
from a register); and iv) data list view.
In order to allow having presentation services
truly flexible and extensible independently of the
application environment it is necessary to provide a
mechanism to define and modify business rules of
the final application.
The most common validations are pre-
programmed accordingly to rules based on the
Archetypes definition. Additionally, there is the
possibility to validate one or more fields of a
presentation entity in a different way that the one
initially foreseen. For example, if we had two date
type fields whose validation rules include the
requirement that the content of the field should be
posterior to the first one, and this had not been
planned, it should be possible to add a rule to
validate this condition. Beyond this basic case there
are many others cases that may rely on the rules
engine to allow the application modification without
recompilation and deployment costs
A rules engine helps to reduce the problems and
difficulties inherent to the development and
maintenance of the business logic of an application
(e.g. the recompilation and deployment costs).
HEALTHINF2014-InternationalConferenceonHealthInformatics
420