Recommendations and quality criteria for hospital information systems

(Version 1 December 2002)

Prof. Dr. Bart Van den Bosch Prof. Erwin Bellon Andr De Deurwaerder Mark Vanautgaerden Dr. Marc Bangels

Contents
1 2 INTRODUCTION ........................................................................................................................................ 4 ARCHITECTURE AND INTEGRATION OF THE HIS ........................................................................ 6 2.1 INTRODUCTION ........................................................................................................................................... 6 2.2 DEFINITIONS ............................................................................................................................................... 7 2.2.1 2.2.2 2.3.1 2.3.2 Connected systems............................................................................................................................. 7 Integrated systems ............................................................................................................................. 9 Splitting by user group .................................................................................................................... 13 Splitting by department ................................................................................................................... 14

2.3 SPLITTING OF THE HIS: CONTENT OPTIONS ............................................................................................... 12

2.4 TECHNICAL OPTIONS FOR DATA EXCHANGE .............................................................................................. 16 2.4.1 Syntax and standards for data exchange......................................................................................... 16 2.4.2 2.4.3 2.4.4 Operational security of the connection ........................................................................................... 18 Central node.................................................................................................................................... 20 Data replication: content options.................................................................................................... 22

2.5 RESULTS SERVER ...................................................................................................................................... 25 2.5.1 Implications for access control ....................................................................................................... 25 2.6 COMPONENT INTEGRATION ....................................................................................................................... 26 2.6.1 Back-end components...................................................................................................................... 28 2.6.2 2.6.3 3 Front-end components..................................................................................................................... 28 Cooperating applications as an alternative to front-end components CCOW ............................ 29

CONTENT-RELATED STRUCTURE .................................................................................................... 30 3.1 DATA ORGANIZATION ............................................................................................................................... 30 3.1.1 Patient number ................................................................................................................................ 30 3.1.2 3.1.3 Codings ........................................................................................................................................... 32 Structuring....................................................................................................................................... 34

3.2 FUNCTIONALITY ....................................................................................................................................... 34 3.2.1 Appointments management.............................................................................................................. 34 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 4 Results management........................................................................................................................ 36 Request and registration system...................................................................................................... 36 Medication prescription and administration................................................................................... 38 Patient movements........................................................................................................................... 38 Invoicing.......................................................................................................................................... 39 Problem list and progress notes ...................................................................................................... 39

AVAILABILITY OF THE COMPUTER SYSTEM............................................................................... 40 4.1 CAUSES OF UNAVAILABILITY .................................................................................................................... 40 4.2 TECHNIQUES TO LIMIT UNAVAILABILITY .................................................................................................. 41 4.2.1 Backup............................................................................................................................................. 41 4.2.2 4.2.3 4.2.4 Hardware redundancy..................................................................................................................... 43 Maintenance contacts...................................................................................................................... 44 Cluster ............................................................................................................................................. 44

4.2.5 4.2.6

Replication server ........................................................................................................................... 45 Equipping of computer rooms ......................................................................................................... 46

4.2.7 UPS, emergency power for infrastructure outside the computer rooms ......................................... 46 4.3 REDUNDANCY CRITERIA FOR A HOSPITAL ................................................................................................. 46 5 ARCHIVING .............................................................................................................................................. 48 5.1 PHYSICAL PROBLEMS ................................................................................................................................ 48 5.2 LOGICAL PROBLEMS ................................................................................................................................. 48 6 SECURITY ................................................................................................................................................. 50 6.1 ACCESS CONTROL ..................................................................................................................................... 50 6.2 AUTHENTICATION ..................................................................................................................................... 50 6.2.1 Basic techniques.............................................................................................................................. 50 6.2.2 6.2.3 Discipline in authentication ............................................................................................................ 51 What authentication techniques should be used for an HIS? .......................................................... 54

6.2.4 Individual names ............................................................................................................................. 55 6.3 AUTHORIZATION ....................................................................................................................................... 55 6.4 MANAGEMENT OF USERS .......................................................................................................................... 56 6.5 AUTOMATIC BLOCKING OF A SESSION IN THE CASE OF INACTIVITY ........................................................... 57 6.6 AUDITING ................................................................................................................................................. 57 6.7 ENCRYPTION AND DIGITAL SIGNATURE..................................................................................................... 58 6.7.1 Symmetric encryption algorithms.................................................................................................... 58 6.7.2 6.7.3 6.7.4 Public-private key algorithms ......................................................................................................... 59 Certificates ...................................................................................................................................... 59 Hashing techniques ......................................................................................................................... 60

6.8 VIRUSES, WORMS AND TROJANS ............................................................................................................... 60 6.9 PHYSICAL ACCESS TO COMPUTER SYSTEMS .............................................................................................. 61 6.10 6.11 6.12 6.13 6.14 THEFT OF LAPTOPS ............................................................................................................................... 61 ACCESS FOR HARDWARE SUPPORT........................................................................................................ 61 INTERNET ACCESS ................................................................................................................................ 62 VIRTUAL PRIVATE NETWORKS .............................................................................................................. 63 ACCESS CONTROL AT APPLICATION LEVEL ........................................................................................... 63 Authentication............................................................................................................................. 63 Authorization .............................................................................................................................. 63 Audit............................................................................................................................................ 66

6.14.1 6.14.2 6.14.3 7 8

KEY ISSUES IN PROJECT MANAGEMENT....................................................................................... 69 PACS PICTURE ARCHIVING AND COMMUNICATION SYSTEMS........................................ 72 8.1 INDIVIDUAL ASPECTS OF A PACS ............................................................................................................. 72 8.1.1 8.1.2 8.1.3 8.1.4 8.1.5 Archiving of images......................................................................................................................... 72 Distribution of radiological images throughout the hospital network ............................................ 77 Connecting the imaging devices...................................................................................................... 77 Viewing for primary diagnosis ........................................................................................................ 79 Viewing throughout the clinic ......................................................................................................... 82

8.2 INTEGRATION OF PACS INTO THE WHOLE IT SOLUTION ........................................................................... 83 8.2.1 Back-office integration of PACS into the overarching information system .................................. 83

ii

8.2.2 8.2.3 8.2.4 9

Front-office integration of PACS in an overarching user interface ............................................. 86 Information exchange with the imaging devices ............................................................................. 89 Correction of errors in the PACS.................................................................................................... 91

TELEMATICS ........................................................................................................................................... 93 9.1 SECURITY IN TELEMATICS ......................................................................................................................... 93 9.1.1 Defining responsibilities ................................................................................................................. 93 9.1.2 9.1.3 9.1.4 Securing of communications ........................................................................................................... 94 Authentication of users.................................................................................................................... 94 Confinement of business logic to the client software....................................................................... 95

9.1.5 Detailed access rules and external doctors..................................................................................... 96 9.2 TECHNOLOGY FOR TELE-INTERACTION BETWEEN PERSONS ...................................................................... 96 9.2.1 9.2.2 Video conferencingLevel of expectations ........................................................................................ 97 Data conferencing ........................................................................................................................... 98

9.2.3 Delayed time interaction by exchanging files............................................................................... 99 9.3 TELELINKING OF AND TELELINKING TO MEDICAL FILES .......................................................................... 100 9.3.1 9.3.2 9.3.3 Exchange of information between independent medical files........................................................ 101 Interactive tele-access to the file within a hospital ....................................................................... 103 The sharing of a central file between independent care providers................................................ 106

iii

1 Introduction
The aim of this text is to make a number of recommendations and to provide an initial stimulus for the establishment of quality criteria for hospital information systems (HIS). A hospital information system is a very complex system, in which every aspect of IT is involved. It is impossible to discuss all these aspects in one text: we shall therefore confine ourselves to certain part-aspects that, in our opinion, are to a greater or lesser extent specific to the hospital sector. Strictly speaking there is no such thing as medical informatics; there is only the application of IT within the medical sector. Some IT techniques arise more frequently in this sector than they do in others, and some problems (e.g. image storage and distribution) receive a different emphasis than they do in most business applications. Many hospitals have a management structure that is fundamentally different from those encountered in most businesses: although the various medical departments work closely together, they enjoy considerable autonomy. Often each department of a hospital can pursue its own IT strategy, whereas in the business world this strategy is usually determined centrally. This has an impact on the problems that arise and on their potential solutions. In this text we have tried to identify some key issues and to propose a generic approach that makes due allowance for this specific situation. We shall be confining ourselves to those technical and architectural decisions that cannot be made purely and simply by technical experts but in which the management also have to be involved because the decisions have an impact on the functioning of the hospital, the (electronic) interactions between departments, the security strategy, the access control, the extensibility of the system and other factors. In addition, we are focusing primarily on the problems and choices that have to be made in the implementation and integration of the clinical systems. These are heavily influenced by the fact that they require a very strict authentication, while it is precisely these applications that are most subject to unusually complex access control and access control measures. For administrative systems, the situation is not only simpler but also less specific, so that more expertise will be found within the internal management and among any external staff who handle the implementation. We do not wish to define any minimum standards for the contents of the medical file. For that we refer the reader to the Royal Decree of 1999 May 1999. which lays down such minima. It is not up to the authors of this text to define priorities for the further development of the medical file. What is optimally and pragmatically feasible for one hospital is very difficult to implement for another. We do make reference, however, to 4

integrations that in our opinion, are desirable or even indispensable if a decision is made to develop or purchase specific modules. The text tries to distinguish between measures that are strictly required and those that are merely desirable or recommendable. We have decided not to produce a list of strict standards. A list of standards could, of course, lead to a strict scoring of hospital information systems, but it struck us as being well nigh impossible to produce a single meaningful relative scoring system for technical, substantive, integrational, safety-related and managerial aspects of an HIS without first having exhaustively listed and described all the criteria. As the latter struck us as impossible, we have confined ourselves to a qualitative description. The text is not, therefore, an exhaustive treatment of all the possible choices that must be made when implementing an HIS. It is more a collection of best practices and some practical suggestions for the solution of problems. The aim is to impart some structure to frequently arising problems and thus help the management in the drawing up of the IT master plan and the implementation of the HIS. Recommendations printed in this style are both extremely important and strictly necessary. Recommendations in this style are less important and can be regarded as secondary.

2 Architecture and integration of the HIS

2.1 Introduction
The architecture of the HIS partly determines the possibilities and limitations of that system. Various aspects of an HIS are affected by the architecture:

Access control Migration of applications and systems Application integration and workflow monitoring Data storage etc.

The architecture is not determined purely by technical factors but also by how the system has grown historically and (above all) by the structure and level of integration of the management. To build an integrated IT system requires an unequivocal vision of this architecture and unequivocal leadership to then implement this vision. In many hospitals however, (medical) policy is decentralized. There is usually, it is true, a central policy for the administrative and logistical support, but the medical policy is run by the various departments (specialisms) in a fully decentralized manner. As a result we often see an integrated patient management system and an integrated invoicing system, but also differing medical subsystems across which the patients medical file is divided: the internist works with a different package to the surgeon, the neurologist has something different again, and so on. Services such as Pharmacy, Radiology or other function measurements generally use very sector-specific software. The system then grows through the acquisition or expansion of modules without a global architecture being thought out in advance. Integration has to be realized retrospectively and is, as a result, more costly and more difficult. Because the departments are also financially independent and have their own budgets, you still have to negotiate with the different departments to convince them to release the necessary budgets for integration. The fact that the management structures have developed the way they have is of course to do with the way in which the government finances the hospitals. This is now unfortunately a reality, and when delineating the architecture of the HIS we have to take this into account: it makes no sense to propose a level of integration that demands management decisions that

cannot be taken because there is no management structure with the authority to take them. In other words, the level of integration of the IT system is restricted by the level of integration of the management. If allowance is made for this factor when delineating the global IT master plan, you should also be able to adjust the expectations of the users. By informing the departments about the consequences of their choice of one or other subsystem, you can still if necessary keep a number of integration options open. Even if you are working with different subsystems there will still be a number of integration options available to you. First we describe a number of basic architectures and their respective pros and cons. We then describe a number of possible integration and connection techniques. In the IT master plan, a high-level architecture must be chosen in which the integration of the various subsystems is described. The plan describes the information flows and the integration techniques at a high level. If the choices made exclude specific options then these must be stated.

2.2 Definitions
We shall first discuss a number of conceptually basic architectures and introduce a few terms to facilitate further discussion. The classification that we offer is certainly not absolute: there are different types of architectures, but between them lies a continuum. An HIS will usually be a combination of these types. Nor are the names of these types standardized: the terminology encountered in other texts may therefore be different.

2.2.1

Connected systems

A connected system consists of separate subsystems that are linked together by data connections. In this way data is transported from one system to another. This can be done in 2 ways: by on-line retrieval or by data replication. In an on-line retrieval system, A will retrieve the data it needs from system B as and when it needs it. The data will only be processed at A it will not be stored there. If A needs the same data again later then A will retrieve it again. A therefore acts as a client and B as the server.

In data replication, A will retrieve data from B at regular intervals and then store it locally. Alternatively, B can send its data to A either regularly or continuously. Bs data is therefore stored redundantly on A. Data replication has the advantage of efficiency: the data is locally available on the second system, which makes interrogation much faster. On the other hand, there is a need for copy management (see p. 22). If different subsystems re-implement the same functionality we refer to it as function replication. To take an example: suppose that the Internal Medicine and Surgery departments have different IT systems. At both departments a Radiology request module has been implemented at the request of the Radiology department. This is an example of function replication. It means that the logic behind the request module must be created in two different systems. Function replication is expensive and is rarely performed, but sometimes it is necessary. Sometimes also it is not enough just to replicate the data to another system you also have to add programs to make it possible to view and/or manipulate this data. Given that different systems are being connected, a distinction can also be made here between ad hoc connections and connections via a central node. Ad hoc connections do not need much defining: in this case, two subsystems are being connected to each other. If a central node is being used, then all the subsystems are connected to this node. The node also usually controls the traffic between the subsystems and acts as a sort of triage station.
Radiology Internal

Dermato

Surgery

Data connection Ad hoc protocol, HL/7 connection or other. Pharma

Illustration 1:Ad hoc connected systems

2.2.2

Integrated systems

In an integrated system, the user sees just one system of subapplications interacting with one another. The degree and complexity of this interaction can vary substantially. An integrated system can be either monolithic or component-oriented. In a monolithic system, one manufacturer makes everything and the degree of integration is usually very high. The subapplications have seamless interfaces and the user has the feeling of working with one big application. The main disadvantage is that there is rarely one manufacturer who is in a position to provide a satisfactory solution for all the subsystems. A further drawback is vendor lock-in: the hospital is heavily dependent on that manufacturer and the applications that this manufacturer supports. In a component-oriented system, different manufacturers make the various subapplications but interact with one another by using each others functions. The user will, however, usually note differences in style between the subapplications because they all have a different origin. The system does, however, behave as a single unit.

Illustration 2 : Connecting via central node

Radiology

Internal

Interface engine (HL/7) or Message broker

Dermato

Surgery

Pharma

Difference between function replication and component orientation The difference is that in a component-oriented system one component implements the function but the function is used in different subsystems. The consistent implementation of the function throughout the whole system is guaranteed. The program code that implements the function logic only exists at one location; if it has to be adapted then this also only needs to be performed at one location. In function replication, the function logic will be re-implemented each time in the target package. There are accordingly different implementations of the same function logic and usually in different technologies also. This is expensive both to develop and maintain. Each application must also be implemented by all the different parties. There is a risk that not all the subsystems will implement the logic in exactly the same way. Back-end and front-end components Component integration can be performed at both the front end and the back end. Front-end components are separate components from which an application has been made at the front end (client) and which may also have their own back-end system. So, for example, you could have a component for the presentation of radiological exams and radiological reports, which retrieves this data from its own radiology database but which is still built in as a whole component into the user interface of the application that presents the medical file as a whole.

10

Application du dossier mdical Admission Sortie Transfert de patients

ID pat.

Info ID Systme RX Planificateur de rendezvous

Serveur de rendez-vous

BD admin. patients

Systme RX

Illustration 3: Front end components Back-end components are usually implemented in a middle tier in a so-called 3-tier architecture. The third tier usually takes care of the persistence of the data. This architecture is very often used in Internet applications, where you do not have (or wish to have) any control over the front-end systems and you therefore implement all the business logic in a middle tier. The middle tier provides services to various front-end applications. The great advantage of this is that the business logic only needs to be maintained at one location. You can also change it without having to make adjustments to the client applications as long as you do not change the interface to the clients. For access via the Internet, for example, another front-end can be built that is different to the one that is used within the healthcare institution in question (see p.105). The above terms represent a number of different types. Within each of these types there are different variants.

11

Application 1

Wireless Application

Application 2

Implemented on "application servers" type J2EE, .NET or servlets. Several middle-tier servers possible. Middle tier RX request RX reporting Appointments Middle tier Patient admin Medication prescription

RX system

Patient admin

Pharma

Illustration 4: Back-end components

2.3 Splitting of the HIS: content options

The management must make a number of integration choices in its IT master plan. As stated above, the architecture of the system helps to determine what it will be easy or difficult to realize with the system. The management must therefore make due allowance for the limitations of the architecture of the HIS while seeking to adapt the architecture to the objectives that it wishes to achieve. Unless a monolithic system from one manufacturer is chosen, the management will always have to decide how the system is going to be split into manageable parts that will serve as the building-blocks of the HIS. This choice is best included in the IT master plan, along with the approach adopted for connecting these building-blocks with each other and with the systems already implemented in accordance with one of the techniques mentioned above. The different parts of the HIS can then be purchased or developed independently of one another.

12

How the system should be functionally divided is a separate issue from the technical choices that you make when integrating the different components. We shall now discuss a number of basic choices that can be made in the splitting of the system and shall then examine some integration techniques.

2.3.1

Splitting by user group

The system can be split by group of users. In other words, each group has its own file. We sometimes refer to a medical file and a nursing file. The former is used by the doctors, the latter by the nursing staff. Sometimes a third file is added: the social file.
General Internal Medical file Cardiology Abdominal surgery Dermatology Anaesthesiology

