ArchiMed A Medical Information- and Retrieval SystemCh. Rehnelt, G. Boldt, W. Premauer Department of...

ArchiMed: A Medical Information- and Retrieval System

Appears in Methods Inf Med; Vol. 38 (1), pp. 16-24; 1999

ArchiMed

A Medical Information- and Retrieval System

Prof. DI DDr. W. Dorda, DI Th. Wrba, DI G. Duftschmid, Mag. Dr. P. Sachs, Mag. Dr. W. Gall, Ch. Rehnelt, G. Boldt, DI W. Premauer

Department of Medical Computer Sciences University of Vienna

Address requests for reprints and correspondence to:

Wolfgang Dorda Institut für Medizinische Computerwissenschaften

Spitalgasse 23 A-1090 Vienna

Austria Tel.: +43-1-40400 / 6699 (6698)

Fax.: +43-1-40400 / 6697 E-mail : wolfgang [email protected]

1


ArchiMed

A Medical Information- and Retrieval System

W. Dorda, Th. Wrba, G. Duftschmid, P. Sachs, W. Gall, Ch. Rehnelt, G. Boldt, W. Premauer

Department of Medical Computer Sciences

University of Vienna

Abstract ArchiMed is a highly flexible medical data storage and retrieval system which adds sophisticated clinical research support to a standard hospital information system (HIS).

Currently, the HIS of Vienna General Hospital-University Hospital (2000 beds) stores the clinical data of over 2 million patients. While this system supports patient care (for example, ADT, clinical chemistry, diagnosis, procedures), it has no features to facilitate research, for example, management of clinical studies.

ArchiMed is designed to support clinical research. It includes an independent database, which mirrors virtually all the information held in the HIS while also allowing new data to be collected independently and added to the database. Flexible retrieval and analysis of any data contained in the database are then possible. Thus existing patient care data can be smoothly incorporated into a study together with data collected specifically for research purposes. The system has already been successfully launched in the departments of surgery and will soon be installed in other departments.

Keywords: clinical information system, data retrieval system, object orientation, semiautomated database design

2


1. Introduction

While many hospital information systems (HISs) can manage large amounts of patient care data, few have built-in capabilities for supporting clinical research. They do not, for instance, allow the researcher to access their databases directly and analyse the extracted data. As already noted in [1] - [3], such flexibility is extremely important at institutions where clinical research is a major emphasis. ArchiMed was designed to provide this support at Vienna General Hospital, the largest university hospital in Europe.

The ArchiMed system has two primary features that enable it to be used as a powerful research tool. First, it allows researchers to define research-relevant variables over and above those variables relating to patient care, which are already tracked by the Vienna General Hospital’s current information system KIS (“Krankenhaus Informations System”, the German equivalent of HIS). Access rights can be assigned to these variables that make them available for personal use (private), to user groups (team-wide) or generally (system-wide). Data concerning the additional “research” variables are then united with the complete set of patient care data within the ArchiMed database. Patient care data collected in the HIS are transferred periodically to the ArchiMed database (see Figure 5). Second, ArchiMed provides tools that enable virtually any statistical operation to be easily performed on the combined data.

The advantages of such a system are numerous. All patient data are stored in the same database, which means that a common data model can be employed for every clinical study. Data extraction can be based on generic mechanisms, avoiding complicated and time-consuming adaptions to varying data models [1]. All data are held in one system rather than numerous incompatible systems, greatly improving both the speed and the accuracy of retrieval. Data are kept consistent with the HIS by ensuring that updates in the clinical setting (HIS) are automatically reproduced within the ArchiMed system.

When a patient enrolled in an active ArchiMed study presents to clinicians, they are automatically notified of this and provided with a form for the relevant data, eliminating a tedious paper-based process. A final advantage is that the researcher does not need to know anything about creating or managing a database, since this is done in background by ArchiMed. Inputting and retrieving data are easily handled using forms which the user him/herself designs and fills in.

The ArchiMed system has been developed, using object-oriented technology, as a client/server application. Data is stored in a central database on a database server. It is therefore generally available, although under data protection.

3


