
 
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