Nursing file S`

Administrative system

Illustration 5 : Splitting by group

Advantages The main advantage of this approach is that it is usually possible to roll out just one nursing file throughout the hospital, while it is more difficult to achieve consensus about one medical file (package) because of the major technical differences between the specializations. As a result, it is sometimes easier to set to work on the computerization of the nursing side first. Disadvantages It is, however, a very great disadvantage to accommodate the nurses and the doctors in two or more different systems that must then be integrated with each other. As information has

13

to be transferred in large volumes and with a high frequency between nurses and doctors, a large number of (data) connections between the two systems is required. As this is quite expensive it only happens to a limited extent and there is therefore a loss of functionality. Without heavy integration or connection efforts, it is difficult to implement workflow in such a system. If you opt for a split by user group, the connection between the medical and nursing systems will have to be very efficient because most workflows exceed the limit of these systems from time to time. In such cases it is best to perform the integration at database level, with one system directly interrogating the database of the other (client server) or to opt for an expanded data replication with redundant storage of the data required in the workflow(s).

2.3.2

Splitting by department

Some prefer to set up a patient file by specialism (group). Nurses and doctors from the same department work in one system but have different packages for each specialism: Internal Medicine, Gynaecology, Surgery and so on.
General Internal File Package A Cardiology Abdominal surgery File Package B Dermatology File Package C Anaesthesiology Anaesthesia/ pre-op monitoring

Administrative system

Illustration 6 : Splitting per specialism

Advantages Specificity. One advantage of this approach is that a very specific system can be chosen for each department. For the more technical departments in particular, a generalized system 14

can be insufficient. In practice, however, a split of this kind is usually made not for this reason, but because each department has a fully autonomous management and selects a system without consultation. Manageability. You have the advantage of manageability, which is especially useful if you do not wish to integrate too tightly. Each of the systems can be adapted or migrated individually without disrupting the others too much. Disadvantages Fragmentation. In an approach of this kind, the patients medical file is stored in a

fragmented way. Usually the service providers of one department do not have access to the package of the other department. Expensive integration. The integration is expensive and, if the systems are strongly

integrated, some of the advantages mentioned above are lost. If, for example, you want to implement order entry then function replication will very soon be required.
General Internal File Package A Cardiology Abdominal surgery File Package B Dermatology File Package C Anaesthesiology Anaesthesia/ pre-op monitoring

Nursing file

Administrative system

Illustration 7 : Combination of splitting by group and by specialism

Several user interfaces. If people are working in different departments they are confronted with different user interfaces. This can be a problem not just for interns undergoing training at a training hospital but also for nurses who are on rotation. Most HIS are combinations of the above splits (see Illustration 7). 15

2.4 Technical options for data exchange

When designing/planning data exchange between different systems, the following points must be defined for each of the connections:

Syntax for data exchange The measures taken to guarantee the operational reliability and correct functioning of the connection - Does data replication resume after the downtime of one of the systems? - Transaction monitoring

Performance requirements

2.4.1 HL/7

Syntax and standards for data exchange

A great many standards have been defined for data exchange in medical informatics, but few are actually being followed by manufacturers on a large scale. One of the few that has a worldwide commercial following is HL/7 (Health Level 7). Even with HL/7, plug-andplay has still only been tackled as far as the level of plug-and-pray. There are also both minor and major dialect differences that mean that setting up an HL/7 connection can rapidly demand several man-weeks. For the exchange of diagnostic images and related information the DICOM standard is generally accepted (see p. 77). There is a difference between a syntax (and a protocol) for communications and a standard. The syntax defines the manner in which data in the message must be coded, the protocol is the technique for getting the data to the communications partner, while the standard defines the meaning. The HL/7 standard is extensible, i.e. the message can be supplemented with user segments in which data can be placed that is not (yet) included in the standard. In fact, in that case HL/7 is used purely as a technique for communicating data regarding which you still have to conclude separate agreements (which is, of course, an advantage if such a technique is already needed).

16

XML A promising new syntax is XML and a related communication protocol is SOAP. These will become more important, but they are not currently replacing any of the standards. Just because two systems support XML does not mean that they can exchange messages with one another (and process them). XML defines only the syntax of the message but does not as yet define the structure and the meaning of the elements in this structure. XML is generally supported by the whole computer industry. XML will therefore also become the syntax above which the standards will be implemented. Later versions of HL/7 will be XML-based. The significance and structure of the message and the items it contains are determined by the HL/7 consortium. When two or more systems are linked, you must consider whether using a standard format is worth the trouble. All too often, people automatically assume that a standard must be used. Sometimes, however, there are reasons for taking a more direct route and creating an ad hoc link (which can then still be based on XML), certainly if only purely private elements are still being used in HL/7. Performance If a standard such as HL/7 is used then the data that you want to send must first be fully converted to HL/7 format. The data is then forwarded via the network to the receiving system or the central node (see below). The receiving system must then unpack the data and convert it to the local format. All this creates overhead, which is not always acceptable in a transactional system. If the structure of the information that you want to transfer is relatively simple, is familiar, and will change little over time, then it can often be much simpler to set up an ad hoc format and data replication procedure, which is much closer to the source and target system. For example, if a source and target system both use a relational database for data storage then you can usually replicate data between databases more efficiently by getting a program to retrieve the necessary data directly from one system and inserting it into the other. The procedure for the latter is best left to the manufacturer of the receiving system. You must check in advance whether the standard that you wish to use involves excessive overhead, as a result of which the performance requirements cannot be achieved.

17

2.4.2

Operational security of the connection

For each connection that you create between two systems, you must make allowance for the fact that both the sender and the recipient and the process that handles the data replication can temporarily drop out, and that it must be possible to restart the data replication again after rectifying the defect.

2.4.2.1

INDEPENDENCE OF SENDER, RECIPIENT AND TRANSFER PROCESS

The connection must be set up in such a way that the sender, recipient or transfer process can fail without the other two being prevented from functioning. This is precisely one of the advantages of splitting systems: defects and downtime remain restricted to just one part. This splitting can be achieved by, among other methods, buffering messages on both sides. The sender writes the data to be transferred into a local buffer. The transfer process retrieves the data from this buffer and then sends it to the buffer of the recipient. The recipient reads the data out of this buffer to process it. If the recipient is not operational then the sender can still continue working and adding data to the buffer. If the processing is only down at the recipients end then the transfer process can send the already transferred data to the recipients buffer. If the recipient is completely unavailable then the data to be sent remains buffered at the sender. The buffers must be sufficiently large to store the data that accumulates during downtime.

2.4.2.2

GUARANTEED DELIVERY

The connection must guarantee the delivery of each message. If the medical file is spread over different systems, the non-delivery of a message can cause important medical information to be lost. Usually a message will only be deleted from the send buffer or be checked off as having been sent after confirmation of receipt. Idempotent operations Often the sender is uncertain, after the recipient has gone down, whether his last message did in fact arrive but no confirmation of receipt was sent in return or whether the message never arrived at all. After everything is operational again the sender can see which was the last message to arrive, but this makes interaction between sender and recipient rather complex. 18

A simpler way is to work with idempotent operations. These are operations that can be performed several times one after the other but which cease to be effective after the first time. That means that whether you perform an idempotent operation just once or several times in succession you get exactly the same result. If, in data communications, you can make sure that each message can be sent in duplicate or even several times then when you restart you will start sending all those messages for which no confirmation of receipt has been obtained. In this way the recipient can receive the same message several times, but without this having any effect. The recipient accordingly does not need to check what the recipient has already processed, which keeps the connection simple. Most commercial messaging engines have built-in mechanisms for guaranteed delivery (see below).

2.4.2.3

RESTART PROCEDURE

For each connection a restart procedure must be worked out and described that prevents any messages from getting lost. The systems must be dimensioned in such a way that they can clear the backlog at sufficient speed. In addition to the measures necessary to counteract the loss of messages, you must also ensure that the systems that handle the data replication have been sufficiently dimensioned. If, for example, the system has been down for 4 hours due to a breakdown you must be able to rapidly clear the messages that have stacked up during those 4 hours. As long as the system is still processing old messages that were generated during the breakdown, the new messages cannot be sent and the recipient remains behind the sender. For the recipient the effective downtime = the period of the breakdown + the time required to clear the backlog.

2.4.2.4

TRANSACTIONS

Implementing transactions across messaging systems is very complex. You can set up simple data replication yourself, but in order to have transactions working on top of a messaging system it is best to use specialized software. During the transaction, locks remain open on the database, which in their turn block other (local or distributed) transactions. If the transactions are being processed with insufficient speed this causes a vicious circle that brings the systems to a standstill. The slower the transactions, the faster this phenomenon arises. Transactions via messages are usually much slower than transactions between databases, which in their turn are slower than transactions within a database.

19

Before you set up an architecture in which distributed transactions are required, you must make sure that these transactions can be handled with a speed that is sufficient not to jeopardize the operational functioning of the participating systems.

2.4.3

Central node

If you have to create a lot of connections between different systems, you can opt to route all the connections via a central node (see Illustration 2 p. 9). Each of the systems is connected to the node. Advantages

The number of connections that has to be maintained falls drastically. The node can also perform routing: a sender needs to send the message only once to the node, which can deliver the message to more than one place. In some commercial products it is possible to specify quite complex routing rules.

Single point of management: via the node you can monitor all the connections. Protocol conversion: the sender sends the message to the node in a particular protocol. The node can convert the message to another protocol before sending it to a recipient.

Maintainability: one system to set up buffers, one system of guaranteed delivery, and so on.

Disadvantages

Single point of failure: when the node is down, all the connections fail. On each occasion, two connections are required to link systems: from sender to node and from node to recipient. As a result the transmission time increases still further (see also page 17). For on-line queries this way of working is often too slow.

Cost. If you want just a few connections this is usually not worth the trouble: you need a separate machine and a software licence (if you are using a commercial product), you have to learn how to use the package, maintain it, etc.

20

2.4.3.1

INTERFACE ENGINE

People in the medical world have been using so-called HL/7 interface engines for a long time. An HL/7 interface engine is a central node for HL/7 messages. Usually this software is installed on a separate server. All the systems send their HL/7 messages to the interface engine. The interface engine buffers them and ensures that they are delivered. Some interface engines allow the implementation of (limited) business logic. This is used primarily for routing and filtering. By using rules you can specify which messages must be sent to which recipients. Usually you can still make changes to a message before forwarding it to a recipient. So, for example, you can define filters. Suppose that a medical system is sending data to another medical system and that an administrative system has to be informed of the fact that an exam has been performed but not of the actual result. In that case you can define a setting on the interface engine that will specify that the other medical system will receive the complete message but that the administrative system will only receive a filtered copy (i.e. without the result) of the original message. Many interface engines can also handle other protocols and can convert HL/7 messages from one version to another.

2.4.3.2

MESSAGE BROKER

You can also opt for a general message broker. The market for EAI (enterprise application integration) has produced several general integration products. The difference with the HL/7 interface engines is that these do not directly support the HL/7 protocol but only more general application-aspecific protocols. These products have the advantage that they can also be used for the integration of nonmedical applications where HL/7 is unknown. As they cover a larger market they are generally more sophisticated too, but they are also usually more expensive. As a central node is an especially important and vulnerable component of the architecture, the following options must be specified in the IT plan:

Securing of the node: who has access, who defines the routing rules, etc? Performance requirements: routing time of messages, recovery time required to process messages after restart, etc.

Operational security: which mechanisms handle guaranteed delivery, uptime (is deduplication of the server necessary?), will idempotent operations be used or not?

21

2.4.4

Data replication: content options

Separate from the abovementioned technical options there are content-related decisions that have to be made and that are solely concerned with the fact that you want to replicate data (separately from any technical option). If the various systems that receive replicated data are under separate management and pursue their own policy, then a number of agreements have to be made with regard to copy management. Who manages the copies of the replicated data? If department A forwards data to department B:

Who is then responsible for the access control to the replicated data? Who is responsible for the correct presentation and visualization of the data? Is department B allowed to change the data? Is department B allowed to apply interpretation rules to As data (outside the control of A)? We are not referring here to crude changes to basic data but with their interpretation from a programming perspective, whether or not through combination with data of your own.

Is B permitted to forward the data in its turn to C?

Presentation and visualization In data replication, the data is sent to another database, but this still does not guarantee that it will be presented there correctly. For example, you may forward lab results to a system that then presents these to its users without normal values or with superseded normal values. As the head of the laboratory is responsible for the reporting, this person must check whether the data is being correctly presented on the other system. Some data is propagated as raw data and cannot be visualized without further processing. Examples are ECG traces, radiological images or the results of image processing. For results of this kind you always need specialized viewers. The department that produced the data must check whether the recipient department can visualize the data. With complex data, consideration can be given to the question of whether, instead of function replication (see page 85), the producing department would not be better advised to make available a visualization component that can be built in by the recipient department.

22

2.4.4.1

MASTER- SLAVE

It is best to create a master-slave relationship between the sender and the recipient. All changes in the propagated data are made via and by the master, which propagates the changed data to all the slaves. Master-slave relationship in this context means that only the sender has the right to add, change or delete data of that type. The recipient may only read the data. If the recipient is an autonomously managed system then this will have to be made mandatory through procedural agreements: changing the data. For most data types it is a simple matter to define a so-called authentic source, which then acts as the master. Even so, you may sometimes want to amend data from a system that you are not the master of. If this has to be done then the best way of doing it is to have the master define a function via which the other systems can amend data on the master. The amended data is then propagated again from the master to all the slave systems. This has the following advantages:

technically, there is no way of preventing the recipient from

the master contains the necessary business logic to check whether the change is permitted and to keep the data internally consistent;

all the other applications (slaves) also have the changed data sent to them; the system that requested the change does not need to know which other systems have to be informed of this or how;

there are no inconsistencies between the copies on the different systems.

2.4.4.2

ROUTING RULES

Even if the different subsystems are managed decentrally it is best if the routing rules and filters are centrally managed on the central node. Administrator access and passwords for the central node must be protected with special care, as all (medical) information passes via this server.

23

2.4.4.3

SYNCHRONIZING OF DIFFERENT DATA COPIES

If, after the data on the master has been sent, changes still have to be made to it, then synchronization procedures and messages must also be defined. A potential problem in this context is that if a large part of the content of the message changes then it is not always clear whether it is a new message or simply an old message that has been changed. Each message must have a unique identifier to which reference can be made when passing on any subsequent changes.

2.4.4.4

IMPLICATIONS OF DATA REPLICATION ON ACCESS CONTROL

Whether you use a central node or work with direct connections, different copies of medical results will end up on different servers. This increases the risk of unauthorized access and makes control more difficult. We can mention the following key issues: Uniformity of the access control rules Are the same access control rules respected in all systems? It does not make any sense to be very strict in one system but then to allow people to access the data just by logging on to another system. Uniformity in the allocation of access rights The access control rules can be implemented simultaneously in two systems, but there could be a difference in the allocation of the privileges in the two systems. Suppose that in the two systems only administrators have certain access rights, but that in one of the two systems it is possible to very rapidly obtain the rank of administrator that system is therefore a security risk. Uniformity in the follow-up In all systems there will be some form of follow-up (audit) of the accesses made. It is best to do this in the same way if technically possible for all copies. If medical data on different servers is copied, the access control across these different systems must be made as uniform as possible as regards rules, allocation of privileges and audit.

24

2.5 Results server

A results server is, in a certain sense, a special case of the architecture with a central node. All the systems connect with the results server but only results are passed on, and the results server stores them instead of forwarding them. The other systems ask for the data on-line as and when they need it. Just as with the node you need fewer connections, but in this case instead of managing the message stream centrally you manage the results yourself centrally. Advantages

Much less redundancy. The results are only present at two places: in the producing system and in the results server. That also means that you need less storage space from a global perspective.

Access control to the replicated data is more manageable because it can be centralized (see below).

Disadvantages

Performance. The replicated data is no longer updated locally in the various systems and must now be retrieved on-line from the results server. This is slower.

Single point of failure.

If you have a results server then you had best avoid a situation where subsystems store the data redundantly again on this server.

2.5.1

Implications for access control

Centralized access control As all the results end up in one results server, you only need to define the access control rules at one location to achieve a uniform implementation. In order to implement more refined access controls you will, however, need more information than just the results. You may, for example, need the location where the patient is hospitalized, the department where he or she has been registered, the appointments, etc. in order to evaluate whether access to the file is to be permitted or not. This means that this data along with the results themselves must be replicated to the results server. In addition, all the users must be 25

individually known in the results server, as also must the group to which they belong or the roles that they can assume. This is, of course, technically possible but is not always feasible because its implementation is labour-intensive. Decentralized access control The other extreme is to implement the access control rules on the querying systems and to allow these to retrieve data from the results server without the results server performing an additional check. The other systems are then fully trusted by the results server. Sometimes the querying systems are allowed to query the data on the results server but with only one log-in name each. In that case the results server can only maintain a limited log of what has been queried: you only know what data has been sent to which application server, and not to which user it has ultimately gone. If you opt for the latter arrangement, it is of the greatest importance that the log-in name/password combination with which the application servers go to the results server is well protected. As the results server does not perform any further checks, the divulgence of this log-in name/password combination is a major security risk. Usually the access control on a results server will be defined partially centrally and partially decentrally. As far as possible, define the access control rules centrally. We suggest working with unique log-ins on the results server and, where an application server retrieves results with a group log-in, to determine what security measures this server must implement in the area of authentication, authorization and logging. Combination of results server and central node For order entry a results server is not a solution: the requests must ultimately flow into the application server of the department that has to execute the request. For this reason it can be useful to combine the central node with a results server. The results server can then receive the results either directly or via the node. Results can also be queried via the node or directly in client-server mode. The latter is, of course, faster.

2.6 Component integration

Component integration is the most modern method of integration and also offers the most possibilities, but it is also technologically the most difficult. It is only really possible with the 26

more modern technological resources. Older applications will not easily lend themselves to integration or be easily integrated as a component. Here we discuss only the technical options that have to be chosen by the management. Standardization on one technology If you move over to a component-oriented system then you should try as far as possible to standardize on the basis of one component technology. There are bridges between component technologies, but these make integration more difficult and usually this results in a loss of functionality and performance. It looks as if the market is going to be dominated by two technologies: .NET from Microsoft, and Java, which is supported by a number of suppliers both large and small. It is obviously not always possible to avoid using another technology, but you must (1) define one technology as the preferred one from the organizations perspective and (2) in exceptional cases, decide on a case-by-case basis whether the advantages of the alien component outweigh the additional cost involved in building bridges and maintaining the knowledge of the other technology required for this particular case. Whether you opt for front-end or back-end component integration, it is best to stipulate in the IT master plan the technologies that the hospital wants and can support so that these can serve as guidelines for all component suppliers. You must also determine what basic interfaces the components must be able to satisfy if they are to be built in successfully. You must also stipulate in advance which functions the subcomponents must delegate to the overarching front-end application in which the components are integrated or to the back-end framework. It is best to allow the subcomponents to deal only with the specific functionality and internal access control. The following functions are best housed in the overarching application or within the structures of the framework:

Authentication, so that this is uniform (where appropriate via LDAP). Access to the component itself: only authorized users should get to see the component. Access to the various functions within the component must, of course, be implemented by this component itself.

Logging of use.

Components are usually smaller than subsystems. You are therefore getting a system to which many different manufacturers will have contributed building-blocks. Each of these components has its own migration path but, above all, its own migration speed. A problem arises if you want to upgrade the component framework to a subsequent version. At that moment all the components that are used within that framework must be able to work with 27

this version. This cannot be taken for granted, as manufacturers are sometimes not inclined to upgrade old systems. Others, on the other hand, sometimes do not want to support old versions of the framework. In this way you can get into a blind alley in which some components require at least a certain version of the framework and others can no longer run on it. This can block the evolution of the system. When purchasing components you must contractually ensure that the manufacturer will continue with the versions of the component framework.

2.6.1

Back-end components

Components that have to interact with one another a great deal are best implemented on the same type of framework. There are bridges between the different component frameworks, but using them usually involves a loss in performance. Implementing transactions across components in two or more different frameworks is also no easy matter. Delegate as many as possible of the user administration and access control rules to the functions provided for these in the framework itself. This makes a uniform application of the rules simpler and thus enables you to obtain (within that framework) a centralization of them that facilitates maintenance and control.

2.6.2

Front-end components

If you create an application for the medical file with the help of front-end components then the overarching application in which the components are integrated plays an important role. The above remarks remain applicable. The more functions the components share with each other, the less function replication is required and the more consistent is the interface and the use. In the case of front-end components, you had best also define the visual integration (look and feel, integration in one window or one window per component, etc.). Allow components to share as many functions with each other as possible (especially basic functions such as patient and user identification, looking up patients, users, materials, etc.).

28

2.6.3

Cooperating applications as an alternative to front-end components CCOW

By synchronizing and coordinating applications so that they automatically follow the users context, the CCOW Standard serves as the basis for ensuring secure and consistent access to patient information from heterogeneous sources. The benefits include applications that are easier to use, increased utilization of electronically available information, and an increase in patient safety.1 CCOW is not a component framework, but rather a technology with which you can synchronize different applications that are open simultaneously. CCOW uses the concepts of patient and episode and will, if the user selects a patient and a certain episode in one application, also inform the other open applications about them so that they can select the same patient and episode. CCOW is now managed by the HL/7 consortium. This is expanding CCOW even further so that the applications can be synchronized with one another even more. CCOW supplies synchronization but not integration.

From Overview of HL7s CCOW Standard by Robert Seliger, Co-Chair, CCOW Technical

Committee, www.hl7.org 29

3 Content-related structure
In this chapter we primarily discuss key issues relating to the manner in which the content of the medical file is structured. This covers, in particular, the degree and manner of coding and structuring. As regards the functionality, no judgment is made on which functions must or must not be present. Which functions you want to automate (and which not) do not provide any indications about what makes a better medical file. In a number of cases nonautomation is, after all, just as good an option. The functionality is only discussed insofar as recommendations are made about the way in which a certain functionality is automated.

3.1 Data organization

3.1.1 3.1.1.1 Patient number MANAGEMENT

The patient number is the central anchoring point the index for all patient-related information in the applications. Choose a meaningless patient number. The purpose of a patient number is that it remains constant over time. Anything that has any significance whatsoever with regard to the patient (date of birth, gender, etc.), the organization (serial number per year, year of first contact, etc.), external references (Social Information System card number, health insurer, etc.) and which is included in this number can change or be recorded incorrectly and thus give rise to the patient number having to be changed. This must be avoided as far as possible. All this information must be an attribute of the patient identification that is related to this meaningless number. If there is the slightest doubt as to whether some information relates to a patient file then a new patient number must be created. There must be a procedure for merging two patient numbers and related files which can reverse this deduplication after it has been proved that the same patient is involved. It is impossible to automatically unsplit wrongly merged patient files or information about different patients in the same file. Correcting these errors requires manual interventions by users who are familiar with the (medical) content. This is usually a time-consuming task that can only be performed by the attending physician. In addition it is better to have less

30

information by separating a file wrongly than to have incorrect information by retaining wrongly merged files for different patients. 3.1.1.2 UNIQUENESS OF THE PATIENT NUMBER

The decision as to whether or not you can use a unique patient number in the hospital is unnecessary if only one (central) application is available. Unique patient number throughout the entire hospital If there are several (linked) patient applications, you should opt for one application in which the basic file of the patient identifications is managed. This basic file is then copied to all the other patient applications. In the other patient applications no changes, additions, etc. to the copy data are permitted. See p. 15 for techniques for linking applications. In the application in which the patient identifications are managed it must be possible to enter all the patients. It is important that procedures are agreed for determining who can enter and change patient data in the central patient application and when. Make due allowance for exceptional situations such as weekends, nights, etc. when new patients have to be included in the system and the persons who normally perform this identification are unavailable. Make due allowance for situations in which the central patient application is down while the other applications that receive a copy of this data remain available. Each patient application therefore receives a copy of each patient record and can thus contain (usually only administrative) data of patients for whom no medical data is available in these applications. Allowance must be made for this in the authorization rules of this application. In some cases, even administrative data contains information that should not be available in this application. Several patient numbers across the entire hospital You can decide to generate the patient number and to have the corresponding patient data managed in each application separately. In this case the patient number is split on the basis of a splitting of the application itself (per department, function, etc., see p.12). The advantage of this is that you do not have any administrative patient data in applications that 31

also do not have other data about this patient. This makes any special authorization rules superfluous. Also, unavailability of the central application is not a problem. If a link has to be established between patient data right across the applications then a relationship must be established between the patient numbers of the various applications. Possible links that must be considered are those with the invoicing system, the results server, etc. Possible techniques for this relationship are the inclusion of a common attribute in the various applications, such as the SIS card number (what about patients without an SIS card?), combination of name, address, birth date (what about incorrect data or variants in spelling, etc.?)

3.1.2

Codings

Codings are pre-defined lists of concepts in which each concept contains an unambiguous and unique alphanumeric combination of signs to which one or more definitions are linked. There are internationally recognized and standardized codings but they can also be local lists
2.

Data that you want to process automatically must be coded. If you allow data to be entered in free text, then different names, spellings, typos, etc. will be used for the same concept, which the computer will not identify as the concept concerned. These errors, variants etc. are committed both by different users and by the same user over time Coding is therefore necessary even if there is only one user who thinks he is acting consistently 3. The calculation of numbers (statistical processing), the use of the system for warnings (interactions between medication and diagnoses, etc.), the calculation of derived values, etc. requires the computer to be able to use a code. Use a structured coding system for code lists that have a lot of codes.

The minimal example is a question that can have an affirmative or a negative answer. This

can be coded by "yes" and "no".

3

When using free text in the above mentionned example, one could obtain "yes", "y", "OK",

"+",... and "no", "n", "-",... as a result. 32

In a structured coding system the code consists of:

different axes that are separate from one another (e.g. SNOMED). Each axis has its own significance and is in its turn its own coding system that can be interpreted separately from the other parts of the code

or

a hierarchical structuring in which each level must be interpreted on the basis of the previous level (e.g. ICD-9).

If you do not have a structured code then you will have to create families of codes to be able to answer certain questions with the computer. This can be a very laborious task involving continuous maintenance and updating. There are various techniques for inputting the correct code. Each of these techniques has its application in a specific context:

hierarchical search systems in which the codes are presented per level and you scroll through the various sublists as if travelling along a path. When each level is chosen the sublist for the following level appears;

search systems based on the definition of codes (exact, phonetic, etc. searching); personalized and restricted lists of the most commonly used codes. Most users will, in the majority of cases to be coded, only use a restricted list of codes. If these can be presented separately, this speeds up the searching and you reach the complete lists by selecting the other option;

natural language identification systems in which the user enters the text in free format and the system then suggests codes that are potentially applicable.

First you have to code these systems, which serve as input for other systems. The best candidates for quick coding are medication prescriptions, problem lists (diagnoses and operations) and activities. The user needs more time to input codes than free text. The advantage of coding is shown primarily when more than one system can use the coded information. For that reason it is recommended to invest primarily in having the basic functionality coded. If the user notes that the coding can be used fruitfully in other systems because there are advantages in interaction, detection, reporting, etc., then s/he will not be so inclined to consider the extra time invested in coding compared with free text as a waste of time. 33

3.1.3

Structuring

Structuring is the division of information into smaller parts in which each part has a predefined significance and a distinctive place with regard to the other information. If you want to exchange information with other systems then you have to structure this information. Structuring can also be necessary to ensure that information is always entered in the same way (e.g. for reasons of consistency or training). Another reason for structuring can be the desire to re-use information. The structuring of a discharge letter into, for example, medical history, current problems, findings and decision makes it possible to automatically copy some of these sections into a subsequent letter or to fill them in from a problem list. Specify which data have to be exchanged with other systems. Structure this data and code the individual data elements as far as possible. Interesting candidates for exchange between systems are letters reporting technical investigations (or examinations) and discharge letters. These must in the first instance be structured so that parts of them can be re-used easily and automatically in another letter. It also facilitates the integration with GP packages when forwarding them to GPs. The structuring of a problem list (see below) can also be useful for the construction of the letters.

3.2 Functionality
3.2.1 Appointments management

A rough distinction can be made between two kinds of appointments management systems:

slot based. In this version, empty spaces are provided in the system in advance into which an appointment can then be fitted. A patients name can be entered into each space, after which that space is taken. You specify in advance the time and duration of this slot and the number of slots that are available with their degree of accessibility (can only be queried by specified users, only if certain conditions are met,(such as information that is entered when searching for the slot, e.g. urgent, first visit, etc. but also the status of the appointments book (more than 80% full, less than 2 days before the time of the appointment, etc.)). The disadvantage of this procedure is that you have to decide in advance how long the duration of each slot will be (without knowing which patient is

34

being seen or for which problems). The advantage is that you can search for free spaces very quickly.

rule based. In this version you list only the restrictions/possibilities in advance (e.g. each working day between 8.00 a.m. and noon and 2.00 p.m. and 6.00 p.m., Saturday between 10.00 a.m. and 11.30 a.m.). The advantage is that patients can be added at free moments and for freely defined periods of time. The drawback is that searching for free slots can involve complex calculations and that unfillable slots arise, which means that in total there is still enough time for an appointment but that this time is fragmented over different moments.

By definition, an appointments system requires many new patient identifications to be created. It is best if an appointments system is not chosen as a central patient application. Make allowance for the fact that an appointments system requires provisional patient identifications to be created and that these provisional identifications should not be taken over into the other systems. The identification of patients in an appointments system proceeds very quickly (by telephone, etc.) and is subject to little control, so that the risk of incorrect information is very high. If you have a request and appointments system, the appointments system must not contain any request information, but these systems must refer to each other. If you only have an appointments system then a logical expansion of functionality is a request for extra clinical parameters when filling in or searching for an appointment. If you have a request system, however, you should not take this information over into the appointments system or make a fresh query but should be able to make an appointment on the basis of a request (with all its clinical parameters). The appointment and the request are linked to each other: deleting the request deletes the appointment, while deletion of the appointment makes the request unscheduled. To make combination appointments you should opt for a system that displays the possibilities for each part of the combination from which the user himself can determine the combination, instead of a system that suggests the combinations itself. For the optimum utilization of the appointments you have to enter far too many parameters to get the computer itself to suggest a good combination. If you do not enter this information

35

the suggested combination will always be less optimum than the one that a user can determine 4.

3.2.2

Results management

Copy results between systems minimally. If you copy results between different systems you must make sure in advance that copy management is being performed For further discussion, see p. 22.

3.2.3

Request and registration system

Before buying a request or registration system or having one developed, you must determine who is going to register what, when, and where. Determine whether the registration will be entered immediately and is the sole registration or whether it will be created first on paper and only entered afterwards. Who registers the request in the computer heavily determines the user interface required and the support that must be offered. If this is the person who generates this request himself (e.g. the doctor who registers a request for function measurement, a lab test, etc.) the requirements for the user interface are very high. You must be able to navigate quickly and easily between the different options without losing your overall view. If the person who registers the request is not the same person who generates it (e.g. administrative users who have to register in the computer a request that the doctor has put down on paper) then simpler interfaces can be provided. Paper allows for much more complex, visuallysupported selection methods than the computer because of the higher resolution that can be achieved on paper than on a computer screen.

When one should fix a combined appointment for 2 technical examinations followed by a

consultation on the same day to discuss results, then one must take into account the patient's condation, the distance from one appointment to the other, the possibility that certain technical examinations can not be combined (patient must be sober, contrast substances,...), external elements (patient should get the 12 o'clock bus,...). An "automatic" support will never be able to include all these elements but will foresee a safety margin. However, the user can easily include these elements.. 36

It is easy, for example, to structure more than 500 lab tests on a request form consisting of both sides of a single sheet of A4 (60 lines, 4 columns, 2 sides) without affecting the legibility and usability. If you tried to present the same number of lab tests on a computer screen in the same structure it would be unusable. In that case, more interim selections would have to be made, which ultimately would increase the number of actions required to enter the request. If an administrative user has to enter the request formulated on paper into the computer then the user interface can be many times simpler because only test numbers have to be entered. When the registration is made in the computer is also an important factor for determining the user interface. There is a big difference between the support required for users who enter information in bulk (and post facto) and that required for users who enter the information while they are engaged in a discussion, exam or whatever. A doctor who enters a request during a consultation with the patient will require a different interface to a nurse who is entering all the collected requests at the end of a shift. Where the registration or the enquiry is made also places demands on the technology. Registrations that are made as close as possible to the place where the information is generated have high technological or infrastructural requirements. A registration of the clinical parameters at the bedside demands a wireless network and a portable computer or alternatively a computer by each bed. Registrations in the consultation booths make demands on the space available in the office. If the registrations are being entered further away from the place where the information is being generated you can make better use of the available space, materials, etc. The drawback is that information can be distorted (because it is not being entered immediately), forgotten, etc. What you register can be split into content and degree of detail: it is best to base the requests or registrations that you enter on your own codes rather than on external ones (e.g. your own activity numbers rather than RIZIV (Belgian National Health Insurance) nomenclature numbers). With this approach you can even determine the degree of detail that you want to record and you are not dependent on the external need for aggregation. Usually people want a more detailed registration internally than is required for external reporting (minimum clinical data, minimum nursing data, invoicing, etc.). Register continuously only what will have an immediate impact on the functioning of the system or is necessary for external reporting. The quality of continuous registrations that serve only for long-term control without the users seeing any immediate advantages in terms of effects is in practice very low. If you want to obtain figures from registrations for long-term control you are better off using 37

sampling (continuously for a limited population or only at certain moments for the whole population).

3.2.4

Medication prescription and administration

3.2.4.1

CONSUMPTION

There is a clear difference between three types of consumption, each of which is necessary for controlling different aspects of medication management:

The medical consumption is the actual quantity consumed by the patient. The physical consumption is the quantity that has been removed from stock. The billable consumption is the quantity that can be charged for on the invoice.

It is important to recognize and make due allowance for this distinction5. Choose to register one sort of medication consumption and derive the other forms of consumption from it.

3.2.5

Patient movements

The central registration of the patient movements can be an important controlling factor for various applications. The more refined and the more up-to-date the information, the greater the advantages associated with it. The patient movements can serve as controls for authorization rules (as far as the patient file but also for external systems such as medicine chests for opiates, etc.) and for running work lists (attendance patterns, combinations of scheduled and already present patients, etc.). The patient movements can also be used for on-line quality control when entering data: activities cannot be registered outside the patients attendance period, an activity cannot be performed at a department where the patient is not present, etc.

One patient has to be given 10 ml from a 50 ml bottle. During the administration someone

drops the bottle. The medical consumption is therefore 2ml, the physical consumption is 50 x 50ml and the billable consumption is 50ml. 38

3.2.6

Invoicing

Try as far as possible to derive/suggest the data required for the invoicing system on the basis of other registrations. Possible sources are structured and/or coded reports and medical registration modules. So, for example, thanks to a structured report and the designation within it of certain technical actions (for reporting reasons), tests or the charges associated with them will not be forgotten.

3.2.7

Problem list and progress notes

A problem list is a chronological list of diagnoses and interventions that shows the current status of the patient. In this list it must be possible to change problems simply from active to inactive status and to correct their content. The progress notes are brief notes in the file that are dated and which can perhaps be related to the problems in the problem list. It need not be possible to inactivate the progress notes, given that they are just a snapshot of a specific moment and are thus always correct. The progress notes form a sort of communication log about a patient. The progress notes are less relevant in the long term. A central, structured, active and coded problem list is the basis for the proper functioning of the medical file. Make agreements in advance about their use and the speed of input. You must try to get as much information coded as possible as quickly as possible in a central problem list, so that this can be used subsequently for applications such as inputting the patients medical history and current problems into the discharge letter, for clinical information when requesting technical exams and cross-referrals, and as input for controlling certain systems such as warning systems (medication allergy, contra-indications, etc.). In the extreme case no information at all need be furnished for the requesting of exams on condition that the active problem list has been filled in up to date. The faster the information is filled in here the more readily it can be used by various applications.

39

4 Availability of the computer system

In this chapter, we discuss a number of techniques that all have the ultimate goal of making the data that are stored in the computer system available at any desired moment. An initial aspect is, of course, the avoidance of unavailability. We must, however, assume that 100% availability is unachievable or, at least, unaffordable. Measures must also be taken to restore availability as quickly as possible when problems do arise. To verify the completeness of the policy in this area you can start from a list of potential problems. For each of these items you can then examine how this risk is covered at your institution. Where appropriate, you can decide that the risk that some problems will effectively arise is so small that no measures will be taken to deal with them. This means of course that should such a problem arise you will have to call on general disaster plans of the hospital and, for example, temporarily close a number of departments.

4.1 Causes of unavailability

We suggest below a number of possible sources of problems without aiming for completeness:

Hardware problems with a computer: failure of a disk, power supply, CPU, etc. Hardware problems with the network infrastructure: failure of switches, routers, etc. System software problems: problems with the operating system, database software, etc. Problems with network due to damage to cabling. Application software problems: bugs in the application software that make the application unusable.

Failure of applications due to manipulation errors: deleting data in the database, wiping of applications, etc.

External factors: failure of electricity, fire, smoke damage, water damage in the computer rooms.

Deliberate destruction of infrastructure, vandalism. Installation of new hardware. 40

Installation of new versions of system software or application software.

4.2 Techniques to limit unavailability

4.2.1

Backup

Creating a backup is a preparation for a recovery operation. In a backup the data is copied to another medium (magnetic tape, CD, etc.) and stored independently of the operational system, as well as independently in a physical sense.6 A distinction is made between:

A full backup, in which all the data is copied. An incremental or differential backup, in which the data that has been changed since the previous full backup or since the previous incremental backup is copied.

In the worst-case scenario you will have to restore all the data of the computer system on the basis of the backups. All changes since the last backup will be lost at that moment. The frequency of the backups must be determined in the light of the maximum acceptable loss of data. If you use rewritable media for the making of backups then as soon as the first byte of the new backup has been written the entire content of the medium is lost. To ensure that there is always at least one backup of a system at least two sets of media must be available. Bear in mind that errors in content may only come to light after some time. In such a situation the last backup containing the situation before the error occurred can help to remedy the problem. At least two sets of media must be used to make a backup.

Backup should not be confused with archiving.

Backup and archiving are two different

applications, each with their own requirements. Archiving is aimed at keeping the data consultable in the very long term. Regularly performing a full backup cannot therefore be regarded as an archive. For the specific requirements of archiving we refer you to chapter 5. 41

Determine the effective number of versions of the backups to be performed in the light of the time that can elapse before a major content-related problem can be discovered. It must also be possible to use the backups in the event of the total destruction of the computer system. This is, of course, impossible if the backup media are destroyed at the same time as the computer system. The backups must be stored in such a way that they cannot be destroyed simultaneously with the operational computer system. This can be achieved by storing the backups at a sufficient distance from the operational system or by storing them in, for example, a fireproof cabinet. Bear in mind that the backups contain all the data of the computer system and that the normal access control mechanisms do not work for the backups. This problem can only be resolved by safeguarding the physical access to the backups. Protect the backups against unauthorized access. As stated above, creating a backup is actually the preparation for a recovery procedure. Of course, everyone hopes that the recovery procedure will never have to be used, but even so it is recommended that this procedure be tested out. A test of this kind will allow you to check whether:

the software that you are using for the backup is actually 100% compatible with the recovery software;

the backup media are readable; the data stored in the backup contains sufficient information to, if necessary, start up the applications on a new machine just supplied by the supplier.

Another important fact that you can learn from such a test is how much time you need to restore the system completely. This is therefore the timespan within which the hospital must be able to continue working without the support of the computer system. Provide emergency procedures to guarantee the functioning of the hospital during the time that you need to restore the computer system. These tests may lead to the conclusion that the inconvenience is too great to keep the hospital operational in a realistic way. You should then consider whether:

42

The recovery procedure can be shortened, e.g. by using different tape drives in parallel. The net period of unavailability can be shortened by setting priorities in the recovery. Here you can think in terms of, for example, a splitting of the databases into a current database and an historical database. Of course, in such a situation you can offer a meaningful application package as soon as the current database has been restored.

The chance that a full recovery must be performed can be reduced by building redundancy into the configuration (see below).

To guarantee good discipline in the making of backups it is important to ensure that this process is not dependent on the goodwill of the users. In the office equipment environment this can be encouraged by recommending users to place their files on a central server for which backup is arranged. Make sure that the backups are not dependent on the goodwill of the individual users.

4.2.2

Hardware redundancy

Almost all large machines offer the possibility of executing a number of components redundantly. The first aspect that deserves attention in this context is magnetic disks. Given that magnetic disks contain moving parts they are quite sensitive to failure. After resolving the hardware problem the data must also be restored from the backup. All server machines must be protected against the failure of a disk by RAID or mirroring. Some server machines offer other opportunities for internal redundancy. Here are a few examples:

Redundant mains current supply: of all the electronic parts of a computer the power supply is perhaps the most vulnerable part because it is here that the whole power of the computer system is processed. For larger servers, consideration can therefore be given to providing a redundant power supply.

The opportunity to restart with part of the server: some servers will try to restart after an outage caused by a hardware defect in which defective components are switched off. The server then restarts, although it with a reduced capacity. Consider whether further

43

investments in hardware redundancy are worthwhile in the context of your global availability policy.

4.2.3

Maintenance contacts

Needless to say, you should conclude maintenance and support contracts wherever necessary. These must of course be adjusted in the light of the likely impact of a system failure. For devices for which dozens of examples have been installed (e.g. office printers or PCs) you can consider purchasing a number of back-up devices yourself and then having the recoveries performed on a cost-plus basis. For other devices it will of course be necessary to conclude a maintenance contract that provides for interventions during business hours (and for other devices perhaps even roundthe-clock interventions). Decide for which systems you will have to conclude maintenance and support systems.

4.2.4

Cluster

A cluster is a traditional way of improving the availability of a computer system. The typical configuration consists of 2 computer systems and 2 disk systems, with each disk system being connected to the 2 computer systems. Under normal circumstances, one of the computer systems will be functioning, with each disk system acting as the mirror of the other. Of course, if one of the disk systems fails then the computer system will continue running on the surviving disk system. If a computer system fails then a switchover will rapidly be made to the other computer system so that users experience only a brief interruption. In the event of software upgrades the entire cluster must be stopped. In other words, this configuration does not resolve the problem of interruptions for software upgrades.

44

4.2.5

Replication server

By replication server we mean in this case a technique in which a link is realized at logical level between 2 database servers. This can be achieved by, for example, software that reconstitutes database commands (SQL commands) from the log of an operational server. These commands are then executed by a second database server the warm standby. Generating SQL commands does take some time, which means that the changes on the primary database are performed on the warm standby after some delay and that the latter is therefore not an exact copy. This technique has the advantage that the warm standby is not a physical copy of the operational server. The warm standby can accordingly have a different software version to the operational server. Alternatively, other indexes etc. can be added. This makes it possible to install new versions of software and hardware with a minimum interruption in services to the hospital. One possible scenario would then be:

Stop the routing of the SQL commands to the warm standby but continue to keep the commands up to date.

Perform the necessary maintenance work on the warm standby. Perform the buffered SQL commands on the warm standby. After a catch-up time this will accordingly again be a copy of the primary server.

Switch the users over to the warm standby as follows: - Stop all user activities on the operational database. - Wait until all the tasks have also been executed on the warm standby. databases will now be logically identical. - Reverse the roles of warm standby and primary server. The

Now repeat the upgrade procedure on the other machine.

In this scenario there is only unavailability during the actual switchover a procedure that can be performed in just a few minutes. In emergencies you can of course switch over in a forced manner, so that even after failure of the operational computer system you can switch over to the warm standby. In this case 45

allowance must be made for the fact that the data that has already been processed on the operational server but which has not yet been passed on to the warm standby will be lost.

4.2.6

Equipping of computer rooms

When equipping computer rooms, it is best if facilities for protecting the computer systems are provided. Examples include:

Physical shielding as a protection against vandalism. Automatic fire extinguisher installation. UPS as protection against short power cuts. Connection to the hospitals emergency power supply as a protection against long interruptions in the electricity supply.

Consider also equipping 2 computer rooms at some distance from one another as a protection against fire, smoke damage, water damage, etc.

4.2.7

UPS, emergency power for infrastructure outside the computer rooms

To maintain the availability of the computer system during long power outages, the equipment must of course also be set up in the workplace and the network infrastructure connected to the emergency power supply. UPS is perhaps superfluous in this case: in the event of power outage these systems can very probably be restarted. If you opt to connect only one part of the infrastructure to the emergency power supply you must check that this is done consistently: it makes no sense to have a PC running in an office if the network apparatus that handles communication with the central servers is not connected to the emergency power supply.

4.3 Redundancy criteria for a hospital

Some production lines in industrial environments depend for their proper functioning on a computer system: if the computer system fails then the production line grinds to a halt.

46

Such environments are often cited as a reference for the high availability of computer systems. In such environments however there are usually periods of varying duration in which there is no activity: think of weekends, for example, or large-scale maintenance on the production line. These periods can then of course also be used for performing maintenance on the computer system. A hospital does not have periods of inactivity of this kind: a hospital is never closed and the demands on intensive services are always critical. The computer systems that these departments support must therefore be continuously available. We have to retain our sense of realism here: a genuinely 100%-guaranteed availability of a computer system is perhaps unattainable and certainly unaffordable. It is nonetheless true that long-term unavailability in particular has a very disruptive effect on the working of a hospital. Allowance must be made for this when choosing a strategy. Bear in mind that in a hospital a few quite short interruptions in the availability of the computer system are less troublesome than one long interruption. making choices and decisions. This is a different situation to that of the typical industrial environment. Make allowance for this when

47

5 Archiving
By archiving we mean in this context the storage of data on removable media (magnetic tape, CD, etc.) with the intention of retaining these data for a considerable time. In the healthcare sector long-term is usually taken to mean decades. This poses specific problems for the consultation of the data.

5.1 Physical problems

An initial series of problems lies at physical level: will you still be able to read the bits of the medium? Consider the following factors:

bitrot: with most media the stored information gradually degrades. With a magnetic information carrier the magnetism gradually falls to a level at which a 0 can no longer be distinguished from a 1. For some magnetic media the supplier recommends rewriting the data every 2 years. Writable CDs also gradually degrade. The obvious solution to this problem is to copy the data to other media before it becomes unreadable.

Ask the supplier of the media what the guaranteed shelf-life of the medium is and rewrite the media before this deadline expires.

The technology of removable media is still developing quite quickly and suppliers do not support old equipment for ever. Eventually a problem will therefore arise in finding a computer with a device that can read older media. Another scenario is that there are no longer any operating systems that support these readers.

Make sure that you have a supported reader available (and will continue to have it available) for all the media that you still need.

5.2 Logical problems

A second series of problems lies at logical level: if you store data in the format of a specific application, will there still be programs in the future that can read this format without problems? A solution to this problem can be sought in a number of directions:

48

One way is to select a timeless format for the data storage. Think of text files, for example, without any formatting of any kind. Portable data format and XML also seem good candidates for continued readability over a very long timespan.

Alternatively you must make sure that you continue to have a computer system that can run the older version of the software. This will comprise adapted versions of the operating system, drivers and application software.

Another way is to ensure that the old formats are converted to newer formats on a regular basis.

Make sure that you always have the necessary software to be able to read the file formats of your archives.

49

6 Security

6.1 Access control

Via access control you designate who may consult and/or change which data is stored in the computer system. In access control a distinction must be made between authentication and authorization:

Via authentication a user will prove his identity to the computer system. Authorization indicates what services the user has access to and/or to which data access is granted.

6.2 Authentication

6.2.1

Basic techniques

Authentication is also used regularly in daily life. For example, a person who opens a door with a key proves that he is entitled to open this door through possession of a suitable key. Most authentication techniques are based on one of these basic principles:

authentication on the basis of something that you know; authentication on the basis of something that you have; authentication on the basis of something that you are.

Here are a few examples:

Authentication on the basis of something that you know is the basic technique for authentication in the case of computer systems: to prove that you have the right to use a certain user name you must type in the password corresponding to that user name.

There are tokens available on the market on which a number can be displayed that can be changed regularly. The series of numbers is displayed at random, but is actually based on an algorithm in which usually the time and a code that is unique to each token are 50

used. Each token accordingly produces a unique series of numbers. In access control based on tokens of this kind, the user proves that he is in possession of the token corresponding to the user name by typing in the number that is displayed on the screen at that moment.

Authentication on the basis of something that you are is used everyday when people are identified on the basis of their features, the tone of their voice, etc. Identification is performed by measuring biological characteristics. That is why these techniques are also known as biometric techniques. In an IT environment, biometric authentication techniques are also based on the measurement of biological characteristics: facial identification, retinal scan, fingerprint identification, voice identification, etc. Specific to biometric authentication techniques is that they usually do not provide a clear answer to whether or not the user is being identified. Usually we speak in terms of a certain percentage of identification. This is no different when dealing with people on an everyday level (think of the problems of telling twins apart, for example). When using biometric techniques in an IT environment, allowance must therefore also be made for false positive identifications, where someone is incorrectly identified as a valid user and false negative identifications, where the system fails to identify a person correctly. Sometimes these authentication programs offer the facility of indicating the required level of identification. If a high level of identification is required then the number of false positive identifications will fall, but the number of false negative identifications will rise.

It is also possible to use a combination of these principles to grant access to a computer system. An example is the ATM of Banksys, where access is granted through a combination of something you have (a bankers card) and something you know (the corresponding PIN code). The combination of different authentication techniques can also provide a solution to the problem of the false identifications associated with biometric techniques.

6.2.2

Discipline in authentication a correct

A very important aspect of authentication is the discipline of the users: authentication stands or falls by the discipline of the users. Here are some examples of how poor discipline can underline the authentication:

Sharing passwords. Writing passwords on a post-it note on the screen or under the keyboard.

51

Using tokens for authentication that need an extra PIN code, but writing the PIN code on the token.

These problems can only be resolved by encouraging discipline among the users. A good starting-point here is to draw up a document containing a code of conduct for the use of the computer system in which a sanctions policy is included in addition to the degree of discipline that is being aimed for. Care must of course be taken to ensure that all the users are bound to this document in a legally enforceable way. For users who have a working relationship with the institution this can be done by including the code of conduct in the standing employment conditions. Users who are not bound by the standing employment conditions can be asked to sign for agreement a copy of this code of conduct. Make sure that the discipline required for authentication is included in a document containing the code of conduct for computer use and that all users are bound to this document in a legally enforceable way. In a number of situations the discipline can also be encouraged by technical measures.

6.2.2.1

ENCOURAGING DISCIPLINE IN AUTHENTICATION WITH PASSWORDS

When authentication with passwords is used the user is generally permitted to choose his or her own password. This has the advantage that the user can choose a password that is easy to remember. The disadvantage is that the user may make a poor choice of password. By a poor choice we mean a password that can easily be guessed or found out by someone else. The methods for finding out passwords are usually based on one of the following principles:

The brute force principle, in which all the possible passwords are tried out until the correct one is found.

The Dictionary principle, in which all the words from a list are tried.

In most computer systems, however, the risk of poorly chosen passwords can be controlled by limiting the choice of users. The best way of defending against brute force attacks is to stipulate a minimum length for passwords. A defence against dictionary attacks can be mounted by refusing to accept passwords that consist of words or simple combinations of words.

52

Activate the options to refuse passwords that are too easy to guess. Insist on passwords that are at least 6 characters long. Someone who is looking over a persons shoulder when they are typing in their password can also try to follow the keystrokes to find out the password. To prevent passwords from being found out by this method it is advisable to change the passwords regularly, e.g. every 3 months. Less disciplined users will try to get round this by going through the password change procedure but then entering their old password again as the new password, or by going back to their old password again shortly after switching to a new one. These users can be encouraged to develop better discipline by making it impossible to re-use passwords and/or by giving passwords a minimal period of validity. Make passwords invalid every 3 months. Activate the options to make it difficult to re-use passwords.

6.2.2.2

ENCOURAGING DISCIPLINE BY CHOOSING AUTHENTICATION TECHNIQUES

You can also investigate the extent to which an authentication technique is intrinsically vulnerable to a lack of discipline. Here are a few examples:

With authentication via passwords the password can be shared very easily. In most computer systems the legitimate user will not experience any problems with this. With some computer systems it is impossible for more than one user to work under a particular user name at the same time. passwords. This can act as an incentive not to share

Authentication via one or other external hardware device has the advantage that this cannot be copied and so only one person can use this device at a particular time. The password cannot therefore be shared.

To ensure a strong authentication, it is best to combine at least two of the above principles. If you do not then someone who finds a token for password authentication can log on without further ado. If this is combined with a pincode then it already becomes a great deal more difficult.

6.2.2.3

PROVISION OF NEW OR UPDATED AUTHENTICATION TOOLS

When assigning new user names and the authentication information belonging to it the system manager must ensure that this data only reaches the legitimate user.

53

This is, if possible, even more sensitive when the user asks the manager to intervene in the authentication system because, for example, he has forgotten the password. Usually this question will be asked by telephone. An authentication of the requestor must then be performed before the new password is communicated. This problem can be tackled by entrusting the task of issuing passwords to reliable people who know the user personally. In a large organization this would of course require the appointment of several trusted employees. As an alternative you can update authentication information via a previously agreed communications channel.

6.2.2.4

RESPONDING TO HACKING ATTEMPTS

In quite a few cases you also have the chance, after several attempts to connect using an incorrect password, to fully block access to that user name until a manager unblocks the access again. This provides a defence against both brute force and dictionary attacks. This does however have the drawback that it becomes possible to sabotage the computer system: the obvious solution is to deny users legitimate access to the computer system. Consider whether or not you will activate the option to temporarily block access after a number of incorrect password entries.

6.2.3

What authentication techniques should be used for an HIS?

An authentication based on a combination of techniques from the three categories does perhaps lead to a perfectly watertight authentication. whether this is ergonomically and financially feasible. therefore have to be found. The fundamental question here is the extent to which you can have any confidence in the group of people that can try to get round your authentication system. When making a decision about this level of confidence the following factors must be taken into account:

It is however very questionable In practice, a compromise will

How valuable is the data stored in the computer system? procedures than for access to medical or financial data.

Obviously a less strict

authentication can suffice for access to documents concerning, for example, internal

54

How large is the group of people that may try to get round the authentication system? For workstations located in offices that are closed during the night, you only have to take your own staff into account. If workstations are in public areas you must take patients and visitors into account as well. And if you grant access from outside the institution, e.g. via the Internet, you must take all the Internet users in the world into account.

To what extent can you rely on the discipline of the users?

For use within the buildings of the institution an authentication based on passwords can suffice nowadays, provided that sufficient attention is paid to ensuring proper discipline during use. For access from outside the institution it is advisable to go over to an authentication that is based on a combination of at least 2 authentication techniques, e.g. a token for password generation combined with a PIN code.

6.2.4

Individual names

In order to guarantee an effective authorization the authentication must be performed on an individual basis. Opt, in principle, for an individual authentication. In environments in which other users very frequently have to use the same workstation it can be very time-consuming to perform the authentication procedure each time, which can give rise to a very strong temptation not to change the user name each time, which boils down to sabotage of the authentication. In this case consideration can be given to assigning a common user name. The authorization of a common user name can also be limited to a greater extent than an individual user name. This should therefore be chosen in preference to a situation in which the authentication mechanism is sabotaged by the users. In exceptional circumstances a common user name with restricted rights can be assigned.

6.3 Authorization
Authorization stipulates which users have access to which data. This has to be set at different levels: operating system, database, applications, etc.

55

At operating system level, you have to define who has access for consulting and/or changing files. In the same way, settings must be made in the database system to define exactly who has access to the information that is stored in it. In some applications, authorization can also be set. In some cases these settings are

translated into settings at system level. In other cases the application itself will also use a number of extra authorization rules, e.g. not releasing certain information to the user. In some cases this is used in a very extreme sort of way: some packages always set up the connection to the database system with the same user name and password and realize full access control in their own code. Should a user succeed in such a situation in interrogating the database directly the extra limitations that the application implements will of course disappear. Such access must, of course, be made impossible. If it is not, the security features in the application make no sense. Make sure you have a consistent policy that can be maintained in the longer term. To achieve this, use the available tools, e.g. division into groups, roles, etc. to keep the administrative work associated with it down to acceptable levels. Make sure that extra security features introduced by the application cannot be circumvented by, for example, interrogating the database directly. The employees with system manager rights require special attention. therefore be kept to a minimum. Check which people within the organization have system manager authorizations. For the system

managers the normal access controls apply. The number of staff that have these rights must

6.4 Management of users

It goes without saying that the user names of employees who leave the institution must be blocked to prevent mischief. The authorization of users must also be properly managed: if a user no longer requires certain authorizations then they must be deleted also. The person responsible for defining the authorizations must have the correct information about the current task distribution within the various departments. If the authorizations are defined centrally then a smooth information flow must be organized. An alternative to this is to delegate the management of the authorizations as far as the level of those people who are responsible for deciding the task distribution within the departments. The person responsible for task distribution can then himself ensure that the 56

authorizations are adapted to changes in the distribution of tasks. This does of course require the necessary degree of discipline from the decentralized managers. Make sure that when a member of staff is dismissed or leaves for some other reason and in situations where misuse of the system is suspected that all access to the computer systems can be rapidly denied to this person. Try also to ensure as much consistency as possible: make sure that a user has the same user name on all systems (and, if possible, the same password). A system that is making more and more of a name for itself in this area is the Lightweight Directory Access Protocol (LDAP). With this system you can manage in one environment the users for all computer systems in the institution.

6.5 Automatic blocking of a session in the case of inactivity

A workstation of a computer system that remains unmanaged does of course make it possible to continue using the authorization of the previous user. Many computer systems and applications make it possible to block the workstation after a brief period of inactivity. This prevents unauthorized access to the applications, but in most cases it means that the workstation can only be unblocked again by the original user. A solution can be found for this if necessary by not using the mechanism of the operating system but by instead replacing it with a mechanism in the application. Investigate how you can best handle workstations on which there has not been any activity for a short time.

6.6 Auditing
By auditing is meant in this context the recording of certain actions performed on the computer system. Most operating systems and database systems make it possible to create audit logs. In these logs both successful actions and actions rejected by the authorization rules can be registered. Examples include a successful or failed authentication.

57

Audit logs of this kind are indispensable for tracking unauthorized use. They can also help to find out exactly what has happened when unauthorized use occurs. For that reason, logs of this kind are usually kept for a period of at least several months. The application programs can also contain audit logs of this kind that can register events at application level. Make sure that the application software (operating system and database systems) records sufficient auditing information to be able to detect unauthorized use. Make sure that the auditing logs are checked regularly.

6.7 Encryption and digital signature

Encryption can be used within a computer system as an extra protection for very sensitive information: besides bypassing the access control you also have to know the encryption key to be able to read the data. The terms encryption and digital signature usually relate to a situation in which data has to be electronically transferred. In this case the encryption will ensure that only the authorized addressee can read the message, while the digital signature will irrefutably identify the sender. Various types of algorithms are used for this purpose: symmetric encryption algorithms, asymmetric encryption algorithms (also known as public-private key algorithms) and hashing algorithms. For public-private key algorithms, certificates are also required. In the case of encryption we have to accept that a 100% protection of encrypted data is impossible: provided you have sufficient computing capacity it is always possible to find the correct encryption key. It is therefore important to always choose sufficiently long keys to make this operation unfeasible in practice. Given that the computing power of an individual computer is constantly increasing, the key lengths also have to be gradually lengthened. This is therefore an aspect that requires regular monitoring.

6.7.1

Symmetric encryption algorithms

These are encryption algorithms in which the same encryption key is required for both encryption and decryption.

58

These algorithms are usually quite fast in execution. The main problem is, of course, that the encryption key has to be exchanged securely. When using symmetric encryption algorithms, make sure you have an adequate key length: 128 bits is a minimum.

6.7.2

Public-private key algorithms

As the name suggests, in public-private key algorithms two keys are used: a private one that is only known to the user of the key and a public one that is made known to everyone. Algorithms based on these principles are mathematically very complex and therefore require rather more computing power. The most obvious advantage is, of course, that no exchange of keys is required. If the sender encrypts the message with the public key of the addressee then only the private key of the addressee can be used to decrypt the message. When using public-private key algorithms, make sure you have an adequate key length: 512 bits is a minimum.

6.7.3

Certificates

When using public-private key algorithms, we use the public key of the correspondent. But how can we be certain that the key that we are using is actually the key of the person or institution that we intend? The answer to this question is provided by the certificates. A certificate contains the public key and the identity of the owner, both signed by a certification service provider. To apply for a certificate, you have to offer the certificate service provider a public key together with the identification data of the person or institution to whom this key belongs. The certificate service provider will then check the identity and confirm via the certificate that this check has been performed. Certification service providers usually have different types of certificates with varying levels of identity check. What level of identity check is performed is described by the certification service provider in his Certification practice statement.

59

The lowest levels of control actually amount to no control at all and are therefore only suitable for test purposes. Decide on the level of identity control that is necessary for your application and make sure that only certificates to which an adequate control is linked are accepted.

6.7.4

Hashing techniques

A hashing algorithm calculates a check sum of a document. The algorithms that are used for this purpose are so powerful that the chance of two different documents resulting in the same check sum is almost zero. Well-known algorithms for this purpose are MD5 and SHA1.

6.8 Viruses, worms and trojans

Viruses, worms and trojans are all pieces of software that are spread with the purpose of getting a computer system to do things over which the normal user has no control. These pieces of software also try to spread themselves over as many computers as possible. Given that computer systems used as office equipment constitute far and away the majority of such systems in use, they are also the favourite target for viruses. You should assume that it is impossible to keep an institution entirely free of viruses, etc. To keep the spread in check, the viruses that have succeeded in penetrating must be removed as quickly as possible. To do this the computer systems must be regularly scanned. It can, however, be useful to perform an extra scan on the routes via which viruses can penetrate the institution, e.g. via e-mail. Design a virus control scheme in which at least all the disks on which data managed by an office automation system is stored is regularly scanned. Check whether other measures are called for.

60

6.9 Physical access to computer systems

Physical access to a computer system usually offers extra opportunities to circumvent the authentication system, e.g. by restarting the system, perhaps with a different version of the operating system. Restrict physical access to the computer systems to authorized persons.

6.10 Theft of laptops

Laptops form a special kind of security risk: when a laptop is stolen, not only is the computer lost but the thief also has access to the data stored on the hard drive. Authentication is no help in this case, as the thief can use all the possibilities of system management to circumvent the authentication. There is only one adequate solution: lock the sensitive data, if necessary by locking the entire drive. If sensitive data are stored on a laptop, then make sure that these data are locked.

6.11 Access for hardware support

More and more suppliers are asking if they can use a modem or the Internet to access from their offices the hardware set up in the hospital. As far as support for this hardware is concerned, this is a good thing for both parties: the supplier can offer support more readily and for the hospital the problems are rectified more quickly. If a device is also connected to the hospital network, the staff of the company could also try to penetrate further into other hospital computer systems. This means that you are also contracting out the security of the hospital network to this company. Make sure that external companies cannot access devices connected to the hospital network without seeking the hospitals permission. Any regular reports must be sent from the hospital, not retrieved by the company.

61

6.12 Internet access

Protecting all the computer systems of an institution so that they can be connected to the Internet without risks is impossible in practice. In addition, the security measures would place a very heavy burden on the everyday use of the computers. For that reason, connection to the Internet must be made via a firewall, which makes access from the Internet to the internal computer systems impossible. Connections for which the initiative is taken by the hospital are not usually a problem from a security standpoint: the initiative is taken by a member of the hospital staff. If you want to offer services via the Internet then consider setting up the computer systems that offer these services in a demilitarized zone so that, should someone succeed in taking over control of these systems, access to the other computer systems of the institution remains impossible. For services for which no authentication is requested this is a necessity. Make sure that, for the other departments, you set up an easily manageable and monitorable environment, among other things by only setting up one channel that is properly monitored. It is also recommended in such cases to ensure that only the applications that are really necessary can be accessed. If the hospital network is connected to the Internet this must be done via a firewall. Computers that provide services via the Internet for which no authentication is requested must be set up in a demilitarized zone. For other services and departments, provide one communications channel that can be optimally monitored and controlled. Departments in which sensitive information is exchanged must use encrypted connections. Make sure also that the infrastructure protects the user against man in the middle attacks. There is, of course, no point in developing a proper firewall infrastructure if other less wellmonitored forms of access to the hospital computer systems are possible. Consider in this connection PCs with a modem and PC Anywhere and similar products. Make sure you have a policy that offers setups of this kind, linked to a sanctions policy. Make sure also that no extra connections can be established round the firewall.

62

6.13 Virtual private networks

A virtual private network (VPN) is a private network connection that is realized via the Internet. A tunnel is established between a computer system and the network of an institution, so that it is as if the computer forms part of the internal network of the institution and can make use of all the services of the internal network. To maintain the security of the internal network, care must therefore be exercised to ensure that the computers connected via VPN meet the same security criteria as the internal computer systems: virus scanning, no extra connections around the firewall, etc. Virtual private networks can only be used when the management of the computer systems that have been set up remotely meets the same quality requirements as the internal systems.

6.14 Access control at application level

The techniques and recommendations for authentication, authorization and audit at general system level are also valid for the applications. Below we describe only the extra recommendations that can be considered for the applications.

6.14.1 Authentication The authentication should preferably be based on that of the underlying management system or be synchronized with it. If the authentication for medical applications is the same as or synchronized with that of the other applications (e-mail, personal files, etc.), passing on the information for this authentication (what people know, have, etc. see p. 50) will involve more risks, so that users will be less inclined to do this. One of the techniques commonly used for this is the LDAP.

6.14.2 Authorization Decide in advance which access control model you want to use throughout the entire hospital. This choice must be made independently of the solutions offered. This choice will then determine the possible applications and integration (and not vice versa). 63

When deciding on the access control model, there are various access axes that must be taken into account:

Departments (specialisms): one patient file per department or 1 central file. Functions (doctors, nursing staff, administrators, etc.): one file per function or 1 central file for all functions.

Patients: do you have access to all the patients in the system or do you only have access to certain patients on the basis of a recent contact, etc?

The access control model chosen is a combination of choices in the above axes. The more you opt for a scenario in which different axes come together to form 1 central file, the more requirements there are for the authorization possibilities of the application. If, on the other hand, you opt for one file per department/function with, within this, access to all patients, then the requirements for authorization will be minimal. Hybrid forms are also possible (1 central file for all specialisms but split per function, etc.). This model will influence the integration and limitations in the applications that are offered (see p. 12). In a central or linked system in which several departments have access, an access control that is based solely on function is not good authorization policy. Usually people think that they can make do with access rules that are based on the groups of users. Doctors can see everything, nurses can see a bit less, and administrators can only see administrative data. Systems that only allow access rules to be determined on the basis of the function cannot allow sufficient splitting in the rules for access to the different patients. The users can then see the data that their function allows for all patients, and that is an unacceptable situation if this application is used across different departments. If you opt for a very strict access control model a user must be able to break through this after giving a reason and after a further audit of the actions. The information on which the access control is based can only be historical. In an extremely large number of cases, people want access to the file because of something that still has to be entered (and they are authorized to request this from that moment onwards). Typical examples are: the patient is coming in for a consultation (but without an appointment); the anaesthetist is seeking access to the patient to arrange an operation but the admission scheduling has not yet been entered.

64

The stricter the access control, the more need there is to be able to break through it. If there are more breakthroughs you must investigate these breakthroughs more intensely. In that case you had best ensure that the reasons that are given for these breakthroughs are structured and coded as far as is possible. If the number of breakthroughs is very high, there is a risk that the attention paid to the few nonlegal breakthroughs will wane because of the large number of legal breakthroughs. For that reason you must be able, if a large number of breakthroughs have occurred, to work out rapidly whether or not a breakthrough is legal. You can do this by making breakthroughs structured and even coded. For the patient who is coming in for a consultation you let the user record a code for patient is coming in for a consultation instead of letting the user enter the reason for this breakthrough in free text. You can then automatically identify this coded breakthrough as legal on the basis of the information that has become available in the meantime (e.g. an appointment that has been made, a subsequent patient movement, etc.). The stricter the authorization rules, the more support must be given to structured data within the system to be able to base these rules on it. Potentially structured data on which you can base the authorization rules include:

Patient movements: through the accurate monitoring of the physical presence of the patients and the corresponding timings. The physical presence within the hospital can be heavily subdivided: from minimal presence and absence in the hospital to a refined monitoring of all possible locations (medical departments, function measurements, operating rooms, etc.).

Contacts between patients and care providers: the recording of the supervisory physician, nurses, social workers, etc. with a specific patient.

Information in the future: appointments, scheduled operations, etc. User movements: who is present when and where.

This data can be manually entered (and will then be relatively static: doctor X has worked for 2 years on emergency cases, nurse Y for 4 years in paediatrics and so on). There are also ways of recording this data dynamically and automatically (badge systems with which users have to make known their presence at a particular location, infrared or radio-controlled detection systems, etc.). For medical applications it can be necessary to define a more refined or different hierarchy of groups and roles than those required for administrative applications. Check whether you can specify this separately for each application. 65

The groups and roles that are necessary for the various applications can be in conflict. Someone can have a managerial function within the purchasing department but may only be assigned administrative access to the medical file.

6.14.3 Audit

6.14.3.1 POLICY Decide and communicate in advance what the sanctions are when infringements are detected. If you do not decide and communicate in advance what the possible sanctions are when the access rules are infringed, these will be decided upon subjectively at the moment the incident occurs. Check the level (per patient, per user and globally) at which the audit can be defined and for which actions (logging on and off only, per action, and the related content). The more refined the level and the actions, the more control you have over the necessary investment for the storage of the audit logs or how long you can keep these. If you do not have any restrictions on storage of the log then you must save it as long as possible in as refined a manner as possible, given that it must be possible to report and document most infringements post facto. It is best if the system behaves in the same way with or without a log, so that the user does not notice any difference. If you notice that a certain patient, action etc. is being logged and another one is not, you have an inclination to treat non-logged actions as legal. If everything functions in the same way but you know that something may have been logged, you have the inclination to treat all actions, patients, etc. with the same degree of confidentiality.

6.14.3.2 AUDIT PER PATIENT Setting up a log per patient can be useful for people for whom the risk of infringement is greater than normal. This is the case with VIPs, but also with your own staff and their family members. Make due allowance for the fact that the biggest security risks are your own staff, both as perpetrators and as victims of infringements.

66

If you have the opportunity to activate the log per patient you must make sure you do this for all employees because it is here that the risk of infringement is greatest. Do not register VIPs as anonymous patients (under a pseudonym). Register them under their own name, via which you activate the log for this patient. If VIPs are registered under a pseudonym this is usually only known to a limited number of people in the hospital. This means that with these patients there is an extra risk of the unavailability of the information required at that moment if the patient has to be urgently treated.

6.14.3.3 AUDIT PER USER An audit per user is a good idea for users with whom there is no contractual relationship, and the sanctions can be made just as severe as for your own staff. An audit can also be applied to users for whom you cannot define the authorizations in advance but can only check post facto whether the accesses sought are legal. Instead of not giving these users any authorizations at all you can decide to give them full authorization and then confirm the registered actions (or have them automatically registered) post facto. Examples are accesses to trial patients, etc.

6.14.3.4 AUDIT PER ACTION You do not need just to be able to log who has performed which action when (and perhaps also where). For the documenting of an infringement or for medico-legal reasons it can even be necessary to be able to document what information (the content) someone has asked for, changed, etc.

6.14.3.5 CHECKING THE LOGGED INFORMATION Make the group of people who can examine the logs as large as possible. Do not make the examination of logs the responsibility of a limited group of people, but of everyone. If the logs have to be checked by a limited group of people then these people can find it difficult to check the validity of the logged actions. This small group of people is going to have to select where the problems lie from a large number of logged actions. This can only be done if automated and standard controls are used. If you allow a large group of persons to view the logs they are going to confine themselves to examining those logged actions about which they have more information and which they 67

know are (il)legal. In addition the number of logs to be examined is relatively small, which makes it a minor additional chore. A doctor will easily be able to work out whether the logged actions for the patients for which he is the attending physician are legal. He knows from whom he has requested a consultation, who is working at his department, to which technical exams he has made referrals, etc. For a small central group, a lot of this information cannot be made available in electronic or structured form, which makes it impossible to check these logged actions for all patients. There will then be too many logged actions remaining regarding which no judgement can be made, which means that the suspect cases will catch the eye less readily.

68

7 Key issues in project management

It is not our intention in this chapter to recommend a specific project methodology but rather to examine a number of key issues that are specific to the setting up and execution of IT projects within a hospital. When purchasing a product you must strive to adjust your own organization maximally to the functioning of the product and to adapt the product minimally to your own organization. In the purchasing negotiations, the users typically visualize the product working in accordance with their current procedures, and the salesmen win them over by talking about possible adaptations of the product to bring them into line with the local working procedures. Although this can provide the greatest satisfaction in the initial implementation, this decision has severe consequences for the further life of the product within the hospital. The local adjustments are the most expensive and most frequently recurring elements in any future implementation of new versions. Because of this, these adaptations are also the usual reason why new versions can no longer be implemented or only after a long delay. You must ask yourself whether it is better to pay the once-only price of adapting your procedures rather than choose a product that is closer to your own way of working (but which perhaps has less functionality, larger initial purchase price, etc.). The decision-making body and the project team must be advised by a group of user representatives, the individual members of which have the necessary hierarchical authority and will also have to themselves live with the decisions that they recommend. You must avoid a situation where the product is purchased or a solution developed on the basis of purely managerial or economic considerations without a user group being able to translate this into terms relevant to the users who will have to work with it every day. The members of this user group must, however, be sufficiently high up in the hospital hierarchy to appreciate the need for such deliberations. On the other hand these people must also be confronted in everyday use with the decisions that they positively recommend. This ensures a balance between strict user needs on the one hand and economic and managerial needs on the other. The implementation of a self-developed or purchased product requires a team of hospital employees of the hospital who are sufficiently familiar with its functioning to pass on the necessary information for local supplementation, maintenance, etc, and who can test the product. These people must in this case be released for the necessary time.

69

The costs of purchasing or self-developing a product are not confined to paying the supplier or the developers but also involve a hidden cost of time invested by employees who have tasks at the hospital other than IT tasks. Try to obtain an estimate of the training required. This means not only the cost of providing this training but also the time spent by the future users on following this training when they could be doing something else. Often the training required is underestimated. Either the future users are given too little time for this or they themselves pay too little attention to attending the training courses. Being thoroughly familiar with the basic functioning of the product and its correct use at the outset can, however, save a great deal of time and prevent a great deal of damage later on. Before taking the new product into use, work out the emergency procedures that have to be followed in the event of failure. Do not base these emergency procedures on the old procedures that are being replaced by the new product; make them visibly different and much simpler. When working out the emergency procedures, do not assume that the computer infrastructure will be available. No single technical solution can guarantee 100% uptime. Even 99.5% uptime means 2 days downtime per year. In the face of this reality you must work out procedures in advance to bridge this downtime. After the successful implementation of the new solution, the knowledge among the users of the old way of working will rapidly evaporate. For that reason you should make the emergency procedures as simple as possible (in such cases, for example, make distinctions between urgent cases and things that can wait until the system is available again). Before you automate you typically have various forms and procedures to support all possible eventualities. If these forms and procedures are recorded in a computer program then quite soon after its implementation the users will lose familiarity with the multitude of paper forms and procedures. It is therefore best if the emergency procedures use heavily simplified forms and procedures. Decide whether the emergency procedures have to be tested regularly. Testing the emergency procedures only makes sense if it is done when normal working is also effectively interrupted. To minimize the negative effect of these tests at a time when, strictly speaking, they are not necessary, you can announce in advance that these tests are going to take place.

70

It is only by testing the emergency procedures regularly that you can be sure that everyone knows during a genuine unavailability of the computers exactly what you have to do to bridge this interruption. In addition, the emergency procedures are then continuously tested for their usability and you can find out what adaptations need to be made. During these tests you also have to effectively interrupt the systems for which these emergency procedures are designed. Work out a rollout plan in which each phase is tackled in its entirety. Avoid duplication of any one phase. When taking new procedures into use you must ensure that you stop the old procedures as quickly as possible. In many cases you have the inclination to still not trust the new system completely and you will continue to perform crucial parts in the old way until you are sure that the new system has proved its reliability. Possible reasons for this are that the entire functionality is not yet available, there are still a few bugs in the new system, not all the derived reports are possible, etc. If you persist with this duplicated mode of working for too long then the new system will never be able to prove that it works properly or the defects will not come to light to a sufficient extent because you can always fall back on the old way of working. The extra working pressure caused by duplicated working and the greater familiarity with the old way of working will also have the effect that you will start using the new procedures less. You should therefore check, after a previously agreed time, whether all the procedures have been effectively stopped and you are only using the new ones.

71

8 PACS Picture Archiving and Communication Systems

A PACS (Picture Archiving and Communication System) is a subsystem for the management of medical images, including their presentation on a workstation. data volumes and the need for domain-specific presentation. In this text we are concerned with the management of the images generated by the Radiology department.7. PACS can then be regarded as a computer system that takes over the functions that until now were realized via film. With digital images on the other hand fundamentally new options are also possible that were inconceivable with film, especially the processing and analysis of the images with manipulation of the content of these images. For the purposes of the discussion in this text, such processing is not regarded as a part of PACS: PACS is seen purely as the infrastructure that serves to facilitate such functionalities. This subsystem specializes in images that make high technological demands through their large

8.1 Individual aspects of a PACS

8.1.1

Archiving of images

8.1.1.1

DIMENSIONING OF THE ARCHIVE

An initial factor that determines the size of the archive is the rough volume of pictorial material that you want to store (the number of pixels * the number of bytes per pixel). This is easy to estimate. The number of radiological exams or the number of beds in the hospital already provides some indication of the annual production 8 Make due allowance for the fact that new imaging devices are increasing that volume (see below).

Many of the key issues can be transferred to a PACS for other medical images, but

technological details or organisational emphases can differ

8

For a typical mix of different types of examinations and with the recent PACS technology,

20 Megabyte per radiologic examniation could be used as a first rough estimation 72

These images are usually stored in a compressed form. A compression factor of 2 (to 2.5) is feasible without any loss of quality (reversible compression). compression. Significantly larger compression factors can be achieved if you are prepared to accept that the image once compressed is slightly different to the original image (irreversible compression). The idea behind it is that with moderate compression factors (e.g. around a factor of 10) the difference in practice is not noticeable, is smaller than other uncontrollable factors, and is of no importance for making medical decisions. This form of compression can change the technological options and can, for example, mean that for the same investment you can achieve more rapid access to older images, which medically speaking is a significant advantage (see next section).9. There is, however, still no generally accepted consensus on what the right compression factors are. For that reason many hospitals are afraid that if they can only submit compressed images in the event of a possible complaint against medical errors then the burden of proof will be reversed to their disadvantage. Decide in consultation with the hospital management whether and in what way use will be made of irreversible image compression. In any case always check the effect of this on the cost and functionality of the archive and distribution system, since the more rapid access that might possibly result is a medical advantage. If you opt to use irreversible compression then retain also a version of the images without the use of irreversible compression in a slower part of the archive. The developments in radiological imaging are posing new challenges for PACS. An initial factor is that the newer image-forming devices, and certainly CT and MR scanners, always generate more images and/or higher resolution images.
10

When discussing data

volumes, always make it clear whether you are talking about volumes before or after such

A second, more recent factor is

the anticipated advent of recording techniques in which a dataset is generated through which the user can navigate interactively. This blurs the concept of an image: from this dataset an infinite number of images can be generated. A question that can be asked in this

There is no technological advantage in performing this compression before the radiologist

has studied the images

10

It is very likely that in the coming years the growth in the amount of produced images

exceeds the growth capacity of storage and communiction systems 73

connection is whether all the images have to be retained 11. It is not yet clear how important this question will become as a result of the various technological developments. If you are using multislice tomographic imaging, make a decision in consultation with the hospital management concerning which parts of this data has to be saved.

8.1.1.2

HIERARCHICAL ORGANIZATION OF THE ARCHIVE

Due to the sheer volume of data that has to be stored, it is usual to divide an archive for PACS into different levels. A working set of imaging exams is kept available on magnetic disk. Exams that have not been requested for some time are only available on slower media in a robot, or perhaps only off-line. So as not to be confronted within this organization with long waiting times if the images have to come from a robot (minutes instead of seconds), prefetching is used: images with a good chance of being required are automatically made ready on magnetic disks. This requires information about patient movements (from other information systems) and rules that determine which exams have to be got ready. Such rules are easy enough to draw up for the operations performed internally within the department of Radiology (when the patient comes in for this type of exam, get the previous two exams of the same organ ready), but are much more difficult to establish for the use of images throughout the rest of the hospital. With the falling cost/volume relationship of magnetic disks, however, we can nowadays consider the radical solution of providing all the storage on magnetic disk, certainly if you have opted for the use of irreversible compression. increased simplicity of management. In the interests of the global organization of the storage system, make the following two decisions: (1) whether a hierarchy will be constructed containing slow components (which demands prefetching), and (2) whether older images will only be retained off-line (which demands manual actions if you want to view these images). This avoids all the problems and drawbacks associated with prefetching. Any additional cost must be weighed against the

11

When films were used, it was also current for a tomography with thin slices, to draw only

one subset from these sections to distribute them. Same for an echography, which is an interactive examination: the radiologist decides chich are the instantaneous ones preserved as an illustration. 74

8.1.1.3

SYMMETRY IN ACCESS TO THE ARCHIVE

Until a short while ago, large data volumes made it a technological challenge to retrieve imaging exams quickly (in a matter of seconds). A method that has already been used to reduce technological requirements is to send the images in advance to the workstation(s) where they will presumably be used or to a local subarchive. If you have to perform this prefetching to be able to retrieve these images from the workstations, this leads to significant limitations in the organization. With present-day technology for networks and archives, it is more common to use an archive from which all the workstations can retrieve all the images symmetrically12, which is much more convenient in use. As far as possible, avoid an architecture in which you need to know in advance from which workstations you will be retrieving images. If the speed of the connections is a problem, e.g. in operations at two different locations with low bandwidth between them, it can actually be an advantage if the PACS has mechanisms for explicitly fetching in advance a copy of the images ready at the other location. The extra cost caused by the complexity of the system (including the maintenance and the reduced flexibility) must however be weighed against the cost of a larger bandwidth. When using intelligent solutions to deal with technological limitations in which you have to make predictions, consider whether a brute force use of technology will not ultimately be cheaper.

8.1.1.4

BACKUP AND CONTINUITY OF OPERATION

Database technology is only a part of the story The images are in general not stored in a database only the references to these images and meta-information about these images (the actual image management system).

12

Possibly faster is when the system finds a copy in a local cache, but that system works

transparently 75

Backup & restore Of course, a frequent backup of the actual image management system is crucial. This database is not of exceptional size and the usual backup strategies are suitable. On the other hand these backup strategies cannot be used for the actual image material, due to its volume. However, the images do have the characteristic that they can no longer be changed. Security against loss of an individual image, typically by a media fault, can accordingly be achieved by writing out a copy once only to an independent medium at another location (and ensuring the integrity of this copy, according to the recognized techniques). Security against destruction of the entire archive or an important part of it forms a special challenge. The questions are (1) how quickly you can start working again (possibly with lower performance) by using copies of the images, and (2) how quickly you can rebuild the original archive. If all the images, including a copy, are available on-line on fast media (which is unusual) then that will of course be a reasonably fast process. If the copy is maintained off-line then the process could take a very long time. As regards recovery, you are of course recommended to have special support for the PACS software. After all, the images have to remain indexed from the management system, the control of the data storage can be specific to the robot(s) and, since you can hardly be expected to wait until a new backup copy is made and the archive is fully operational again before restarting the operations, the software must make allowance for the fact that the archive is only partially available. With the supplier of the PACS, work out a procedure for the continuation of operations after a large part of the archive has been destroyed. Estimate how long this procedure will take (time until functioning with acceptable limitations is possible versus time until the original situation has been restored). If the backup copies of the images are maintained off-line then at least check whether the software of the PACS permits these copies to be used immediately after they have been loaded into a new robot (possibly of a different type to the previous one). Changing or expanding the storage system Given the specific organization of the archive, the way in which it can be expanded can depend on the software of the PACS supplier. Given the volume of data, the conversion of a file archive to a new archive can take a long time, especially if a near-line component is involved.

76

Discuss in detail with the supplier of the PACS what facilities are provided for expanding the archive or replacing its components (when data has to be transferred).

8.1.1.5

CONSOLIDATION OF STORAGE NEEDS

Storage and its management are important cost factors in hospitals. Check whether you can use a joint storage system for PACS and other applications in which a large amount of data is stored. This makes it essential that the PACS is able to use this 3rd party solution. In the earlier PACS systems this could certainly not be taken for granted, given that they had the inclination to provide their own software for the control of the different hierarchies in the storage system. To an increasing extent however, these systems use standard solutions and this can certainly be discussed.

8.1.2

Distribution of radiological images throughout the hospital network

The introduction of PACS can be an argument in favour of making the network faster. With the existing technology, the network within a building is no longer a stumbling block to the introduction of PACS and most probably not the biggest cost factor either. In most cases no separate network infrastructure is used for the PACS. The bandwidth to be provided for images to users throughout the entire institution is influenced by the choice of clinical viewer (section 8.1.5), since this component is already optimized to achieve a certain economy of bandwidth. There is sufficient experience with the suppliers of the PACS or users to make suggestions about the required bandwidth.

8.1.3

Connecting the imaging devices

Digital linking versus secondary capture Almost all new imaging devices for Radiology can be linked digitally to the network (see the next point about DICOM). If an older device cannot be linked digitally there is a possibility of digitizing the images from the analog output that is used to control (for example) a printer. The result will then be as if a print had been scanned on film. The functionality for working further with these images is more restricted.

77

A special problem with this sort of secondary capture is the sending of patient and exam IDs. A possible technique is to deduce these from the text that has been printed out onto the film via automatic character recognition. This is, however, unreliable (see section 8.2.3). DICOM The DICOM standard was developed for the exchange of medical images and related data. This standard is widely supported in the radiological world (and more generally in PACS). DICOM defines two things:

Coding (in a high degree of detail) of imaging information, including acquisition parameters, spatial relationships between the images, information about patients and exams, etc.

A (complex) protocol for communication with an entity that offers a specific service for these images (storage, printing, etc.).

Different DICOM services A device can be DICOM-compliant without necessarily supporting all DICOM services. The most usual services are briefly described below:

Image Storage defines how a device has to send a set of images to another node, e.g. to a PACS.

Storage Commitment is a refinement of the previous function of an archive, and provides feedback when the images have been written out securely (and therefore can, for example, be wiped from the module).

Modality Worklist defines how the HIS can send information about the patient and exam to the imaging device so that this information can be included in the digital dataset (see section 8.2.3 p. 89 for the reasoning).

Print prints a series of images over the network on a DICOM printer. A printer of this kind will almost certainly be provided for printing from the PACS workstations. The possibility of printing from the imaging device is useful for emergency procedures.

Performed Procedure Step allows the imaging device to report that a (part of an) exam has been performed and to supply administrative information about the images and the procedure with which a PACS or HIS can initiate further operations or perform quality controls. 78

Query/Retrieve allows an independent system to retrieve images from a PACS and to make a local copy of them (see section 8.1.4 p. 79, the section on specialized workstations).

Try to activate on all imaging devices that you want to connect to the PACS at least the DICOM functions Image Storage and Modality Worklist. Discuss with the supplier of the PACS what other DICOM services can be utilized by that PACS, and check on their availability with the suppliers of the imaging devices. Level of integration with DICOM DICOM is a communications standard intended for the exchange of imaging data between independent systems. DICOM is not intended to achieve a tight integration of applications with images or to, for example, realize a joint management or an overarching user interface.

8.1.4

Viewing for primary diagnosis

Functionality, technology and conditions of interactive study of images There is now sufficient experience of diagnosis on workstations, so we need not go any further into this subject in this text. Nor will we be discussing here any aspects such as the performance of measurements on the images, calibration of the imaging screens, or the realization of the correct lighting conditions. Selection of exams, worklists The system must build up worklists from which the exams to be studied can be selected. In the non-automated organization, the worklist consists of a stack of film folders with the most urgent exam at the top. With fully digital working, the token value of paper disappears and all the information must be explicitly presented by the computer. When different radiologists are working together on a packet of exams, the system must synchronize worklists across different workstations and prevent different radiologists from starting to report on the same exam. Investigate where in the existing organization people rely on the token value of paper or film. Check whether this function is sufficiently taken over by the digital worklists on the workstation for image viewing and identify where additional information must be brought into the computer system.

79

Bookmarking of images Here we are concerned with the possibility of compiling a collection of images as especially relevant or illustrative, e.g. to be able to find comparison images quickly when comparing exam results later on. There is less experience of this function, but given the increase in the volume of available image material, it will become important. Filtering of images The imaging department may have a policy of sending only a summary of the imaging exam (see next point) to the requestor or enclosing this summary as an additional item with the other images, etc. It cannot therefore be automatically assumed that the PACS supports the desired procedure. If the imaging device generates a large number of slices lying very close to one another, a subset of images with a larger distance between them may be used throughout the rest of the process. The PACS must then provide mechanisms for automating this feature. Only making a subset of the images available can be done by only maintaining these images (p. 74), or by only maintaining the other images in a slower part of the archive (or in a part of the imaging department), or by simply making this subset easier or faster to retrieve, which is more a question of ergonomics and efficiency than of imposing restrictions. At policy level, a decision must be made regarding the extent to which only a subset of the images will be sent from the imaging department to the rest of the institution. Another point is whether the PACS can implement this decision technically without requiring too many manual actions. Use of another suppliers workstations on the PACS The user interface on the workstations is strongly linked to the non-standardized management system of the PACS. It is therefore impossible to transparently replace the viewing stations of the supplier of that PACS with workstations from another supplier. What is possible is to exchange imaging exams with another workstation that, for example, supports specialized visualization or surgery planning The further manipulation of the images on this other workstation is from then on dependent on the PACS, and without the management functions offered by that PACS. An initial possibility is to pass these images on from the PACS (DICOM Image Storage). A second possibility is to allow this specialized workstation to query a list of exams present in

80

the PACS that meet certain criteria and to itself transfer these exams (DICOM query/retrieve). If you want to exchange images with specialized workstations, then you had best ensure that the suitable DICOM functions are provided. Make due allowance for the fact that the image manipulations and processing on these workstations are independent of the PACS. Managing the results of specialized processing or analysis A very common reason for exchanging images with a separate workstation is to perform specialized processing there. The results of this can be images but can perhaps also be numbers or specialized presentations. You cannot automatically assume that these results can be sent back to the PACS for storage and further management, certainly if it is data for which DICOM does not have a standard. If you want the results of the processing on independent workstations to be managed in the PACS, you must examine in detail with the suppliers concerned whether that is indeed possible and whether the explicit communications required for this make this setup worthwhile. Ask yourself whether the processing cannot be performed within the PACS. Access control Access control from the workstations of the PACS must be explicitly provided for in that PACS. As with every subsystem, for the PACS also you must check how the general policy for access can be implemented. An alternative is to have the exams selected in the HIS or the RIS (section 8.2.2) and so delegate access control to that system. If the images have been sent to a workstation or system outside the PACS, the access control from then on lies, of course, in the hands of that other system. A special problem is that refined access controls are not possible in the DICOM query retrieve function. The PACS does not know, among other things, which user is performing the query action on the other system. Restrict use of the DICOM query/retrieve function to systems for which you have access control. With DICOM it is possible, however, to initiate the image transfer from a different system to the one on which the images stand or on which they have to end up. It is accordingly technically feasible to, for example, initiate that transfer from the HIS, in which you must nonetheless still ensure access control.

81

8.1.5

Viewing throughout the clinic

Clinical viewing means viewing images outside the imaging department, e.g. by the requestor of the (radiological) exam. In most systems, different software is offered than that used within the imaging department. The emphasis in this software for these more occasional users can then lie more on an intuitive user interface, on integrability with other components of the clinical workstations, or on greater economy in technological requirements. As a result, functions are omitted or simplified. Less attention can also be paid to matters such as the handling of calibrated imaging screens. You have to make the policy decision whether all the workstations will be equipped with the radiological software, or whether outside the imaging department only the clinical viewing software will be provided, or whether a combination of the two workstations will be used outside the imaging department. Of course, if you combine the two then the question arises whether you get the best or the worst of both worlds. What can play a part in this is that you must then integrate the two systems with the HIS and achieve access control (aspects that have a stronger emphasis outside the imaging department than they do within it). Specialized workstations such as, for example, those used for surgery planning remain outside the scope of this discussion whatever form they may take. Functionality, technology and conditions for interactive study of images There is less experience with the use of digital viewing by heterogeneous groups of clinical users. For that reason you should certainly involve different representative users in the assessment of possible systems right from the outside of the project (see p. 69). We would however like to point out that dynamic navigation through a series of images using the new imaging techniques is gaining in importance. There is no analogy for this in film-based working, so clinical users most probably have less experience with this. It is usual to regularly calibrate the imaging screens within the Radiology department. That is difficult to organize throughout the entire institution, certainly when these imaging screens are not specially designed for this purpose, when they also have to serve for presentation of data other than images, and when the precise adjustment cannot be firmly achieved. Most probably the ambient light also is not always the same, if only because the users need more light for their other tasks, whereas examining the details of images generally requires a darker environment. 82

Selection of exams, worklists In a clinical department, an imaging exam is approached from the perspective of the whole patient file. It is for this reason among others that in commercially available systems also the opportunity to select images from the primary user interface of the overarching information system is increasingly common (section 8.2.2, p. 86). Bookmarking of images and annotations on images In the film-based system, clinical users often use their own summary of the images, e.g. by making annotations on the film. So, for example, to follow the course of tumour therapy a reference slice can be designated that you will want to find again quickly when you compare a new exam later. Discuss with the supplier of the PACS the possibilities for indexing (or annotating) images or parts of images and how such selections or indications can be managed. Decide on a policy for making or changing annotations and check whether the PACS can support this. It should not be possible for users outside the diagnostic department to change annotations made by people inside the department. Access control Detailed access control is even more important outside the imaging department than within it. That can also be a reason for allowing the imaging exams to be invoked in the overarching information system (section 8.2.2, p. 86).

8.2 Integration of PACS into the whole IT solution

Due to the hi-tech character of a PACS, you will develop the temptation all the more quickly to concentrate on the technical aspects. Even so, integration into the whole IT solution is essential. A stand-alone PACS cannot meet expectations.

8.2.1

Back-office integration of PACS into the overarching information system

The term back-office integration is used here because we are dealing with a form of information exchange between computer systems that is separate from and largely invisible to the interactive user. This is not a standardized term.

83

H IS /R IS

E xam sched uling info P atient info

PA C S

Info fo r P A C S user

Illustration 8 : The HIS must send information to the PACS. Some information is required so that the PACS can manage the imaging exams in a meaningful way (in the global context) or can control automatic systems. Other information is primarily intended for organizing the user interface on the imaging workstations

84

Sending administrative and logistical information to the PACS The PACS must obtain information from the HIS/RIS about the patients who are expected and the exams that have to be performed. All changes in patient data in the HIS/RIS and patient merges must be pushed through to the PACS. This must cover, as a minimum, the IDs of exams and patients (used in the HIS) and the name of the product. A fundamental reason is of course to be able to refer in the image management system to the same entities as those in the HIS (see p. 30). Another specific reason is so that the PACS can check whether the incoming imaging exams can really be allocated to a particular patient and linked to an exam in the overarching information system (more about this in sections 8.2.3 and 8.2.4). A possible further reason is to allow the PACS to control prefetching (p. 74) and prerouting (p. 75) 13. A frequently used method for this information exchange is communication of messages in the HL/7 standard. It can be an advantage if the PACS can handle several mechanisms for this exchange, since HL/7 is not the easiest protocol to implement (see p. 16). Sending reports to the PACS If you are examining diagnostic images, there is a good chance that you will also want to look at the report. That report will, however, be managed outside the PACS. You can opt for exchange of these reports between HIS and PACS, e.g. so that you can view previous reports from the viewing software. Of course, with this solution you have the usual problems of replication of data in two systems (see p. 22). An alternative is to supply a link at the level of the user interface (ultimately this is purely a matter of presentation), as described in section 8.2.2, p. 86. Make it a policy decision whether you want to exchange reports with the PACS (so that they can be retrieved from there). If you do supply such a link, make sure that the copy is always up-to-date. Forwarding task-supporting information to the PACS In the discussion of radiological viewing it was emphasized that ergonomic worklists are important (p. 79). If the imaging workstation is to be able to build up such lists it needs

13

Of course, use of this information for prefetching implies that you have to send this

information well in advance and that it must be available in the HIS well in advance. 85

information from external systems. The interactive user perhaps wants to obtain a list of exams requested by a certain doctor or by a specific unit, or of exams for which a report has still yet to be made 14 An initial question that arises in this connection is whether the PACS can actually use the information you want. The second question is how you will forward this information (as well as any changes in it). Check what information is required in the user interface (worklists, search engines) of the workstations that is not already present in the PACS. That means that you must analyze in detail the process of working with images. When defining the workflow, take into account that there can be a delay in sending this information. Check whether the PACS has mechanisms for accepting and using this information (this is not standardized). A reasonably useful form of information communication is also that of the request and the clinical querying of the diagnostic workstation, through which the radiologist can do most of his work from that workstation without having to switch over to other information systems.

8.2.2

Front-office integration of PACS in an overarching user interface

By the term front-office integration we mean integration at the level of the user interface, so that the user at least gets the impression of interacting with one single overarching information system. In the context of PACS that is certainly relevant for the clinicians, since for them images are only one part of the available information (perhaps a technologically heavy part, but one of only limited importance). An initial advantage for integration in the user interface is simple ergonomics because the patient and/or exam does not have to be searched for again in a different application. A second advantage of front end is apparent from the discussion in the previous section. Much of the information that you communicate back end serves ultimately just for user interaction in the other system (presentation of reports, sorting of worklists per unit, etc.). Often it is technically simpler instead to have the user interface function performed by the system that immediately has all the data. A third advantage is that you can impose a consistent policy. At different places in this chapter, for example, access control was mentioned. If the imaging exams can only be

14

This last information can sometimes also be indicated in the image working station

However, in many organisations i t is surer that the report comes directly from the system where it has been produced. 86

invoked in the HIS (and if the viewer of the PACS is accordingly controlled by that HIS) all the access control can be performed centrally in the HIS.

HIS/RIS

Exam scheduling info Patient info

PACS

This is any result or

Illustration 9 : In this example images are being invoked from the user interface of the clinical workstation. In this arrangement you automatically have the familiar context and selection mechanisms, and a part of the information exchange from Illustration 8 becomes unnecessary.

The primary system for selection The question arises which system should be the primary system for selecting information from worklists. Given the limited experience with front-office integration a pragmatic look should also be taken at the available possibilities. For clinical viewing it is clear that the user interface of the general patient file is the most suitable starting-point. That system has most of the relevant context to be able to supply powerful search mechanisms or to present worklists (e.g. of patients who are allocated to this user, who are present at a certain department or for whom a consultation has been scheduled). That system also has the context for access control. Regarding use within the radiology department it can be stated that the pure availability of images controls much of the workflow and that the worklists are optimized to the specific task of working with images. The radiologist would then be able to select the exam on the workstation, after which the HIS/RIS would present the clinical and other information and offer support for the input of the report. At the start of the PACS project, decide what integration at the level of the user interface you are striving for (since that leads to a shift in the efforts required for development). You should therefore decide what the primary system is for the selection of patient and exam.

87

Available techniques The HL/7 consortium is working on the CCOW standard for this kind of visual integration of IT applications (see section 2.6.2 p. 28). It is too early to speak of a fully mature standard and the envisaged functionality is, all in all, still rather limited. While waiting for this standard, many PACS providers are providing facilities on an ad hoc basis which enable their systems to be controlled or, in consultation with other providers, are allowing these providers to control their systems (technologically it is indeed a simple matter to send an event to another application in one or other technology). Over the past few years remarkable progress has been made in the acceptance of the idea that the different applications of different suppliers must work together. Not too much however should (yet) be expected of the implementation. For example, if you can invoke the clinical viewer from outside the application with the instruction to immediately display an imaging exam but you have to restart this viewer to display a different exam, then you lose a great deal in terms of ergonomics. When you use a context synchronization (e.g. via CCOW) it will continue to be apparent to you that there are two different applications involved. The level of detail with which you can control the other application is also limited. The other extreme is that the supplier of one system supplies a software component that the supplier of the other system integrates into his own application, which makes a very tight application possible (see section 2.6.3 p. 29)15. Given the progress being made in component frameworks in general, it can be expected that this principle will be used to an increasing extent. If you are striving for integration of user interfaces between PACS and other systems, discuss the possibilities in detail with the suppliers concerned, since this is completely nonstandardized. Check whether the implemented integration is also compatible with complex navigation throughout the entire patient file. Other key issues The tightness of the visual integration can affect the desired refinement of control. You must be able to compare images, which demands smooth navigation through the imaging exams. The navigation mechanisms of the HIS have the advantage that they reflect the specific

15

Both imaging presentation and communication with the underlying archive are specialized

functions. The component in the user interface accordingly comes with its own underlying system. 88

organization and utilize the broader existing context. On the other hand, if the viewer is integrated in such a way that you have to go back for each navigation to a window in the HIS, it can ultimately be more convenient just to display on the viewer which patient the data relates to and to arrange for interactive navigation through the various exams of this patient within the viewer. The greater the extent to which use is made around the images of annotations, summaries, measurements and so on, the greater is the connection between these images and the information or context in the overarching information system. The management of these items can, of course, be made more powerful and also simpler by centralizing it in the HIS. Experience with this is still insufficient however.

8.2.3

Information exchange with the imaging devices

IDs in the forwarded DICOM dataset In the DICOM dataset that is sent to the PACS there is a field for the patient ID and a field for the ID with which the external information system refers to this imaging exam (accession number). These attributes are generally entered on the imaging device (which generates the DICOM message). Entering patient data on the device is also usual in film-based working. In the case of PACS however, it is essential that the IDs be entered with absolute accuracy. This cannot be guaranteed if the input is performed by manual typing. Wherever possible, avoid a situation where patient and exam ID have to be entered on the imaging device; instead make sure that these are taken over electronically from the overarching information system. Techniques The most commonly used method in radiological imaging is the sending of data on scheduled exams to the imaging device via the DICOM Modality Worklist function. The operator must then select the correct entry from this list. This DICOM communication can be performed directly from the HIS. The PACS can also however take upon itself the task of communicating with these devices. After all, the PACS obtains from the HIS information about scheduled exams (back-office integration, p. 83), so that the HIS only has to supply some additional data with which the PACS can decide which device to control. This task of control is not simple. So, for example, allowance must be 89

made for precisely when (which day) the exam is scheduled for. There are specialized interface engines on the market (see p. 21) that can handle the traffic between HIS, PACS and imaging devices, and which can control a list of non-DICOM-compatible devices. If you want to connect an imaging device to the PACS and you still do not have any clear idea of the best method of viewing IDs automatically on that device, then check immediately whether the DICOM Modality Worklist function can be used. Do not however automatically exclude other options, e.g. direct control of that device from the selection in the HIS/RIS, which can be more convenient when you are performing lots of short exams (which makes selection from a long list onerous) and the operator for the general organization still has to indicate in the HIS/RIS that you are busy with a particular exam.

P atient & exam ID s P atient & exam ID s P atient & exam ID s P roced ure typ e S ched uling i nfo

H IS /R IS

PA C S

Illustration 10 : It is essential that the imaging devices take the external IDs for the patient and exam from the global information system electronically, so that these can be correctly entered in the generated DICOM datasets. In this example, the PACS is making worklists for most modalities on the basis of information from the HIS, while another device is controlled directly from the HIS (in practice from the RIS).

Additional key issues In the Modality Worklist it is the imaging device that retrieves a new worklist, e.g. for a couple of minutes. A certain time-lag must therefore be allowed for between input into the HIS/RIS and availability of the data on the device. Make sure that the exam in the HIS is created BEFORE the imaging exam is begun. (The exam relates to the object to which the imaging exam is linked.) 90

It is certainly true that when exams can be performed on different devices and the data has been sent to all these devices you arrive at long worklists which become impractical. The worklist on the device must also be cleansed again. This cannot always be done automatically (you want to be able, for example, to include another image). The imaging device can, if desired, present only worklists that have been scheduled for today, but that again assumes that the date on that device is correct and that any postponement in exams is actually entered into the information system. Of course, manual input must continue to be possible, e.g. to be able to start operations with the imaging device if the information in the overarching system is not available (in time).

8.2.4

Correction of errors in the PACS

Because the PACS knows which exams to expect (p. 85) it can check whether the incoming DICOM datasets contain the correct IDs of patient and/or exam. In some cases in which manual input was required here could still be inconsistencies. It is necessary to be able to view these imaging exams for emergency cases (within the imaging department), but they cannot be utilized throughout the entire hospital. Make sure that errors in identification of the exams can be rapidly correctly manually (even during night and weekend shifts). Make sure that errors are reported as close as possible to the place where they arise. Correction post facto by persons who have not actually performed the exam requires thorough knowledge of the organization and of imaging! You should arrange for a stricter discipline among the operators than in the film-based situation. A bad mistake is, for example, to select from the modality worklist of another exam scheduled for the same patient. Provide feedback mechanisms to draw the operators attention to faults, which means among other things that the radiologists must report incorrect identifications.

91

IDs
DICOM data set

IDs

HIS/RIS

IDs

PACS

This is any result or

Manual correction

Illustration 11 : The information exchanges between HIS, PACS and imaging devices described in the previous sections allow the PACS to perform any check on incoming imaging exams. In the absence of these mechanisms manual corrections are, however, required

92

9 Telematics
Telematics deals with the support, by means of information technology, of operations in which quite a long distance is involved. Distance here can mean:

Physical distance, through which (1) limitations of communications technology play a part and (2) security based on physical barriers is absent.

The fact that the information exchange is extending outside your own hospital, which means that you (1) have no influence over the systems and working methods on the other side and (2) have to work without the general information context that you normally have within your own working environment.

The most important key issues in telematics derive from that second point. If physical distance is the only factor involved then it is known as teleworking. where you communicate with people outside your own hospital. In this chapter we will first focus extra attention on the aspects of security that become especially important in telematics. We will then discuss a few techniques of information exchange in which this information is not present in a medical file on both sides. Finally, some possibilities and key issues in tele-information exchange are discussed in the context of the medical file. We will not be discussing teleworking in this text, except to mention a few differences with the situation

9.1 Security in telematics

Key security issues have already been mentioned in chapter 6 (p. 50). In this section we revisit those aspects that are especially important when using telematics and also discuss some aspects based on this specific application. The key issues that have already been mentioned in these other chapters are not explicitly revisited here.

9.1.1

Defining responsibilities

An important element of security is the investing of responsibility in the user, with the related possibility of imposing sanctions. If you are making sensitive information or services available to outsiders via telematics then you must ensure that these users are also advised of their duties and show a sense of responsibility. At the same time, however, responsibilities must also be formulated in more general terms. 93

Conclude legal agreements on security and responsibilities with external parties. There is also a relationship between the hospital and the patient. Perhaps the patient would prefer it if his or her data was not passed on to the information systems of other care providers. Since the use of telematics is a new factor in this field, many situations are not covered by the general regulations. Check whether the patients informed consent is required for the electronic communication of patient data.

9.1.2

Securing of communications

One form of illegitimate access to data is eavesdropping on communications. In a local network that risk is limited because the hacker must be physically located within the infrastructure. In telematic networks the risk is enormous, not only because of the longer and less closely monitored physical path to the partner, but also because the nodes in that external network are, per se, accessible from somewhere else. The Internet is especially vulnerable here. The message can be sent via (and often even be retained at) nodes that are managed by organizations that do not have the opportunity to pursue a security policy and which cannot be held responsible for intrusions by third parties. There is no formal confidentiality of mails on the Internet. On the other hand, the Internet is organizationally a fruitful medium for cooperation between health workers of all kinds (see section 9.3.2.2, p. 105). The way in which this aspect is dealt with is encryption, which is best used through all the communications (see p.58). Techniques are available for checking whether the message has been (deliberately) changed during communication and whether the message did actually come from your communication partner (see p. 59).

9.1.3

Authentication of users

In telematics, a person need not be physically close to the system to try to retrieve information, which simplifies intrusion.16.

16

An additional problem with this is that someone can try to break into the system for fun

while it would not be considered fun to start physically stealing the data. 94

If a wide group of users over which you have no control has access to a service (such as a Web site) then someone who hacks into the computers that provide this service still cannot access the computer systems in the hospital that contain sensitive information or from which sensitive operations can be performed (see section 6.12). If you have to give an external user access to sensitive information then strong authentication methods are required (see p. 50). This means that you must always conclude prior agreements with this user and must exchange hardware or keys.

9.1.4

Confinement of business logic to the client software

Even if you are sure of the reliability of the person who is requesting access, there is a risk that the workstation with which this person obtains access has been infiltrated. After all, you do not have the same control over this workstation as over those within your own hospital. As a result, you cannot rely on any restriction that you yourself have implemented in the software that you have supplied to this person. Assume, for example, that this software opens a connection to the database and performs a number of secure queries. A hacker can try to put this connection to the database to illicit use. According to the same reasoning you cannot rely on any form of access control that was implemented in this application. You also cannot be sure that the business logic in this application is being correctly performed and is therefore keeping your internal systems consistent. The software at the clients should not contain any functions that can be circumvented, such as access control or important business logic. The software on the server should not assume that queries or retrievals of services by the telesoftware are well behaved.

One more secure method is to concentrate all such queries, access control and business logic in components within the hospital (in a middle tier) from which only certain methods are made available to the tele-applications (see Illustration 4 p. 12)17. Even then these internal

17

One possible drawback to the heavy implementation of this principle is a slower response

for user actions that require strong interaction between the user interface and the business logic. That argument plays less of a role in applications that are explicitly intended for use outside the hospital in which a simpler user interface is most probably being aimed for. 95

components must make allowance for parameter tampering, but the more restricted the set of methods that can be resorted to the easier it is to guard against this. A second more secure method is to have only the graphical user interface running on the workstation and to have the actual application on the servers of the hospital by using techniques involving terminal servers (popular in Windows environments) or display servers (as encountered in the use of, for example, X-Windows). An advantage of this is that existing applications can be immediately deployed. On the other hand it can be undesirable to allow people from outside the hospital to automatically use the same application as internal staff, simply because they can commit too many erroneous actions due to unfamiliarity with the system. This solution is therefore more suitable for teleworking.

9.1.5

Detailed access rules and external doctors

Detailed access control is based on information in the computer system about the doctorpatient relationship. Such information is available to a much lesser extent to external doctors (this external doctor is most probably not attached to a specific department of the hospital, has perhaps not had any medical contacts with the patient noted in the file, etc.). Take into account that the existing access rules for medical data can demand information about the external doctor that is not available in the internal system, so that you have to implement other rules.

9.2 Technology for tele-interaction between persons

There are a few reasonably standardized methods in which the aim is to enable people to cooperate without them having to travel. key issues. In information exchange via video conferencing, data conferencing, e-mail, etc., this information is not integrated into an information system at the communications partner. Do not therefore regard this as a way of exchanging information between medical files. It is not our intention to issue strong recommendations and certainly not to lay down quality criteria, but we will mention a few

96

Organization 1

Organization 2

Record 1

Record 2

Other healthcare actor

Local record

Illustration 12 : In the techniques of telecooperation discussed in this section there is interaction between people but no information exchange between the medical files. In the best-case scenario the people use information from their own file in the conversation or they show it to their communications partner.

9.2.1

Video conferencingLevel of expectations

The quality of visual information in video conferencing is on the low side. The idea is to create a meeting experience, not to transfer subtle points of detail. The usual standards are based on the CIF resolution of 352x288 pixels, which is about half the resolution of TV in both directions (which is itself already much less than on a computer screen). If there is sufficient bandwidth and processing speed then the movements are less jerky but the resolution remains limited. Do not use conventional video conferencing techniques as a way of discussing images or text in high quality. To discuss documents in detail at a distance, data conferencing is preferred (section 9.2.2, p. 98). Of course, if the quality is not particularly important and the material is only required to illustrate the discussion it can be sufficient to hold it up in front of the camera or to switch to a separate document camera. If it is primarily the meeting experience that is important then make sure that there is adequate sound quality, if necessary at the expense of image quality. It is more annoying if you cannot understand the other side properly than if the image falters now and again. One aspect of this is the occurrence of echoes, which can demand facilities for echo cancellation.

97

Required network capacity In video conferencing the delay in communications is relevant and you need a guaranteed bandwidth. For this reason the use of ISDN is popular, since a guaranteed bandwidth is combined with almost universal availability. The bandwidth of ISDN, however, is low. In the existing compression techniques, different ISDN lines are often used in parallel. bandwidth, but that has to be discussed on a case-by-case basis. Video conferencing using the IP protocol, e.g. over the Internet, is attractive because of its flexibility. There are separate standards for it. At the moment however you cannot obtain guaranteed bandwidth over the public Internet. If you do want to make use of it you have to conclude agreements with the all the providers of Internet communications. The above requirements for bandwidth assume that communications will be set up between two locations. If more than two locations are involved then additional communications can be set up in pairs, or one node can be made responsible for the control after which a composite signal is sent (with high bandwidth and specialized equipment and operation at that node). The provider of the telecommunications channels can also offer that as an additional service. Organization The directing of the sound and image is not automatic. For meetings involving several people (certainly if documents have to be shown on screen now and again) of for transmissions in which the quality of the moving images is important (image composition, zooming in, light reflections, etc.) it can be necessary to have someone knowledgeable operating the camera(s). If the quality of the video-conferencing is important, consider whether investment in proper operation of the equipment is not more sensible that additional investment in equipment. Most telecommunication providers can supply synchronous connections with a higher guaranteed

9.2.2

Data conferencing

If the data is available in digital form on the workstation of one of the participants, this data can be made visible with the same quality on the workstation on the other side of the communications.

98

In an electronic whiteboard a window is visible on all the connected workstations on which each of the participants can place information from the local environment. the discussion. In Application sharing the user interface of a program that is running on one workstation is also visible on the other connected workstation(s). If necessary the control of that program (mouse and keyboard) can be handed over to another participant. For this reason it also sometimes known as a shared desktop. In a whiteboard you can only introduce standardized media. It does not, for example, directly accept a radiological image series in DICOM. contrast interactively), application sharing is necessary. For the more basic applications it is sufficient to have a significantly lower bandwidth than that required for video conferencing. For interaction on a series of images as mentioned in the previous section a high bandwidth can indeed be a requirement. In the world of teleradiology, specialized applications that can circumvent these limitations are already being used18, but each partner in the communication must then use the same specialized software. If you want to perform complex interactions of high quality on a large series of images (typically for radiology applications, and then primarily for primary diagnosis) you must weigh up the use of standardized applications that demand a large bandwidth against the use of specifically radiological solutions. In order to realize interactive navigation through such an image series (running through dozens of images, adjusting the All the participants can, among other things, make annotations on the information introduced into

9.2.3

Delayed time interaction by exchanging files

The real time aspect of the above techniques means that everyone must be present at the same time. For many applications the most efficient procedure is still the sending of data after which the addressee studies this asynchronously.

18

In the standard application, each interactive adaptation of the image presentation demands

that a new screen image be sent. For this specific application you can only send the images once; from that point on you can only send commands to change its presentation. 99

Only use telematic technology in which people have to be present at the same time, albeit at different places, if real time interaction is genuinely required. Any type of file can be sent via e-mail, but because the message has to be stored on intervening computers the total length of the message is restricted. To send large messages (e.g. sets of images), the use of a server on which one party places it and the other retrieves it is generally more viable than e-mail. In addition to making arrangements for security (including between users mutually) you must also set up an organization to prepare, cleanse, etc. the data on this server. It is becoming increasingly common to provide access to this server via a Web interface, which not only allows you to provide a specific user interface but also offers possibilities for realizing extra management of the data. The communications partner must have the software to read the data. Check whether important meta-information or organizational information on the various information items can also be displayed. That seems obvious. But with complex data types, e.g. series of radiological images, it is not so straightforward. Perhaps the viewer of your communications partner can see these images but the positions are not stated in millimetres even though you used mm as the basis for calculation in a related report, and so on (see also section 9.3.2, p. 103).

9.3 Telelinking of and telelinking to medical files

We will only discuss situations in which there is communication between independent health care workers (hospitals or doctors for the purposes of this text). If, on the other hand, different hospitals merge and decide to construct a common file, the integration techniques discussed in chapter 2 are applicable, in which only the technology for the communications differs (and, as regards security, a VPN is recommended). A few characteristics of this situation and the innate limitations are therefore:

The structure of the medical files is and remains different. In practice there is, after all, no standard for that file. There is not even a standardized way of working and in many cases not even one standardized set of concepts.

You have only a limited influence over the technology at your communications partners.

100

It is therefore a priori unrealistic to expect a strong integration between the various systems. The connections will be loose with limited workflow support.

9.3.1

Exchange of information between independent medical files

In this situation information is copied from one file to the other. The information is then independently managed at the two locations.
Org a ni z a tio n 1 Org a ni z a tio n 2

Record 1

Record 2

Othe r he a lth c a r e a c to r

L o c al re c o rd

Illustration 13: Exchange of information between medical files, in which the different doctors each interact with their own file. There is primarily interaction with the local files, while the information exchange between these files mutually is limited.

9.3.1.1

ORGANIZATIONAL CHALLENGES

An initial problem is that a commonly accepted meaning must be agreed for the data that is being exchanged. It is, of course, acceptable to consider the entire text of a radiological report as one item, but appointments, admission reports, statements of problems, etc. must contain additional structured information if a computer system is to be able to take action on them. In most cases therefore only a largest common divisor of information can be exchanged in a structured manner. A second problem is that a common context for this data must be defined and coded:

101

This context contains, at its very least, the patient. That assumes that the same patient identification is used in both files or that an automatic translation is possible (see section 3.1.1, p. 30).

In most cases more context is required. A radiological result refers to a certain type of exam, to a request accompanied by clinical questions, etc. Here also only a largest common divisor of items will remain with, in the description, a lower level of detail than is usual in both files.

A third problem is the depiction of the structure of the transmitting file on that of the message and therefore on that of the receiving information system. In the case of that receiving system allowance must perhaps be made for the fact that information that comes from outside does not have the same references as internal information. An external radiological report, for example, does not perhaps have a requestor in the internal system, or perhaps a patient who has not yet been registered in the internal system must first be created and use must also be made for this purpose of the limited information available in the transmitted message. A statement like we will exchange files must be translated into a statement of exactly which information items, with a specific meaning, will be exchanged. That means that a model must be made of the information in both systems and in the message and that these models must be mirror images. That requires decisions to be made about the level of detail or structure in this exchange and perhaps requires adjustments to be made to the organization of the receiving system.

9.3.1.2

ARCHITECTURE AND TECHNOLOGY FOR COMMUNICATIONS

For communications between two hospitals, direct transmission from sender to receiver is suitable19. When transmitting to computer systems in private practices, which are less suited to acting as a server, a more convenient architecture is one in which messages are sent to a central node which buffers them until the other system comes to fetch them on its own initiative.

19

In this section we are assuming that the receiver may not retrieve information on his own

initiative, if only because that demands a closer harmonization with the business processes at the senders end (see following sections) 102

The technical options for data exchange and the key issues described in section 2.4 (p. 16) remain valid. Recent developments in communications technology in the sphere of the WWW offer obvious potential for establishing the loose connection between different systems in a telematics settings20. Some concepts are XML (for the structured coding of the data), SOAP (for the sending of messages of this kind), and Web services for logging on to services remotely. Take into account that when using communication resources in the sphere of XML there is still as great a need to conclude precise agreements about the meaning of the information items being exchanged. If you want to use this technology for information exchange between files, we suggest (if you are looking for a suitable approach, both technically and content-wise) that you refer to Recommendation 4 of the Belgian Committee on Standards for Telematics for the health care sector (Data working group)21.

9.3.2

Interactive tele-access to the file within a hospital

Pretty much the opposite to the approach to data exchange discussed in the previous section is to give the external doctor remote interactive access to the file of your hospital. In this case there is no interaction with the local file of this doctor. The links between the context in the two files are only created mentally. In contrast to the previous technique, this doctor is confronted with the differences in organization of the two files. Against that drawback there stands the fact that all the available information from the central file is presented, within a robust structure, without any compromises having to be made in terms of translation of this information to a local file. This can also include information that is only relevant in that central file and which it does not make sense to store

20

The concepts are carefully thought out, there is a strong standardization, and (thanks to the

wide distribution of this technology) efficient development tools are available and there is a good chance that allowance will be made for the implementation of all kinds of products such as firewall security
21

http://www.health/fgov.be/telematics/cnst/fr/an.htm 103

in another file (e.g. contacts for nursing staff), information that changes rapidly (e.g. the patients location), information where local storage is technically questionable (e.g. large series of images), or information that is so specific that it is difficult to provide a viewer for it locally. The lack of integration between the files of the external doctor and the hospital makes automatic workflow between these systems impossible. On the other hand, any interactive control of the workflow in the hospital by the external doctor is relatively simple to achieve.

Organization 1

Organization 2

Record 1

Record 2

Other healthcare actor

Local record

Illustration 14 : Tele-interaction of external doctors with the file of a hospital. There is no direct link between the various files, but each doctor has a strong interaction with the various separate files

9.3.2.1

ORGANIZATIONAL CHALLENGES

In this way of working, the internal processes of the hospital are actually opened up to the external doctor, who at least obtains a view of these processes and perhaps has some influence over them. If you want to make information and business processes accessible from outside the hospital, you must in the first instance ensure that they are available within the hospital. The external doctor cannot be assumed to be familiar with all the details of the internal processes. A simplification of the procedures relating to the outside world is therefore often sensible also (e.g. in connection with the booking of appointments).

104

A special problem in this context is data and functions that are divided over different systems. Internal users may have learned how to cope with this tangle, but for an outsider the resulting complexity probably cancels out the benefits of tele-access. So that a file can be made available to the outside world in a meaningful way, the data and procedures must already be strongly integrated into it. From the perspective of the file, a context is required for the user, e.g. to determine what accesses this user has. The available context for external doctors is significantly smaller than for the internal users. Separate rules will probably have to be implemented, both for access (see section 9.1.5, p.96) and for the support of some parts of the workflow.

9.3.2.2

TECHNOLOGY FOR INTERACTIVE TELE-ACCESS

External users need a different user interface to internal users. The internal application probably contains functions that the external user does not need, demands knowledge of details of the organization in the hospital, and is vulnerable to incorrect use in the absence of this knowledge. Try, in so far as no performance limitations are created in the process, to group components for business logic in a middle tier and to invoke the same components from the internal front-end and the external front-end applications. One advantage is the opportunity for stronger security (section 9.1.4, p. 95). A second advantage is re-use of development and maintenance. If the aim is to grant access to a large group of external parties, you can impose in the software for the client relatively few barriers to the underlying operating system or the available communication channels. As regards communications, connection via the Internet is an advantage in this case. It does not matter in what physical way or via which provider (ISP) the external doctor and the hospital are connected to the Internet. Avoid a situation where the hospital has to support different principles of communication (different types of modems for example). As regards the application, software that is based on the exchange of standardized HTML pages or which is written in Java is an advantage here, due to the reasonable independence of the operating system of the users workstation. Scripting languages within a browser are inclined to be dependent on the browser or even on the version of the browser. Remember that the form-based principle of HTML/HTTP lends itself to the building of intuitive user

105

interfaces, but that the degree of interaction with the system in that principle is rather restricted. In the technical design, bear in mind the need for maintenance on the users system. Ensure a technically clear separation of responsibilities in the making of settings for connection. Avoid a situation where your application has to be installed on the local system, and if that is unavoidably necessary ensure that there are automatic update procedures via the Web. In this setting, centralized maintenance of the users systems is very expensive, due to the travelling required, the fact that the configurations are very heterogeneous, and the fact that you cannot or do not want to exercise any influence over these configurations. It is precisely those methods that lower maintenance costs in hospitals that cannot be used in this instance. A fruitful technique is therefore the use of a Web browser. The external user can provide or arrange a fully independent connection to the Internet and this connection can be independently configured and tested.

9.3.3

The sharing of a central file between independent care providers

The working procedures described in the previous sections have drawbacks if more than just single hospitals are involved. Data exchange between more than two different files is of course more difficult and will run up against more limitations (see also section 2.2.1, p. 7). Visual access to the various central files becomes more onerous the more the information is spread over different such files and the more the user comes into contact with the differing organizations of all these files. One possibility is that the different people involved can agree that a separate file will be developed on neutral ground. For those operations where collaboration is the aim, that central file will be used as a means to that end. For other operations, everyone uses his own information system. This does of course require information exchange between the different internal systems and that central file.

106 Illustration 15 : An independent central file on neutral ground for cooperation between different hospitals and external doctors. In this illustration each hospital can place information in the central file.

Organization 1

Organization 2

Record 1

Record 2

Other healthcare actor

Central record
Local record

Organization managing central record

107

You can conceive this as a highly centralized results server (see section 2.5, p. 25). Due to the greater neutrality in comparison with the two previous solutions (linked to the even more limited structure of the information coupled with it), it is conceivable that the information will not be consulted purely visually but will also be actively queried by local software. A variant is to manage not the results themselves but references to the results in separate files.. There are initiatives underway in which the patient himself manages a part of this data
22

9.3.3.1

TECHNICAL AND ORGANIZATIONAL CHALLENGES

Take into account that, when using a shared file between different independent hospitals, all problems relating to (1) data exchange between files and (2) tele-access to a file coalesce. Ultimately in this setting information will after all also be shared with another file (from each hospital to a central file). As is the case with a results server within a hospital communicating with the different departments, this configuration does not automatically provide a solution to the support of the workflow between the different hospitals in the network. Another problem is the management (and technical maintenance) of that additional central file.

22

In this case, it is of course naive to hope that there is a good structure on the data level. In

the ideal case, it is as if one could always send a paper file by fax. 108