The ArchiMed system is portable to most of the operating systems commonly employed in hospitals: possible operating systems include Windows, MAC/System7, MAC/System 8, OS/2 and many UNIX derivatives.

The system is already successfully used in the departments of surgery of the University of Vienna Clinics at the Vienna General Hospital (2000 bed capacity) and has been adopted by the University of Graz Clinics. Negotiations with several other clinics and hospitals are in progress.

The principal reason for the success of the system is the opportunity it gives the clinician to define variables, forms and workflows him/herself, thus ensuring an exact fit between data acquisition and clinical procedures. Interestingly, while the literature reveals a certain trend towards user-driven systems of this type, there are no reports of an approach on a scale comparable to that described here.

The WAMASTAT system [4], which permits independent data definition by the end user, was developed in 1982. Even at that "pre-PC" time the need for flexible data definition was so great that a system based entirely on mainframe technology was developed. The spectacular success enjoyed by WAMASTAT among the medical staff of the University of Vienna medical clinics confirmed the correctness of this approach. The opportunities offered by WAMASTAT to specify data are still very limited, however: after the names and labels of variables, data types (numerical, alphanumerical, date) and the required input/output positions have been specified, the system automatically proposes a (modifiable) input mask and generates an appropriate relational table internally. Data may then be immediately input and analysed. The system architecture is very well suited to carrying out clinical studies, especially those having a simple design, but offers only rudimentary access to routine clinical data.

"Semi-automated database design by the end-user" was proposed by d'Hollosy [1]. The URIS system was developed in response to demands similar to those that led to WAMASTAT. However, URIS automatically makes both study- and patient-identifying data available uniformly over the entire system, including a unique patient number, a hospital code (in multicentre studies) and a code for the HIS. The system is designed to support clinical studies, but does not provide any support in the maintenance of electronic healthcare records. However, the identification data indicated show that URIS represents a step towards the objective discussed in this paper: The system enables the flexible design of forms by the end user and data integration - even between one hospital and another! - using the identification data.

Sabri [5] described a "Do it 2000" system, which likewise brings a user-driven approach to a HIS. A uniform user interface serves to display "flexibly definable" medical documents. However, the emphasis of the project is on the man-machine interface: Underlying system

4


components (data model, support of working procedures and the use of clinical data to plot individual courses or carry out statistical evaluations) are not the object of the project.

In this paper we shall give an overview of the ArchiMed system’s functionalities to support clinical research. Section 2 describes the system’s main functions, in particular its tools for supporting autonomous form design by clinicians, its data collection and management facilities and its analytical tools. In section 3 some aspects of the system’s implementation will be discussed. In section 4 additional information concerning the project and an analysis of the system's benefits and limitations are given.

2. System Functions

The clinical research functions of the ArchiMed system may be divided into three major groups:

•

•

•

form design and definition of variables

data collection and management

statistical analysis

In the following sections we will discuss these issues in detail.

Definitions:

A data field is a label (the name of the data field) that is associated with a variable (the value of which it may display). A form (see Figure 2) is a collection of data fields that may be used to collect or display data for patients. A form either partially or completely filled with data about a patient may be stored as a document related to that patient.

2.1 Form Design and Definition of Variables The principal aim was to provide a tool that would allow clinicians to create complex database-related forms without requiring extensive computer knowledge.

With the assistance of the Form Designer (see Figure 1), the end user can design the forms he/she needs independently without resort to software designers. Thus delays and friction are avoided and clinicians receive exactly the forms they need [6].

Fig. 1

Form maintenance and service can also be taken over by the clinician, enabling alterations to be promptly inserted.

5


One of the main requirements of the system is that any form designed on an ArchiMed client must be immediately available on all other clients. Forms created using the Form Designer are therefore stored in a central database server so that a form can be downloaded dynamically by any client on request.

A further requirement is that data collected with the aid of a form should be stored in a way that it may be linked with data originating from any other form in the course of retrieval. The data are therefore stored independently of the corresponding form in a common, retrievable data structure.

2.1.1 The Multi-Page Concept In order to facilitate the structuring of ArchiMed forms, the latter may be divided into individual pages. This approach, which is also suggested in [7], assists in placing variables having matching contents in a visual relationship with one another.

