9 Health Telematics Networks
Piotr Nawrocki
1, Dominik Radziszowski
11
Department of Computer Science, AGH University of Science and Technology, Krakow, Poland
The healthcare sector [7] is characterized by increasing specialization among the parties: hospitals, either public or private, practitioners, pharmacies, social insurance etc. which generate an intensive structured communication flow. A major driving force behind the development of telematics for health is to more efficiently manage the healthcare delivery process, while providing more user- oriented applications and integrated solutions in such areas as continuity of care, patient records, regional healthcare telematics networks and health information to the citizen.
This chapter presents the problems of the health telematics network. Some technical aspects of the network communication are presented in Chapter 5 – (“Wireless Systems in e-Health”). Information about security in the e-health systems is found in Chapter 4 – (“Security and Safety of Telemedical Systems”).
1 Transport Layer in Telematics Networks
One of the most important issues when designing telematics networks is assuring reliable and suitable communication [10] between computer nodes.
Due to the specific conditions in medical networks (among others, data protection), telematics networks should have a very high level of security. The transport layer describes all communication aspects of telematics computer networks.
1.1 Packet-Based Communication
Along with the evolution of the Internet, a wide range of services and
capabilities of computer networks has been developed. Existing network
protocols such as TCP/IP
1and UDP/IP are based on packet transmission and predominate in backbone of telematics networks. This conception of transmission is suitable for multimedia of audio/video streams, and hence is of great importance for telematics networks. Modern telematics applications make use of picture, video and sound for sending information. Multimedia transmission requires specific network conditions and parameters. The possibility of losing packets, lack of retransmission of packets, and unauthorized access are problems which programmers of telematics (and particularly teleconsultation) applications must tackle. DSL and ADSL solutions are recently becoming increasingly popular. This technology is not expensive and remains suitable for most users, but it is not satisfactory for streaming A/V data. These solutions exhibit transmission asymmetry and only one direction has good bandwidth, while the opposite direction transmission bandwidth is comparable to dial-up technology (and it is not adequate for multimedia transmission).
1.1.1 Edge Access Technologies
The base backbone technology for communication in telematics networks is based on packet transmission in wire media. Additionally, for communication between nodes (for example between doctors and patients at home or hospitals and ambulances), modem communication or wireless technology can be used.
In scenarios where patients exchange medical information with doctors the cheapest way of communication is a modem (and new DSL and ADSL technology). This solution is sufficient for exchanging textual data (for example blood pressure) but the bandwidth is too low for examination results presented as audio/video. New wireless technologies are sufficient for audio/video streams and also provide communication with mobile nodes (for example ambulances). There are some wireless technologies (see Chapter 5) for communication in networks. Among the diverse wireless technologies available, users can choose the networks most suitable for telematics.
1.1.2 Quality of Service
Modern computer networks enable connecting independent (until now) topologies for data, video and voice transmission into one infrastructure that uses IP technology. Bringing together so many applications with diverse requirements for parameter values in the network layer forces one to consider
1
The IP standard version 4 is being used currently but technological developments and a rapid
increase in numbers of people using IP addresses (as a result of an increase in the number of
network devices) have spurred the development of a new standard - IP version 6. The new
standard also solves the problem relating to a large number of network addresses.
Quality of Service (QoS) mechanisms. These mechanisms make it possible to unify all available computer networks’ usage with assurances of an appropriate service level. QoS mechanisms are indispensable where traffic overloads may potentially appear, to assure that traffic sensitive to packet losses and delays (e.g.
real-time audio and video) is prioritized with respect to computer data where such faults are better tolerated. Usage of QoS solutions is critical at the point of contact of local networks with bandwidths of hundreds of megabits per second, and slow WAN links, where aggregation of hundreds of kilobits of available bandwidth is performed.
2 Health Digital Data Standards
Thus far, we have discussed generic network communication standards; there is also a set of standards specific to the healthcare industry. Some of these concern equipment, and some concern patient records. Problems arise when there is a need for integration of different hospital systems in one functionally-coherent system, e.g. the creation of HIS (Hospital Information System) based on RIS (Radiological Information System), LIS (Laboratory Information System) and PACS (Picture-Archiving and Communication System). In such situations, dedicated programmer interfaces and data conversion dictionaries have to be created. A better solution is to set up standards for medical data interchange, standards sufficiently open and universal that they would allow for effective integration of systems working on different system and hardware platforms and using different data representations.
The current situation is that there exists a large number of inconsistent standards. Major health informatics standards applicable to medical data representation, interchange and secure communication, originate from CEN (Comité Européen de Normalisation - Technical Committee 251) [9], [1].
2.1 ENV 13606: EHCR Communication (1999)
This four-part European pre-standard (ENV) [9] governs the representation of EHR information as it might be communicated between two repositories or between a client and a server. In its four parts it defines:
x the object model that must be used to represent the EHR,
x a set of term lists that must be used to populate key attributes defining the classes of information being communicated,
x a set of rules and an information model governing how access control requirements should be specified,
x a set of message specifications to support message-based exchange e.g.
using XML.
In December 2001 CEN TC/251 confirmed a new Task Force, known as
“EHRcom”, to review and revise the 1999 four-part pre-standard ENV 13606 relating to Electronic Healthcare Record Communications. The intention of this work is to propose a revision that could be adopted by CEN as a formal standard during 2004. The overall mission statement of the EHR communications standard proposed by the Task Force is to produce a rigorous and durable information architecture for representing the EHR, in order to support the interoperability of systems and components that need to interact with EHR services:
x as discrete systems or as middleware components, x to access, transfer, add or modify health record entries, x via electronic messages or distributed objects,
x preserving the original clinical meaning intended by the author,
x reflecting the confidentiality of that data as intended by the author and patient.
A combination of good working relationships between CEN, openEHR [13]
and HL7 [12] has led to an intention to harmonise the proposed new standard both with openEHR (reference model and archetype approach) and with HL7 [1].
2.2 Health Information Systems Architecture (HISA) ENV12967 defines an open systems architecture facilitating the development of products and services by different vendors. It defines the structure for how healthcare information systems should be built, implemented and used. It specifies the interactions between hospital information systems, organisations and users, and the control, storage and manipulation of the different types of data in the various components of the system.
HISA services are divided into:
x Generic Common Services which would be found in the core information systems in any business domain,
x Healthcare Common Services which are more specific to healthcare but common to most applications within healthcare: subject of care, activities, resources, authorisation, patient health characteristics.
A new HISA Task Force was established in early 2002 to revise this standard,
and this work is expected to be completed during 2003-4 [1].
2.3 Health Level 7
This US-based international organisation, generally known as HL7 [12], is responsible for the most widely adopted standard for message-based communication in healthcare. HL7, whose message specifications were first published in 1988 as an industry standard, was awarded Standards Development Organisation (SDO) status in 1993 so that newer versions of the specification are official ANSI legislative standards. The messages primarily support the interoperability of components of a hospital information system and purchaser- provider contractual communications.
HL7 Version 2 messages have been developed to reflect standardised reporting data sets for several aspects of a patient’s care in hospital:
x patient admission, transfer or discharge (ADT), x orders for drugs, procedures or tests and their results, x messages relating to finance and billing information, x clinical observations focussing primarily on measurements.
Despite its wide international usage, the problems of inconsistent implementations of Version 2 and the unsystematic growth of message segment definitions have limited the realisation of interoperability, leading to the drafting of a new v3 standard. A key feature of Version 3 is the Reference Information Model (RIM): a means of specifying the information content of messages through an information model that clarifies the definitions and ensures that they are used consistently. The RIM is a formal object model, expressed using UML, representing the superset of core classes and attributes that will be required (in various combinations) by the different HL7 Version 3 messages.
The HL7 Clinical Document Architecture (CDA) is a proposal for the generic structure of clinical documents, and is sometimes regarded as the HL7 equivalent of a record architecture. Only “Level One” of the CDA has at present been ratified: this XML-based specification includes a header with document authorship information, organisational origin and patient identifiers, and a body whose basic structure is loosely defined at this stage.
HL7 version 2 is presently being used in the United States, Australia, Canada,
Germany, the Netherlands, Israel, Japan and New Zealand. Additional countries
are joining each year [1].
2.4 Standards for Images - DICOM
The Digital Imaging and Communications in Medicine (DICOM) [11] standard arose out of a precursor standard for images (ACR-NEMA) that was first published in 1985 by the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA). The DICOM standard is the most widely used common data representation internationally for the various medical images acquired and communicated. It has addressed many of the issues of vendor-independent data formats and data transfers for digital medical images. CEN and ANSI have adopted DICOM by reference in their imaging standards.
DICOM is a result of efforts to create a standard method for the transmission of medical images and their associated information which started in the 1980s.
Having an open architecture, DICOM enabled equipment from different manufacturers covering a range of examination types (so-called modalities) to be interconnected. This is why it soon has become the industry standard.
Distinct from various general-purpose graphical formats, DICOM files offer very good, diagnostic quality of the images, although, where worse quality is clinically acceptable, lossy compression can be applied. DICOM files contain many so-called tags (name-value pairs) precisely describing not only the image and how to properly display it but also information with patient demographic data and examination annotations. The operations which are the most characteristic of DICOM format are the following: adjusting Hounsfield window value, animating dynamic images (e.g. from coronarography examinations), displaying contained tags and marking annotations. Hounsfield window scale adjusting is necessary to notice the subtle differences between some tissues, and two parameters are used here: the value, expressed in Hounsfield Units (HU), and the window’s width; the values outside the window border are non-distinguishable.
DICOM is not only the specialised file format but also a client-server protocol.
It introduces different services (e.g. storage, printing, displaying) called the Service Class and their providers (SCP) and users (SCU). For example, a laser printer is the SCP providing printing service for a workstation (being Print SCU). Infrastructure of hospital PACS systems consists of many such devices.
The security issues pertaining to medical information have come under more
serious consideration in recent years. This manifests not only in installing
firewalls in hospitals but also in DICOM protocol changes. DICOM standard
authors, in consecutive annexes, address, among others, secure transport
connection, data integrity and authentication of users and media security (e.g.
encryption of the file while storing DICOM data on media). Altogether, this allows efficient transfer of medical data over insecure networks [3].
Integrating the Health Environment (IHE) is a recently-formed industry-sponsored organization seeking to promote interoperability between systems within specialist departments such as radiology, and the conventional hospital systems used to order such investigations and to receive imaging study reports. It works closely with DICOM and HL7 in this area [1].
GP
RadiologyBio-signals
Laboratory ADT
Pharmacy
DICOM DICOM
DICOM SR IHE
HL7
CEN EN13606 HL7 CDA
Patient’s home
Admin
Clinical records CEN EN13606
HL7 CDA CEN EN13606
HL7 CDA
Hospital
CEN EN13606 HL7 CDA
Community health centre
Person healthrecords
Admin
CEN EN13606 HL7 CDA Clinical
records
Clinical records