From Communication Server to Information Server Simplifying ... - NCBI

From Communication Server to Information Server Simplifying the Concept Albrecht W. Zaiss, Ulrich Schrader, Stefan Buchele, Rudiger Klar Dept. of Med. Informatics, Hospital of the Albert-Ludwigs-University, Freiburg, Germany Freiburg university hospital has about 1,700 beds, over 50,000 inpatients, and about 300,000 outpatient visits per year. Typically the information infrastructure consists of independently coexisting legacy systems in the different departments. Most of them do not have standard interfaces like Health Level Seven (HL7). Often communication servers are used to connect to them and to generate the HL7 messages.

realised by a polling. Since all access to the data has to be by the information servers, the security policy of the institution2 and any changes to it can be be implemented centrally on this server.

EXPERIENCES

Besides a patient data server as part of the administration system, a results and report server (RRS) is implemented as an information server to integrate the laboratory systems, pathology, department systems, etc. Both are used in daily routine. Every client or department system uses HL7 queries to access them. The RRS has been developed using an ADABAS C database running on a SUN SPARC 20 Twin Processor (280 MB RAM, 30 GB hard disk) connected to the FDDI backbone of the hospital. The RRS has stored more than 80,000 pathology reports and about 15 million lab values increasing by 15,000 values per day. 15,300 unsolicited HL7 messages are sent from the laboratory, microbiology, and the pathology systems daily. The mean response time to a query is 5.1 q75% = 7s, (median = 4s, q25% = 3s, seconds max = 27s). Usually a HL7 query is quite complex like "give me all recent lab values from all labs for all patients on my ward". More result and report generating systems will be integrated in the RRS shortly.

COMMUNICATION SERVER The communication server acts as a message translator and stores incoming messages until the receiver is available. Since it is a message hub the number of interfaces required is greatly reduced. Often they will duplicate incoming messages to all systems that might be concerned. So the sending application does not have to know the organization1. The responsibilities for the information itself are still with the legacy systems. This creates a number of problems as will be shown. If the duplication of messages is based on a "to whom it may concern" method, then there has to be a possibility to query each system to get the information if need arises at a later time. Otherwise all incoming messages have to be duplicated to every system raising the network traffic. In Germany data privacy laws prohibit the transmission of unneeded data. If messages are send only to systems that have a need as determined by a time variant clinical context the communication server has to keep track of each message in order to forward updates correctly.

Using the concept of an information server we were able to integrate existing legacy information sources with very minimal requirements for the interface. It allowed for a centralized implementation of the security policy as defined by our hospital and the rather strict German data privacy laws.

INFORMATION SERVER To work around these problems we implemented an information server based on three principles: 1. for every data there is only one accessible system that always has the most current data; 2. data will be transmitted "on demand" rather then "to whom it may concern"; 3. redundant storage of data is possible but not encouraged. The information sources transmit upon availability to the appropriate information server where they are stored. Any requests by systems other than the sources themselves are fulfilled by the information server. There will be no unsolicited transmission of data to any information sink. So the information server acts as an information hub. The drawback of this restriction is that alerting has to be

1091-8280/98/$5.00 C 1998 AMIA, Inc.

References 1. Simonic KM., Gell GA General Approach to the Strategy of Integrating Healthcare Applications using HL7. in: Lun KC et.al., Editors. MEDINFO 92. Elsevier Science Publishers B. V., 1992: 1432-6. 2. Schrader U, et. al.. Critical Success Factors for a Hospital-wide PACS. in: Masys DR, Editor. The Emergence of "Internetable" Health Care - Systems that Really Work. JAMIA - Journal of the American Medical Informatics Association, 1997: 439-43.

1105