The individual form may be divided between two types of pages: Notebook Pages and Branch Pages. Notebook Pages may be opened using corresponding Index Tabs in any desired sequence. Branch Pages can be opened from a single source Notebook Page using a button (compare Figure 2). They can also form the source page of any number of other Branch Pages. Thus, users have at their disposal a mechanism for defining tree-like sequences of form pages. Certain parts of the tree may be activated or de-activated by enabling or disabling the relevant button. To this end a simple script language was invented to define the activating and de-activating conditions. A graphical formula assistant supports the user when specifying the conditions in the script language.

The use of the Branch Page enables the definition of forms, sections of which are displayed during data collection only if relevant. For example, all variables applying to the stages of pregnancy might be placed in one part of the tree. The branching to this part of the tree would be blocked in the case of male patients.

2.1.2 The Version Concept Since forms are subject to alteration, the ability to display documents already stored using prior versions of forms must be ensured.

After altering a form the user has to decide whether it should be stored in the same or a new version. In the case of minor modifications, e.g. adaptation of a layout, only the user can determine if the significance of the original document has been changed. However, in the case of essential alterations, e.g. the deletion of a variable from a page, the system enforces the creation of a new version. Thus, the consistency of documents already stored is ensured.

6


Versions are tracked by the system, which allows each document to be automatically displayed in the form version in which it was stored.

2.1.3 The Design Process To outline the potential of the form designer, we now describe a design session stage by stage.

Each form page is individually designed using the “Palette“, “Layout“ , and “Properties“ Tools (see Figure 1).

The Palette Tool enables the user to locate the desired variables on the form page as data fields. A number of seek variants may be used for variables already existing in the database (according to label, alphabet or category); alternatively, the immediate creation of a new variable in the database is possible as described in section 1. The Palette Tool also puts at the user’s disposal a number of layout elements (graphics, texts, boxes, etc.) and complex function controls (formula fields, branching buttons, etc.).

If the user wishes to minimise time spent on the design phase, he/she can automatically generate a form page using pre-selected variables. If the design is carried out manually to achieve a more sophisticated layout, the user can choose the desired type of data field (input field, combo box, radio button, etc.) for each variable. The choice of an appropriate data field type enables better data quality (e.g. by offering standard entries using a combo box). The number of different data field types available for a variable depends on the variable type (number, text, date, time, timestamp).

To express relationships between a number of data fields on a form, the fields may be grouped. This produces a visual as well as a database relationship that can be used for data retrieval. The option of defining relationships between clinical data is regularly exercised by ArchiMed users. As an example, one might imagine a form for the collection of post-operative data. Amongst other data fields, this form could provide for the entry of potential complications and therapies, each complication to be associated with a corresponding therapy. In order to enable the entering of related complication-therapy pairs in the form, the corresponding data fields could be grouped in a table.

Parameterisation of data fields in a form can be achieved using the Properties Tool. The number of adjustable properties of a data field is decided by the variable it represents and by the type of data field.

For example, domains can be defined for numerical data fields. These domains may be called up during the recording process for the purpose of input checking. The default label of a data field may also be overridden. A unit category may be assigned to each numerical data field

7


(e.g. length, weight, etc.). Each of these categories contains units that can be converted to any other unit of the same category (e.g. m, cm, mm, etc.). In each category a particular unit is designated as the category’s default unit, in which the relevant data are stored in the database. However, the unit used when displaying the data field may be selected with the assistance of the Properties Tool and the required conversion is then automatically carried out by the system.

Results may be calculated and displayed in a data field using data from other fields. The relevant formula may be defined by the user with the help of the Property Tool and supported by a formula assistant. Conditions for activating or de-activating individual data fields or buttons may be similarly expressed.

The Layout Tool helps the user arrange the data fields on a form. Various formatting features are offered, e.g. aligning data fields and creating groups, adjustment of size and spacing, breaking down data fields and groups into their elementary components, etc.

