sure of systems value through high quality services;
have modular architecture to allow developments,
maintenance and evolutions and so, enable
“monotonic” systems with an incremental evolution.
The creation of distributed clinical information,
maintaining autonomy, needs to be tested to avoid
conflicts that can occur in three levels (table 1)
(Román et al., 2006).
Table 1: Description of problems related to the different
levels of interoperability.
Levels Description of conflict
Semantic
Originate on different databases schemas that
were created independently. Interoperability is
only possible in previously common semantic
concepts.
Functional
Different components usually have different
functionalities and interfaces. A federated system
is based in a single identification and view. The
information must be exported functionality
according to the normalized interfaces.
Instance
Happens when the same person information’s
stored in different systems has to be merged. The
corresponding Personal ID handled by each
system must be found with the guarantee that it
refers the correct person and prevent a value
conflict.
3.1 Messaging versus Federation
Interoperability between systems can be made
through messages or federation.
3.1.1 Message-based
The message-based communication, in particular
based on HL7/DICOM, is considered as a
mechanism that facilitates the functional integration
of clinical information systems and administration,
institutional or regional level, resulting in the
automation of medical processes (Katehakis et al.,
2001).
This form of messaging is mainly used to share
only portions of the I-EHR and uses various
locations to store information, what results in
redundancy of information generated (which, in
many cases, can lead to inconsistencies) because it
focuses on episodes of care and referrals and
facilitates rapid entry of data, to cover a fairly large
number of end-user requirements.
3.1.2 Federated Approach
The federated approach is mainly used to promote
the virtual view of IEHR, without information
replication.
Any federated approach to an I-EHR
environment should be able to supply uniform
means of authentication, providing quick and
authorized access to personal health records; be
physician-generated and dispose patient record
information that is physically located in a different
clinical IT system (Katehakis et al., 2001).
3.2 Reference Architecture for the
Health Information Infrastructure
(HII)
The development of global information societies led
many countries to give high priority to create and
permit access to the I-EHR of a citizen. Therefore,
another priority is the creation of a health
information infrastructure (HII) to support the
provision of a variety of telematics and healthcare
services electronically (Tsiknakis et al., 2002).
A medical institution regional/national HII is
fundamentally about bringing timely health
information and aiding communication that brings
benefits for health decisors, their families, their
patients, and their communities. By this way,
individuals and public health professionals are HII
stakeholders and users, and the applications that
meet their respective needs are important
components of the infrastructure (Tsiknakis et al.,
2002).
Taken as a whole, the HII draws upon principles,
best practices, partnerships and necessary laws, but
is based on the use of standards, systems,
applications, and technologies that support
personalized healthcare services through the
effective information integration of networked
information sources (Tsiknakis et al., 2002).
The system’s architecture is a formal description
of an IT system, organized in a way that supports
reasoning about the structural properties of the
system. It defines the components that make up the
overall information system, and provides a plan to
implement the overall system. Usually is represented
by means of an architecture model. The Reference
Model Open Distributed Processing (RM-ODP) is
an architecture model used actively by industry in
the domain of healthcare that sets a standard of
reference for an open distributed processing
(Tsiknakis et al., 2002).
The purpose, therefore, of an architecture
regarding the technical aspects for developing a HII
is to provide and enable interoperability; modularity;
migration; stability; maintenance and cost-
effectiveness.
HEALTHINF 2012 - International Conference on Health Informatics
160