A DATA MANAGER for the health information system Berlin

Computer Programs in Biomedicine 6 (1976) 166-170 © North-Holland Publishing Company

A DATA MANAGER

FOR THE HEALTH INFORMATION

SYSTEM BERLIN

K. APPEL 4, M. JAINZ 3, T. RISCH 5 , K. SAUTER 2 and W. SCHNEIDER 4 in collaboration with W. SCHOLZ l , G. GRIESSER 3 and V. KASTNER 6 Edited by M. JAINZ and T. RISCH 1 Ministry o f Health and Environmental Control, Berlin; 2 Department o f Biometrics and Medical Information Science, Medical School, Hannover; 3 Department o f Medical Statistics and Documentation, University of Kiel, GFR; 4 Uppsala University Data Center, Uppsala and s Datalogilaboratoriet, Department o f Computer Science, University of Uppsala, Uppsala, Sweden; 6 Medical Information Center, Berlin-DOMINIG L GFR

The needs for permanently changing the logical and physical structure of a medical database during the development of a health information system have initiated the project of implementing a DATA MANAGER. The concept of the DATA MANAGER covers facilities for the development of the logical data structure model including documentation of the model and programming support for application programs accessing the health information system (HIS) database. The outstanding facilities of the INTERLISP system have been found to be appropriate for writing the DATA MANAGER. A first data structure model, on which the DATA MANAGER will operate, is roughly outlined. Database Description Data Manipulation

Data Manager Health Information System

1. introduction The planning of automation in the health services in Berlin comprises the development of a health information system (HIS). A part of this work is performed through a specific project, DOMINIG I, which is sponsored by the government of the Federal Republic of Germany (Ministry of Research and Technology). HIS contains among other parts a central index (ZEMAS) and, on a regional level, the historical part of the common database of the system [11 ]. Experiments with the development of medical information systems have shown that the dynamic changes in the medical requirements ask for a system, in which it is explicitly assumed that the database used by the information system is permanently changing in its logical and physical structure. The changes in the physical and logical structure may partly be taken care of by a commercially available database management system (IMS, DMS 1100, ADABAS, TOTAL, etc.). The application programs access desired data via the logical structure, which is stored in tables. Performance considerations are often not taken into account when dealing with these problems.

Meta Database

Program Generator

The development of a system as complex as in Berlin will cause changes in the logical data structure model, which - when using a database software - will require reloading of the structure tables as well as reorganization of the physical data sets. The simulation of search strategies and the study of representing and performing logical links in the database are such reasons for changes. The coding of application programs and their database substructures will heavily be affected by frequent changes in the logical structure, especially in the detailed contents of the segments (microstructure), as the database software does not keep information about the microstructure in the most cases. An additional important aspect is - at least during the development phase - the maintenance of a complete and clear documentation of the logical data structure model and its realization in physical storage.

2. Concept of the HIS data manager 2.1. Tasks

T h e aspects mentioned in section 1 lead to the de-

M. Jaintz and T. Risch (eds.), Health information system STRUCTURE •

DEFINITIONS

\

i

r °'TA l MANIPULATION REQUESTS

,/

167

eventually generate the data structure model during the development phase and to satisfy future needs. Different versions of the structure model could be held under different names. 2.1.4. Communication with the Data Definition Language (DDL) of the Data Base Management System (DBMS) in use will be handled by an interface package. 2.1.5. A capability for simulation of search strategies in the database. 2.1.6. A capability for estimation of the search times of the various database accesses. 2.2. HIS data manager program modules

PROGRAM (¢g

SPSS)

Fig. 1. HIS Data Manager and its relationship to database in use.

velopment of a data managing system. The system will help solving the following tasks. 2.1.1. It will provide for an automated documentation of the logical data structure model, and assist the system programmer with information about the most up to date version of that structure model. 2.1.2. In order to facilitate user programming the necessary accessing routines for the data manipulation language will be automatically generated. These routines will extract data from the database with specified conditions (selection rules). The resulting data may be printed out directly or submitted as input to other programs, for example some statistical program like the "Statistical Package for Social Sciences" (SPSS). These generated routines may allow for interaction with the user in answering specialized queries. 2.1.3. A simple updating capability to modify and