2.2 Data Collection and Management Data fields, forms and documents as defined in section 2 are fundamental to both the KIS and the ArchiMed systems: that is, all data are collected using forms and maintained as documents. For example, a secretary may fill out the “patient identifying data” form by entering the patient’s name and insurance number in the appropriate fields on a form. Physicians fill out diagnosis forms using the appropriate codes.

In the KIS and the ArchiMed systems certain forms (for example, “Electrolytes”) may be automatically filled out using electronically transferred data from laboratory instruments.

In the KIS system data may only be collected through predefined forms. New forms cannot be defined by the user.

In contrast, the ArchiMed system allows flexible form design using the Form Designer, which is an integral part of ArchiMed. By defining data fields the user can specify the data to be collected by or viewed in a form. The data fields may be associated with already existing variables (either defined by previous ArchiMed users or by KIS ) or new variables, which are defined and added to the ArchiMed database. A saved form may be added to a list of “working forms”, permitting each clinician individually to organise frequently used forms.

Sets of patients may be defined (e.g. all those who had a cholecystectomy within the past month) and forms automatically associated with them in preparation of a clinical study. ArchiMed ensures that, whenever a patient enrolled in a study presents to a physician, the study forms to be filled in are automatically added to the list of working forms, ensuring that the clinician is aware that he/she should review these forms and add or alter data

8


appropriately. The once complicated and unreliable process of collecting data from multiple sources on patients involved in studies is thus automated.

The researcher may also require a form that is being used for new data entry to display information about the patient that already exists in the system. For instance, he/she may want patient-identifying data to appear at the top of every form or certain laboratories to be included in the form so that they appear in the document finally created. This is easily managed with ArchiMed. A form can even be created that is used solely to display patient information without the opportunity to enter new data or alter existing data. To obtain an overview of essential patient data, forms can be designed to include both individual data fields for specific variables and entire patient documents (or parts thereof) already stored. This feature of the system is also used to compose doctor's letters.

2.2.1 Data Management Functions that Support Patient Care Patient data can be completely managed (retrieved, displayed and analysed) by ArchiMed to give the physician a rapid overview of patient status. All documents containing information about the patient from the ArchiMed database can be listed, sorted, filtered and visualised. To enable a quick comparison, several documents can be displayed simultaneously in separate windows.

Patient data may also be retrieved and viewed in various ways, for example, in tabular or graphic form (see Figure 2). Values falling outside the normal range can be highlighted. The clinician can see all abnormal values over a specified period of time at a glance. Data can be plotted over time and charts viewed individually or overlaid with automatic adjustment of axis. Thus, the ArchiMed data display may even be used in simple patient care.

Fig. 2

2.2.2 Data Management Functions that Support Research Of course, the real power of ArchiMed lies in its ability to extract and analyse all patient data in the ArchiMed database. This function allows patient selection based on logical criteria and analysis of data from one or more patients through a user-friendly interface. Analysis is based on SAS (Statistical Analysis System) [8]. Results can be displayed in numerous formats, including tables and various graphs. Details can be found in section 2.3.

9


2.3 Statistical Analysis One of the basic building blocks of the ArchiMed system is its retrieval system. Routine patient care data may be linked to data derived from scientific studies and the data retrieved and analysed jointly.

Retrieval can be managed in an intuitive way within the ArchiMed system and meets the requirements of complex question formulations.

The primary scientific aim is to define patient sets, which are analysed statistically, e.g. the median GOT level of all patients with hepatitis A may be calculated. Commonly used methods include descriptive statistics (means, extremes, medians, frequencies, etc.), statistical tests (pairwise comparisons, the chi-square test etc.) and graphic data visualisation methods (histograms, plots, etc.) to elucidate biometrical relations.

The retrieval system consists of the sub-sections Set Definition and Function Execution.

2.3.1 Set Definition Patient sets are defined by stating suitable, logical conditions: for example, by selecting all patients who "suffer from a certain complication within 0 to 6 days of a specific surgical intervention". The Retrieval System allows complex time constraints to be formulated (see Figure 3), since the course of a disease is of key importance (compare [9] - [14]).

Fig. 3

The criteria for set formation are retained throughout the session and, above all, when changing a function.

