Recommendations and quality criteria for hospital information systems

Transcription

1 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

2 Contents 1 INTRODUCTION ARCHITECTURE AND INTEGRATION OF THE HIS INTRODUCTION DEFINITIONS Connected systems Integrated systems SPLITTING OF THE HIS: CONTENT OPTIONS Splitting by user group Splitting by department TECHNICAL OPTIONS FOR DATA EXCHANGE Syntax and standards for data exchange Operational security of the connection Central node Data replication: content options RESULTS SERVER Implications for access control COMPONENT INTEGRATION Back-end components Front-end components Cooperating applications as an alternative to front-end components CCOW CONTENT-RELATED STRUCTURE DATA ORGANIZATION Patient number Codings Structuring FUNCTIONALITY Appointments management Results management Request and registration system Medication prescription and administration Patient movements Invoicing Problem list and progress notes AVAILABILITY OF THE COMPUTER SYSTEM CAUSES OF UNAVAILABILITY TECHNIQUES TO LIMIT UNAVAILABILITY Backup Hardware redundancy Maintenance contacts Cluster i

3 4.2.5 Replication server Equipping of computer rooms UPS, emergency power for infrastructure outside the computer rooms REDUNDANCY CRITERIA FOR A HOSPITAL ARCHIVING PHYSICAL PROBLEMS LOGICAL PROBLEMS SECURITY ACCESS CONTROL AUTHENTICATION Basic techniques Discipline in authentication What authentication techniques should be used for an HIS? Individual names AUTHORIZATION MANAGEMENT OF USERS AUTOMATIC BLOCKING OF A SESSION IN THE CASE OF INACTIVITY AUDITING ENCRYPTION AND DIGITAL SIGNATURE Symmetric encryption algorithms Public-private key algorithms Certificates Hashing techniques VIRUSES, WORMS AND TROJANS PHYSICAL ACCESS TO COMPUTER SYSTEMS THEFT OF LAPTOPS ACCESS FOR HARDWARE SUPPORT INTERNET ACCESS VIRTUAL PRIVATE NETWORKS ACCESS CONTROL AT APPLICATION LEVEL Authentication Authorization Audit KEY ISSUES IN PROJECT MANAGEMENT PACS PICTURE ARCHIVING AND COMMUNICATION SYSTEMS INDIVIDUAL ASPECTS OF A PACS Archiving of images Distribution of radiological images throughout the hospital network Connecting the imaging devices Viewing for primary diagnosis Viewing throughout the clinic INTEGRATION OF PACS INTO THE WHOLE IT SOLUTION Back-office integration of PACS into the overarching information system ii

4 8.2.2 Front-office integration of PACS in an overarching user interface Information exchange with the imaging devices Correction of errors in the PACS TELEMATICS SECURITY IN TELEMATICS Defining responsibilities Securing of communications Authentication of users Confinement of business logic to the client software Detailed access rules and external doctors TECHNOLOGY FOR TELE-INTERACTION BETWEEN PERSONS Video conferencinglevel of expectations Data conferencing Delayed time interaction by exchanging files TELELINKING OF AND TELELINKING TO MEDICAL FILES Exchange of information between independent medical files Interactive tele-access to the file within a hospital The sharing of a central file between independent care providers iii

5 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 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

6 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. 5

7 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 patient s 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 6

8 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 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. 7

9 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. B s 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 Pharma Data connection Ad hoc protocol, HL/7 connection or other. Illustration 1:Ad hoc connected systems 8

10 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 other s 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 9

11 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

12 Application du dossier médical Admission Sortie Transfert de patients ID pat. Planificateur de rendezvous Info ID Système RX Serveur de rendez-vous BD admin. patients Système 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

13 Application 1 Wireless Application 2 Application Implemented on "application servers" type J2EE,.NET or servlets. Several middle-tier servers possible. Middle tier Middle tier RX request RX reporting Appointments 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

14 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 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 Cardiology Abdominal surgery Dermatology Anaesthesiology Medical file 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

15 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) 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 Cardiology Abdominal surgery Dermatology Anaesthesiology File Package A File Package B File Package C 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

16 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 patient s 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 Cardiology Abdominal surgery Dermatology Anaesthesiology File Package A File Package B File Package C 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

17 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 Syntax and standards for data exchange HL/7 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

18 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

19 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 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 recipient s end then the transfer process can send the already transferred data to the recipient s 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 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

20 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) 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 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

21 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 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

22 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 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

23 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 A s 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

24 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: technically, there is no way of preventing the recipient from 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: 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 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

25 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 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

26 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 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

27 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

28 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 organization s 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

29 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 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 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