2.2.1. The S T R UCTURE B A S E module The MANAGER has its own description of the data structure model in a data base called the STRUCTURE BASE. The STRUCTURE BASE is more detailed and commented than the Data Definition Language used by the Data Base Management System. A second structure model, which does not match the structure model of the real database, may be kept in the STRUCTURE BASE. The second structure model could serve two different purposes. Firstly the MANAGER could perform a mapping between the two models. Thus one can study changes in the structure model without changing the database. For example in an application of the system to some medical database it is possible to study the STRUCTURE MODEL by using a medical database in a different place. Secondly a second model of an imaginary database can be used as input to performance studies, e.g. by simulation, as an aid to improving the original database structure. 2.2.2. The P R I N T O U T module The content of the STRUCTURE BASE is automatically printable and thus serves directly as documentation of the database. It is possible to instruct the system to print only those parts of the STRUCTURE BASE that are of interest for the user. 2.2.3. The I N I T I A L I Z A T I O N module The STRUCTURE BASE is interactively initialized,

M.Jaintz and T. Risch (eds.), Health information system

168

field. Furthermore all editor commands are "undoable", making it possible for the user to "regret" and nullify previous changes.

~~ iA~TERMN I AL

~

ATAM A N I P U L A T I O N REOUESTS

REQUESTST O / STRUCTURE/ BASE /

REQUESTSTO PHYSICAL DATABASE

/

REQUESTPACKAGE

GENERATOR

J GENERATO IN PACKAGE

t

V

DATADEFINITION I LANGUAGE STATEMENTS PRINTOUTDE STRUCTURE

DATA BASE ACCESSSOURCECODE i I

I

r ,_ . . . .

' ' i

~ . . . . . . . . . . . . . . .

D

B

M

~'_ . . . . .

S

,

I

i. . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 2. Details of the HIS Data Manager.

using a program prompting the user for names of records, fields, links, comments, sizes, etc. in the STRUCTURE BASE. The initialization program will also keep track of loose branches of the STRUCTURE BASE in construction so that no logical links are missing when the program is terminated. This program module makes it easier to create new databases and requires the user to comment more carefully the STRUCTURE BASE.

2.2.4. The STRUCTURE BASE editor Since some changes in the STRUCTURE BASE are not allowed the editor will check the legality of each modification and special attention is paid to the correctness of the secondary changes in the STRUCTURE BASE. If for example a new reference is introduced in the STRUCTURE BASE, the initialization program (2.2.3) will be called to define the properties of that

2.2.5. The DDL INTERFACE module This module contains transformation programs to transform the detailed STRUCTURE BASE contents into terms of the Data Definition Language used by the Data Base Management System. The MANAGER will also accept statements written in the DDL and will transform them into the STRUCTURE BASE vice versa. 2.2.6. The PROGRAM GENERA TOR module This module generates source code (procedures) to do the database accesses needed in the application programs. These accesses refer in terms of the Data Manipulation Language (DML) used by the Data Base Management System to elements of its structure descriptions. It is not intended to provide a complete programming language in the system. Generally, it will be necessary in larger programs to complement the database access procedures generated with own routines written in the host language of the DML, for other processing tasks unrelated to the database. However, programs for simpler question-answer routines and straightforward listing can be generated entirely by the system. 2.2. 7. The request language The language in which the selection rules are formulated (REQUEST Language) may have a structure similar to the RELATIONAL-DATA-BASEsublanguages, like for example Chamberlin's et al. SEQUEL. Some of these languages will be studied to find the most appropriate user-oriented syntax. The REQUEST language should be highly interactive. The user may ask the MANAGER for information about the STRUCTURE BASE (fields, names etc.). This information may then be referred to in the REQUEST language. Furthermore, if the user gives illegal references to the structure, for example incorrect field names, the system will be able to correct the references, for example by automatic spelling correction or asking the user to correct these references. A simple editor for the REQUEST language will be

M. Jaintz and T. Riseh (eds.), Health infbrmation system LEVEL1:

I

PATIENT iEDER~T.'NBR NAME ADDRESS

P.OSL!M

LEVEL 2:

r---I DATE BEGIN / END : F'i DIAGNOSES :Fi- t • RISK FACTS " ' , , i l THERAP. RESULTS LEVEL 3 :

i',: :' ,I '," III I~ tl

I I /

|--

1

I CASE I HEALTH COORDINATES I EPICRISIS "1 <-FINAL DIAGNOSIS> [ -t DATE BEGIN / END / -/ ~--t -t

tb LEVEL 4 :

',1' I