2.3.2 Function Execution In the process of function execution the user determines which statistical functions should be applied to the chosen patient set. At this point the basic distinction between univariate (descriptive statistic relating to one variable) and multivariate (statistic relating to two or more associated variables) functions is made.

As an example, the frequency function provides a list of stored entries for each chosen variable showing their rate of occurrence. A typical request for data retrieval would be: "which surgical interventions were carried out for a definite patient set and how often did they

10


occur in the past year?". The result would be an alphabetical list of operations and their frequency. Another function commonly used in surgery is based on the Kaplan-Meier test and compares the probabilities of survival of chosen patient sets (see Figure 3).

3. Implementation Aspects / Technical Basis

3.1 System Architecture As already noted, the system is based on a client/server architecture. It has been implemented according to the Distributed Function Model, proposed by the Gartner Group. The graphic user interface, with all applications concerning user guidance, is localised to the client. Data storage, processing of stored data and control of this data are implemented on the server. To avoid overloading the network and the client with undue quantities of data, complex statistical analyses may also be carried out on the server.

3.2 Development Environment After an extensive product survey, Parc Place’s Visual Works [15] was chosen as the main development environment. Visual Works is an object-oriented development environment for designing portable applications and is based on the programming language Smalltalk. This pure object-oriented language offers an extensive and stable class library, the nuclei of which have been in existence and subject to testing since the early 1980s. In particular, the available classes for the development of graphic user interfaces were a significant argument in favour of Visual Works.

Since various system platforms are in use at Vienna General Hospital, portability was also an important criterion. Applications developed in Visual Works are immediately portable. No further processing of the source code - for example, platform-specific compiling - is necessary when changing the platform.

The ArchiMed-Retrieval system has been implemented using the SAS (Statistical Analysis System) [8] development environment. The general advantages of SAS as the basis and background of the retrieval application are its powerful statistical functions and the easy access offered to these functions from the development environment.

11


3.3 Database Overall View After close comparison of current database systems, the choice fell on Oracle’s [16] database server. The following factors were decisive in making this choice:

• the company’s widespread representation in the medical/scientific sector;

• availability on all significant operating system platforms;

• support for various character sets (NLS);

• support for stored procedures and distributed databases;

• the integrated CASE Tool to support data modelling.

In addition to its support of data modelling, the CASE Tool guarantees that any expansion or adaptation following detailed planning can be incorporated into the data model. The integrity of the information is ensured by completeness and consistency testing in each phase.

Database procedures have been employed for high-intensity data manipulation, for example, the storage of forms or documents. Using these procedures, complex multi-level operations can be executed by a single procedure call on the server. Thus intensive network communication is avoided.

3.4 Data Model In designing the ArchiMed data model, the main criterion to be met was that no operation should require specialised computer knowledge (in particular, database knowledge) on the part of the user.

Consequently:

•

•

a model consisting of a single table, which contains all variables was excluded, since this would have required modification of the table structure whenever a new variable is created. Furthermore, a table of this kind would largely consist of null values since in general only a fraction of the entire variable set is affected by a single insertion.

the standard approach of most report tools, wherein a new table is created for each new form, was also discounted: typical retrievals involve more than one form and under this approach defining generic, complex queries directed to more than one form would be difficult.

12


For this reason, a metamodel was designed, which permits dynamic expansion of medical variables and forms and makes possible retrievals from more than one form.

Fig. 4

The core of this model (see Figure 4) is constituted by the elements variable, form, version, data field, document and value [17].

The entity variable represents the catalogue of medical variables.

A form consists of one or more assigned variables. The allocation of these variables is carried out using a data field.

Each document relates to one form (version) and the stored values of this document (value) relate to the relevant data field.

4. Experience / Discussion

4.1 Duration and Progress of the Project Development of the system drew on more than 20 years of experience built up by the Department of Medical Computer Sciences in this field (development and operation of the Medical Information and Retrieval Systems WAMIS [18], [15], NISYS, WAMASTAT [18], WAREL [20], [21] and WAMAS [18]. These systems will be replaced in coming years by the new ArchiMed system.

Planning commenced at the beginning of 1994 (following preparatory work in 1993). After functional planning in the first half of 1994, the most important decisions concerning the architecture of the system were taken and training of the development team began. Detailed planning was completed by the end of 1994.

The years 1995 and 1996 were devoted to implementing the system.

By the end of 1996 implementation had been completed and by the beginning of 1997 preparations for commissioning the system had been initiated.

In the first half of 1997 the system was introduced to the departments of surgery of the University of Vienna (installation of the database server, delivery and installation of the clients, training). In the second half of 1997 the system was commissioned on a stepwise basis in the six surgical departments.

13


4.2 Project Status and Experience The first stage of introducing the system focused principally on the department of organ transplants. From the end of 1997 all clinical studies and all essential administrative procedures related to patient care (including outpatient support, transplant planning data and EURO-transplant registration data) in this department were implemented using the ArchiMed system. In the department of cardiology data relating to heart surgery were input into the ArchiMed system directly in the operating theatre. The databases of all major surgical studies were transferred into the ArchiMed system.

After 6 months during which the system was commissioned on a department by department basis, the current status of the system is as follows:

Table 1

Table 1 shows that the flexibility of the system has already enabled a large number of variables - totalling 4300 - to be defined. By the end of 1997 more than 310,000 documents containing about 5.2 million individual values had been stored in the system. A high proportion of these data had been imported electronically from other systems.

The system has been welcomed by users and nearly all the other clinical departments of the University of Vienna are also interested in the system. In recent months the possibility of funding further extension of the system - as demanded by users - has been widely discussed at all levels (including senior political decision-makers). Funding is already assured for adoption of the system by a number of other clinical departments before the end of this year.

In addition, the university clinics of Graz plan to adopt ArchiMed and have therefore introduced the system in recent months.

4.3 Discussion and Planned Further Steps

The primary aim of the ArchiMed system is to support scientific research. In this area, the main benefits of the system are as follows: ArchiMed offers the user unrestricted opportunities to define medical variables and forms within a clinical information system. Particular emphasis has been placed on simplicity in the definition process. The system’s flexibility in this field enables users to achieve an original and exact match with their own working procedures. All of the system’s clinical data may be used for the purposes of statistical evaluation as well as in patient care. In analysing the data the clinician is supported by powerful yet user-friendly system components. The analytical elements of the system make possible complex investigations in which the disease course and the relationships

14


between the data can be considered. No system of this type that could also operate in conjunction with the existing HISs at Vienna General Hospital described above (see Figure 5) is commercially available and a system therefore had to be newly developed.

The main limitation of the ArchiMed system is that it currently does not facilitate communication between individual departments, for example, between ward and laboratory (laboratory requests, reporting back of results), is not supported. As communication is not integrated in the system, also the status of a document - for example, - "laboratory diagnosis incomplete and not yet released to the ward" or "laboratory tests positive and released to ward" – is not considered. A further reason for not supporting document status is that correction of data errors must be possible on retrieval of scientific data. Specially empowered system-users may therefore correct data at any time. However, the clinical user also wants to apply the ArchiMed system in future for interdepartment communication. Consideration is therefore currently being given to expanding ArchiMed to fulfil this system function.

As noted, the flexibility of the ArchiMed system has produced a high level of user identification with the system. However, it must be made clear that a corresponding organisational structure is an absolute requirement for the use of a flexible system of this type. Since doctors have been given the technical ability directly to introduce adaptations into the system "on site", the associated organisational structure must also be on site: that is, an authorised clinician should be present in each department to play a coordinating role. In the departments of surgery this is currently done by a clinician jointly with a medical information scientist. Accordingly, the data dictionary is rigorously maintained and coordinated: no forms or variables may be drafted without agreement as to their content.

The user-driven approach described has fully confirmed its value within the organisational framework outlined.

The project is therefore carried further as rapidly as possible. Further steps planned include:

1. Phasing out of existing systems at the university surgical clinic.

This step was provided for in developing the ArchiMed system. Existing databases can be progressively incorporated into the ArchiMed system on the basis of common patient identification services and the communication server (see Figure 5). Conclusion of this phase is scheduled to take place not later than mid-1998.

2. Adoption by further departments.

15


This will involve separation of patient identification services and the communication server from the existing WAMIS system and the incorporation of existing databases from further departments into the ArchiMed system (see Figure 5). Conclusion of this phase should be achieved by the end of 1999.

Fig. 5

4.4 Summary

ArchiMed allows all patient data to be easily managed. The system may be used for clinical care, but its major focus is clinical research. The system supports patient-oriented Data Collection and Information Presentation including tables and graphs. Forms may be defined autonomously by the clinician using the system’s Form Designer tool.

ArchiMed enables researchers to define the variables they wish to track for any patient and to add these variables to a central Data Dictionary without requiring any database knowledge. The system then ensures that the variables are tracked. Access rights are assigned to the variables that make them available for personal use (private), to user groups (team-wide) or generally (system-wide).

Finally, ArchiMed permits extraction and analysis of data for a large number of patients without requiring knowledge of database management.

The opportunity independently to define forms and variables is exploited by users to achieve a better fit between documentation and clinical working procedures. This produces a significant improvement in user acceptance and computer use which yields more comprehensive and better data. The user-driven approach of the system demanded corresponding organisational preparations, but overall it has entirely justified its introduction.

Acknowledgements:

Financial support for the project described in this paper has been received from the ARGE/AKH - VAMED. The authors want to thank Christopher Kreist for many fruitful suggestions and Michaela Mayrhofer for her help in preparing this paper.

16


References:

[1] D’Hollosy W., Walrave M.H.F, Hendriks B.Th, Debruyne, F.M.J, Wijkstra H. Semi,-automated Database Design by the End-user. Methods of Information in Medicine 1995; 34: 266-271.

[2] Herson J. Personal computer software for clinical trials. In: Rotmensz N, ed. Data Management and Clinical Trials. Amsterdam: Elsvier Publ, 1989: 235-246.

[3] Koval J.J., Krarciak L.M., Grace M.G.A., Lockwood B.J. A comprehensive database management system for a variety of clinical trials. Methods of Information in Medicine 1987; 26: 24-30.

[4] Dorda W., Laminger B., Sachs P., Reichetzeder Ch. Softwaresysteme zur Auswertung Medizinischer Daten. In: Gell, G., Eichtinger, Ch., eds. Medizinische Informatik 94, R.Oldenbourg Wien-München, 1994: 78-82.

[5] Sabri A.: Rapid Customizing to Evolving HIS Requirements Due to an Object Oriented Configuration Architecture. In: Dudeck J., Blobel B., Lordieck W., Buerkle T., eds. New Technologies in Hospital Information Systems, IOS-Press Amsterdam, Berlin, Oxford, Tokyo, Washington, 1997: 136-140.

[6] Jaulent M.C., Jean F.C., Sauquet D., Degoulet P. The interface manager of the HELIOS medical software environment. In: Lun, K.C. et al. eds. MEDINFO 92. Elsevier Science Publishers B.V. (North Holland), 1992: 1305-1310.

[7] Borälv E., Göransson B., Olsson E., Sandblad B. Usability and efficiency. The HELIOS approach to development of user interfaces. Computer Methods and Programs in Biomedicine 1994; 45: 47-64.

[8] SAS Institute Inc., Master Index to SAS System Documentation, Version 6, Fourth Edition, Cary, NC: SAS Institute Inc., 1992.

[9] Banhard F., Klaeren H. A Graphical Query Generator for Clinical Research Databases. Methods of Information in Medicine 1995; 34: 328-339.

[10] Gall W. Zeitrelationen für Auswertungen medizinischer Daten. Query-System für Daten aus dem heterogenen klinischen Routinebetrieb. Dissertation, 1995.

[11] Klopproge M.R. Modelling Information Preserving Databases: Consequences of the Concepts of Time. In: Proceedings of the 9th International Conference On Very Large Data Bases, 1983: 399-416.

[12] McDermott D. A Temporal Logic for Reasoning About Processes and Plans. Cognitive Science 1982; 6: 101-155.

[13] Snodgrass R.T. Temporal Databases: Status and Research Directions. ACM SIGMOD Record 1990; 19 (4): 83-89.

[14] Snodgrass R.T. An Overview of the Temporal Query Language Tquel, TR 92-22, Department of Computer Science, University of Arizona, Arizona, July 1992.

[15] ParkPlace-Digitalk Inc. Visual Works User’s Guide Revision 2.0, 1995.

[16] Oracle Corporation. ORACLE7 Server Concepts Manual, Redwood City, CA, 1992.

[17] Barker R. ed. Case* Method: Entity Relationship Modelling. Addison-Wesley-Verlag, 1992.

17


[18] Grabner H., Marksteiner A., Dorda W., Wolf W., Grabner G. WAMIS: A Medical Information System. Conception and Clinical Usage. Journal of Clinical Computing 1982; 10: 154-169.

[19] Grabner H. Die Datenbank des Medizinischen Informationssystems WAMIS. In: S.Koller, P.L. Reichertz und K.Überlag, eds. WAMIS Wiener Allgemeines Medizinisches Informations-System. New York/Tokyo/Berlin/Heidelberg: Springer Verlag, 1985: 36-82.

[20] Dorda W. WAREL: A System for Retrieval of Clinical Data Considering the Course of Diseases. Methods of Information in Medicine 1989; 28: 133-141. [21] Dorda W. Data-Screening and Retrieval of Medical Data by the System WAREL. Methods of Information in Medicine 1990; 29: 31-11.

Address:

Wolfgang Dorda

Institut für Medizinische Computerwissenschaften

Spitalgasse 23

A-1090 Vienna

Austria

Tel.: +43-1-40400 / 6699 (6698)

Fax.: +43-1-40400 / 6697

E-mail : [email protected]

18


Fig.1 The Form Designer allows autonomous definition of forms by the clinician. Form pages

are individually designed using the “Palette“ and “Layout“ Tools. Each data field may be

parametrised by means of the “Properties“ Tool.

Fig.2 ArchiMed provides several ways to visualise patient data: Individual documents are

viewed by means of their corresponding forms, whereas tables and graphs link several

documents to get an overview of a patient’s medical status.

Fig.3 Retrieval of patients with a certain therapy followed by an arising complication is

formulated. The variables therapy and complication are linked by the patient-IDs. They do not

have to be stored at the same document, but the date of therapy must precede the date of

complication. The window in the background shows the printout of a Kaplan-Meier-

Analysis.

Fig.4 Entity Relationship Diagramm of the ArchiMed Data Model’s main components

Fig.5 Overview of the data flow between ArchiMed and the HIS. Several legacy systems, like

the Wamis system for instance, will be incorporated into ArchiMed in the next project phase

19


Fig. 1 The Form Designer allows autonomous definition of forms by the clinician. Form pages are individually designed using the “Palette“ and “Layout“ Tools. Each data field may be parametrised by means of the “Properties“ Tool.

20


21


Fig.2 ArchiMed provides several ways to visualise patient data: Individual documents are viewed by means of their corresponding forms,

whereas tables and graphs link several documents to get an overview of a patient’s medical status.

22


23


Fig. 3 Retrieval of patients with a certain therapy followed by an arising complication is formulated. The variables therapy and complication are linked by the patient-IDs. They do not have to be stored at the same document, but the date of therapy must precede the date of complication. The window in the background shows the printout of a Kaplan-Meier-Analysis.

24


VALUE

DOCUMENT

PATIENT

UNITFORM VARIABLE

belongs to references to

consists of specifies

belongs to

is owner of consists of

belongs to is assigned to depends on

is assigned to

is base for describes is base for

DATA_FIELD

VERSION

Fig. 4 Entity Relationship Diagramm of the ArchiMed Data Model’s main components

25


HIS

Comm.Buffer

Comm.Server

PatientServer

MedicalDatabase

Wamis

MedicalDatabase

ArchiMed

PatientData

Mainframe

Unix-Cluster

Online Requests

Fig. 5 Overview of the data flow between ArchiMed and the HIS. Several legacy systems, like the Wamis system for instance, will be

incorporated into ArchiMed in the next project phase

26

Date post:	21-Feb-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

ArchiMed A Medical Information- and Retrieval SystemCh. Rehnelt, G. Boldt, W. Premauer Department of...

Documents