EVENT L I i q DATE i | L - I <`RISK FACTS >

Hierarchical ~pointers Summary and i----quick-reference pointers . N • List of N's

< NOTES >

LEVEL 5 :

SYST. OBS.&INT. DATE TIME .-PROCEDURE ~FORMAT, VALUE

169

modules in the MANAGER system will rely upon intensive interaction with the user, and because of the requirements for frequent modifications of programs as well as for debugging ease during the development phase. The performance considerations are not critical at the MANAGER level, since the MANAGER is intended in the first place to generate production programs (which, of course, should be as efficient as possible) and the generation itself will happen only a few times per program. Furthermore we do not wish to spend much programming efforts during the development phase, that is until the final system concept has been settled. These considerations have lead to chose INTERL1SP as the programming system in which to develop the MANAGER. The actual INTERLISP 360/370 implementation to be used has been developed by the Department of Computer Science, Uppsala University, and the University Data Center of Uppsala on the basis of the INTERLISP system, as developed by BBN, Boston, Mass., USA.

":"

Fig. 3. The Data Structure Model of HIS [41 . 4. The Data Structure Model of HIS in BERLIN available in the system to permit the user to correct interactively previously entered REQUEST language statements. The compilation of the REQUEST language into the Data Manipulation Language will use the STRUCTURE BASE to do necessary optimizations of the generated DML code.

4.1. P A T I E N T

3. System considerations for the MANAGER

The patient is the logical root in the common database of HIS.

In order to develop the MANAGER as presented in section 2 we need a programming language and environment with at least the following capabilities: It should allow for the representation of logical data structures (for example lists and trees) and provide for manipulation and debugging them by a structure oriented editor and structure oriented I/O facilities. It should support extensive symbol processing and manipulation (for instance the processing of source code). - It should be highly interactive since most of the

The structure model of the historical part of the common database of HIS, the regional level in a multisatellite system [12], is represented as a hierarchical system, which contains the following levels (see Fig. 3).

4.2. P R O B L E M

A problem is the total of all examination- and treatment-cases, which result in connection with a disease. 4.3. CASE

A case is the entity of all examinations and treatments, which are performed in a specified facility of health service by a single person.

170

M. Yaintz and T. Risch (eds.), Health information system

4.4. E V E N T An event describes the data, which results f r o m a meeting o f physician and patient.

4.5.1. SBA : system-observing-action 4.5.2. S VA : system-changing~ction The terms SBA, S V A cover the special medical details, i.e. diagnostic and therapeutic actions and resuits. A m o r e detailed description o f the data structure m o d e l is presented elsewhere [4].

References [1] Anonym, Abgeordnetenhaus yon Berlin, Vorlage ~Jber die erste Fortschreibung des Berichts fiber die weitergehende Planung zur Automatisierung im Gesundheitswesen. Drucksache 6•977 vom 3.8.1973, Kulturbuchverlag Berlin. [2] Anonym, Medizinisches Informationssystem, DOMINIGTeilprojekt I: "Regionales medizinisches Organisationsund Planungssystem ffir [ibertriebliche Aufgaben des 5ffentlichen Gesundheitswesens", Senator f[ir Gesundheit und Umweltschutz, Berlin, Nov. 1973. [3] Anonym, Der Senator f'dr Gesundheit und Umweltschutz, Berlin: Protokoll der Arbeitssitzung des Fach-

arbeitskreises V in Berlin vom 25.-28. Januar 1975. [4] K. Sauter (Ed.), A Data Structure Model for a Health Information System, Comp. Progr. Biomed. 6 (1976) in press. [5] M. Jainz and P. Wick, A Dialogue System for Displaying and Updating Patient Master Records, in J. Andersson and M. Forsythe (Eds.) Proc. MED1NFO 1974, North-Holland, Amsterdam, 1974. [6] Lou S. Davis, A System Approach to Medical Information Report of Permanent Medical Group, Department of Medical Methods Research (1972), 3779 Piedmont Avenue, Oakland, Calif. 94611, USA. [7] K. Appel and T. Risch, LISP-IMS MANAGER, Project Status Report 1975-01-14, Uppsala University Data Center, 75002 Uppsala, Sweden. [8] T. Risch, LIM, LISP-IMS MANAGER documentation and user manual (to be published). [9] Chamberlin and Boyce, A Structured English Query Language, R.J. 1394 (1974). [10] Boyce, Chamberlin, King Ili and Hammer, Specifying Queries as Relational Expressions, in Klimbie, Koffeman (Eds.) Data Base Management, IFIP Working Conference on Data Base Management, April 1974, North-Holland, Amsterdam, 1974. [11] W. Schneider and S. Bengtsson (Eds.), The Application of Computer Techniques in Health Care, Comp. Progr. Biomed. 5 (1975) 169, North-Holland, Amsterdam. [12] W. Schneider, Integration of Data from a Computer Automated Laboratory into a Generalized Hospital Information System, in G. Griesser and G. Wagner: Automatisierung des Klinischen Labors, F.K. Schattauer Verlag, Stuttgart-New York (1968) pp. 301-305.