wendt: modeling hospital information systems (part 2 ... · modeling hospital information systems...

© 2004 Schattauer GmbH

256

Methods Inf Med 3/2004

We start with a requirements list on a3LGM2 tool and a short discussion of othermodeling approaches in chapter two. Thethird chapter describes the 3LGM2 tool it-self. The fourth and largest chapter reportson results from the work of the authors ininformation management at the LeipzigUniversity Hospital (UKL): It describes amodel of that sub HIS of the UKL thatdeals with archiving patient records. Ana-lyzing and presenting capabilities that helpto answer questions with a model are de-scribed in the fifth chapter. Benefits as wellas shortcomings and needs for further de-velopment are discussed finally.

Requirements and ApproachesA 3LGM2 compliant model describes an information system using three differentlayers [1]:● a domain layer,● a logical tool layer and● a physical tool layer.

The domain layer consists of enterprisefunctions and entity types. An entity repre-sents information about a physical or virtu-al thing (in a hospital) and an entity type isa class of entities. The logical tool layer fo-cuses on application components and thephysical tool layer describes physical dataprocessing components. In contrast to oth-er approaches the 3LGM2 also defines in-ter-layer-relationships between the layers

Modeling Hospital Information Systems (Part 2): Using the 3LGM2 Tool for Modeling Patient Record ManagementT. Wendt, A. Häber, B. Brigl, A. WinterInstitute for Medical Informatics, Statistics and Epidemiology, University of Leipzig, Leipzig, Germany

IntroductionA hospital information system (HIS)should be considered as that socio-techni-cal subsystem of a hospital which has toprovide information, e. g. about patients, atthe right time, in the right place to the rightpeople [1-3]. Accordingly, a HIS is not onlythe hospital’s ward management system orthe patient management and accountingsystem but its whole system of informationprocessing. It therefore comprises e. g. thepaper-based patient records as well as thecomputer-based patient monitoring systemin an intensive care unit.

Such a comprehensive and complexsystem needs a systematic informationmanagement approach. The informationmanager’s task is comparable to the task ofan architect, who has to construct a com-plex building from different and probablyheterogeneous components. The informa-tion manager needs a blueprint or modelfor planning the information system but also for its direction and monitoring.

In [1] we proposed the 3LGM2 as a metamodel for modeling HIS. Preparing a mod-el does not only need a meta model but also an appropriate tool. Using 3LGM2 asthe ontological basis this tool should enableinformation managers to graphically designeven complex HIS. It should assist informa-tion managers similarly as computer aideddesign tools (CAD) support architects.

The aim of the paper is to present a pro-totype of the graphical 3LGM2 tool and todemonstrate its usability by presenting amodel of a part of the Leipzig UniversityHospital Information System. The 3LGM2

tool is freely accessible and readers are wel-come to evaluate itb.

SummaryObjectives: We introduce the 3LGM2 tool, a tool formodeling information systems, and describe the processof modeling parts of the hospital information systemof the Leipzig University Hospital (UKLa). We modeledthe sub information systems of five patient record ar-chiving sections to support the creation of a proposalfor governmental financial support for a new documentmanagement and archiving system. We explain thesteps of identifying the model elements and their rela-tions as well as the analyzing capabilities of the 3LGM2

tool to answer questions about the information system.Methods: The 3LGM2 tool was developed on the basisof the meta model 3LGM2 which is described in detailin [1]. 3LGM2 defines an ontological basis, divided intothree layers and their relationships. In addition to usualmeta CASE tools, the 3LGM2 tool meets certain require-ments of information management in hospitals. Themodel described in this article was created on the baseof on-site surveys in five archiving sections of the UKL. Results: A prototype of the 3LGM2 tool is available andis currently tested in some projects at the UKL and partner institutions. The model presented in this articleis a structured documentation about the current state of patient record archiving at the UKL. The analyzingcapabilities of the 3LGM2 tool help to use the modeland to answer questions about the information system.Conclusions: The 3LGM2 tool can be used to modeland analyze information systems. The presentation ca-pabilities and the reliability of the prototype have to beimproved. The initial modeling effort of an institution isonly valuable if the model is maintained regularly andreused in other projects. Reference catalogues and reference models are needed to decrease this effortand to support the creation of comparable models.

KeywordsInformation management, hospital informationsystems, models (theoretical), information manage-ment, organizational model, 3LGM2, computerizedmodels, documentation, patient record

Methods Inf Med 2004; 43: 256 –67

a UKL is the official abbrevations of the Ger-man name »Universitätsklinikum Leipzig«

b Please e-mail to [email protected]

The 3LGM2 Tool for Modeling Patient Record Management

257


to build integrated models of informationsystemsc.

A tool to efficiently support informationmanagers in constructing 3LGM2 modelsfor HIS in real environments should ● provide a graphical representation of

the most important concepts of 3LGM2;● ensure that only the 3LGM2 concepts

can be modeled and that only those associations can be specified which are defined by the 3LGM2;

● be able to display the three layers of aHIS model separately but also com-bined in a multi-level view together withthe inter-layer-relationships;

● help to manage even large models bysupporting sub-models for various views;

● provide means for analyzing a complet-ed model;

● provide means for documenting allneeded properties of functions, entitytypes, application components, andphysical data processing componentsand should support this by possibilitiesto create individual catalogs.

That means the modeling tool should ‘know’ the 3LGM2. Consequently, a meredrawing tool would in fact be helpful fordrawing diagrams but would not meet therequirements in total.

More appropriate candidates for toolsmay come from computer aided softwareengineering (CASE). It is widely accepted

to use the Unified Modeling Language(UML). A lot of UML tools are offered bythe industry (e. g. [4]). Using the concept of“stereotypes” [5] could make UML ‘learn3LGM2’. Stereotypes can extend UML’sbase modeling elements and thus extendthe UML meta model layer by classes, i. e.concepts of the 3LGM2. A more generic approach may come from so called metaCASE tools (e. g. KOGGE [6]). A metaCASE tool gets a meta model for a particu-lar class of graphs as input and generates aCASE tool. The generated tool enables theconstruction of exactly those graphs, whichare defined by the meta model.

Hence UML tools as well as metaCASE tools could be used as tools for con-structing 3LGM2 compliant models of hos-pital information systems. But we decided

Fig. 1 The 3LGM2 tool

c It is strongly recommended to read the origi-nal paper [1] to get deeper insight into detailsand the theoretical concepts of the 3LGM2.

Wendt et al.

258


to develop a specific tool because Informa-tion management must not be confusedwith software engineering. Informationmanagers usually do not develop softwarebut plan, direct and monitor heterogeneousHIS. This means in detail:● The full functionality of a CASE tool is

not needed for modeling HIS and a re-duction of complexity is necessary forusers, as e.g. information managers.

● Means for analyzing a completed3LGM2 model and for extracting sub-models cannot be generated by genericapproaches.

● The 3LGM2 implies that models are visualized in a specific way (e. g. dis-playing the three layers of a HIS modelseparately but also in a common viewtogether with the inter-layer-relation-ships). This cannot be achieved by ge-neric meta case tools.

● Models should also (at least in parts) beunderstandable by persons not special-ized in information management, e.g.chief physicians or the CEO (chief exec-utive officer).

The selection of a meta-language and tool for describing the meta model 3LGM2,i. e. the meta-meta model, has been inde-pendent from the decision to develop a particular tool for making 3LGM2 compli-ant models. There are different meta-languages respectively tools for describinglanguages or ontologies (e.g. UML or Protégé [7]).As explained in [1] we decidedfor UML in this case simply because it is

widespread and proved to be sufficient inthis case.

The 3LGM2 Tool

General FeaturesThe 3LGM2 tool is a software product de-signed to create information system modelson the basis of 3LGM2 (Fig. 1). On the mod-eling canvas, which dominates the mainwindow of the tool, an information systemcan be modeled and displayed on threelayers.A model diagram is a graph, i. e. con-sists of nodes and edges.There are differentnode types that correspond to the elementclasses defined in the 3LGM2:1) On the top layer – the domain layer –

the hospital’s enterprise functions andentity types used by these functions aremodeled. An edge between a functionand an entity type symbolizes that thefunction uses or creates informationabout entities of that entity type.

2) The middle layer – the logical tool layer – contains application components,database systems, document collections,component interfaces and communica-tion links between them. An applicationcomponent is an installation of appli-cation software or an implementation of an organizational plan. Applicationcomponents support functions and storedata about entity types in databasesystems respectively document collec-

tions.These relations are modeled expli-citly by linking elements from the logicaltool layer to elements of the domainlayer.

3. The bottom layer – the physical toollayer – contains physical tools: recordshelves, computers, network compo-nents and even personneld, i.e. ‘touch-able’ components of the informationsystems. Physical data processing com-ponents are the basis for applicationcomponents. Similar to the relationsbetween the domain layer and the logical tool layer, relations between thelatter and the physical tool layer aremodeled explicitly by linking model elements.

Each of the element classes function, entitytype, application component, databasesystem, document collection, componentinterface, and physical data processing com-ponent is visualized in the model diagramand has a default geometric shape and a default background color. Since a fixedmapping of shapes and colors to the element types may be too inflexible, userscan● change the default mapping from ele-

ment classes to shapes and colors,● change the shape and the color of select-

ed elements,● assign bitmap symbols to selected ele-

ments, and● change the line style and the color of

selected edges.

A lot of detailed information is not graphi-cally displayed but accessible via the modelbrowser and by dialog windows (Fig. 2).

The three different layers can be viewedand edited separately but can also be com-bined in a multi-level view as shown in Figure 1. Thus, users may focus on a specificlayer but also on relations between the

Fig. 2 A simple domain layer with a function, three entity types and a detail dialog for the entity type “Patient record”

d We apologize for denominating humanbeings as “tools” and “data processing com-ponents”. This scandal seems to be the backside of the same medal showing the very im-portance of non-electronic information pro-cessing in hospitals. We are grateful for hintsand comments leading to a nomenclature mo-re adequate to human diginity.


259


different layers.This feature makes it easierto create an integrated model and presentthis model to partners.The angle of and thespace between the layers in the multilevelview can be adjusted.

Similarly to a lot of other graphicalmodeling tools the 3LGM2 tool also offers ● typical operations for graphical model-

ing, e.g. aligning elements, moving ele-ments up and down, changing colors andfonts, adding icons, etc.,

● a model browser for hierarchical brows-ing through the model structure;

● dialog windows to enter and view de-tailed information about model ele-ments;

● a menu bar and tool bars for accessingcommon operations.

Extraction of SubmodelsDepending on the complexity of an in-formation system and the required level ofdetail the model diagram may easily get un-clear and confusing. The 3LGM2 includesthe functionality to extract subsets of mod-els into submodels.

Submodels are presented in separate di-agrams, have their own model browsertrees and hold own layout data, e.g. elementposition and colors.The data elements fromthe underlying model are not separated,i. e. a change of an element name in a sub-model affects the whole model.

Analyzing ModelsThe 3LGM2 tool provides a set of prede-fined analysis functions (see Table 1).Thesefunctions are designed to answer specificquestions arising in information manage-ment business. The result of an analysis canbe highlighted in the model graphic but also be used to create a submodel.

The analysis feature applies search algo-rithms on the internal graph structure tofind model subsets and paths betweenmodel elements. It takes into account● names and descriptions,● element classes, and● connections to elements of specific

classes.

This feature may be considered as the ma-jor criteria of differentiation from othergraphic and modeling tools. In addition tothe predefined function set the user maydefine customized analysis functions in theanalysis definition dialog.

ExportingBitmap representations of model diagramscan be created via an export operation.Thisfeature makes it easy to embed modelgraphics into slides or report documents. Areport feature to create text lists and tablesis provided: Since the model files are savedin XML format, we integrated an XSLTprocessor to apply XSL transformations to3LGM2 models. The list of extractable information is under continuous develop-ment.

A 3LGM2 Based Model of thePatient Record Management atthe Leipzig University Hospital

Several projects at the UKL focus on thetopic of archiving patient records and ad-ministrative records: While the archives forpaper-based records have to be restruc-tured and to be equipped with a centralized

electronic record management system,an electronic document management andarchiving system shall be implemented toarchive electronic documents and to steptowards the electronic patient record [8, 9].A model of the current sub informationsystem for archiving paper-based and elec-tronic documents may help to assess the situation and to elaborate requirements. Amodel of the target subsystem may help tostate the requirements more precisely andto present them in discussions.

We describe the creation of the model ofthe current state. The model includes thecentral patient record archive, local patientrecord archives at the departments forinternal medicine, children surgery, conser-vative dentistry, children dentistry, and or-thopedics of the UKL, and parts of the information system that are used to fill andmaintain the records. The modeling activ-ities were preceded by on-site surveys inthese departments. We interviewed personsresponsible for record management. Insome of the departments record manage-ment is performed by nurses, in others byspecialized secretaries. Most of the inter-views were not guided by a standardizedquestionnaire but the interviewer was atrained 3LGM2 user.

The model is built in five major steps:

Table 1 Some predefined analysis functions provided by the 3LGM2 tool

Wendt et al.

260


Describing the Domain Layer: Enterprise Functions and Entity TypesFrom the survey data we gathered enter-prise functions and associated entity types(Fig. 3).We describe five of the functions toillustrate how we identified them:1) Register patient record. When a patient is

admitted to the hospital the first time,the ward creates a record. After dis-charge of the patient his/her record is archived. Here we identified the firstfunction: Patient records have to be reg-istered so that they can easily be foundwhen someone needs them. Of course,the records have to be filed when theyhave been registered. Since informationabout a record is created, the functionitself leads to the first entity type:Patient record.Several information about the patientand his/her case are included in register-ing because these information are need-ed when records are searched. Thus weneed two additional entity types: Patientand Case.

2) Lend patient record. When a patient isreadmitted to the hospital, then his or

her patient record, which has beencreated during an earlier case must beavailable on the ward. Usually therecord has already been archived, i. e. ithas to be lent out to the ward. We sub-divided the function into two subfunc-tions:a) Search patient record. An archived

record that ought to be used has to besearched for in the archive. This sub-function is performed in every ar-chive and is part of several otherfunctions. It uses information aboutthe patient and the case the recordbelongs to and information about thepatient record itself, e. g. its location.

b) Register lending. Before handing outthe patient record to a client (ward,laboratory, etc.), the informationabout this patient record is updatedto reflect the new location respec-tively the department that is now re-sponsible.

3) Remind to return patient record. Very often patient records are not returned tothe archive when patients have been dis-charged.The wards have to be remindedto return the records. The reminder in-

cludes information about the patient,the case and the record itself.The recordinformation in the archive is updated toreflect the reminder activity.

4) Register return. The return of a patientrecord is registered, i. e. the record infor-mation is updated. To find the record information that is to be updated, partsof the record information itself and,sometimes, the patient and her/his caseare needed.

5) Add document. Very often documentsare added to records that are already ar-chived. These documents are deliveredto the archive where they are indexedand filed in a record. We subdivided thefunction into two subfunctions:a) Search for patient record. This sub-

function was already describedabove. Of course, the record that willreceive a document has to besearched for.

b) Create document description (index-ing). Index information helps to find documents. They are createdwhen documents are added to therecord.

When modeling information systems it maybe necessary to distinguish organizationalunits.They are also modeled on the domainlayer, but not shown on the modeling canvas.

During the process of identifying func-tions and entity types we complied with thefollowing principles:1) A function usually needs information

and creates or changes information. In3LGM2 terminology: A function uses orupdates at least one entity type. Themost of the functions use AND updateentity types.

2) An entity type indicates that the infor-mation system contains informationabout real life objects or abstract thingsof a specific kind but not the objects orabstract things itself.

3) Functions may be subdivided into sub-functions (part-of-association). A set ofsubfunctions should describe its superi-or function completely.

Fig. 3 The Domain Layer of the sub information system for archiving


261


Describing the Logical Tool Layer: Application ComponentsIn the previous section we describedWHAT is done in the context of patientrecord archiving. We now focus onWHEREBY functions are performed andWHERE data are stored. In this section westart with application components on thelogical tool layer.

Our survey yielded a heterogeneous in-formation system with a lot of differentcomputer-based and paper-based applica-tion components. We describe those of thearchive section of the Department forInternal Medicine to illustrate how weidentified application components (Fig. 4):

Patient record archive INZ. The patientrecord archive of the Department for Inter-nal Medicine (INZe) is modeled as an appli-

cation component with four subcompo-nents:a) Record management system INZ (INZ/

Access). This computer-based applica-tion component is used to document the locations of patient records and isneeded for the function Search patientrecord. It will be replaced by the newRecord management system INZ (INZ/ZA/Archive) after a period of parallelusage.

b) Record management system INZ (INZ/ZA/Archive). This computer-based ap-plication component is used more gen-erally: to perform Register patientrecord, Lend patient record, Register re-turn, and Add document.

c) Record lending management systemINZ. Every lending of a record is docu-mented on a lending form that is de-stroyed after the return of the record.This paper-based application compo-nent is used in parallel to the Recordmanagement system INZ (INZ/ZA/Ar-

chive) to perform Lend patient recordand Register return.

d) Archive operation INZ. This paper-based application component coordi-nates the operation of the previously described components. It is needed forcommunicating with wards, outpatientcare sections, external institutions likeinsurances, etc. There are no computer-based interfaces for communicationwith these partners.

The superordinate component Patientrecord archive INZ only aggregates its subcomponents and does not have an owndatabase system or own interfaces.

The application component details aredescribed using the tabs in the associateddialog windows.The list of application com-ponents described above includes two ele-ments named Record management systemINZ: One component based on the soft-ware product MS Access customized bystaff members of the archive and one based

Fig. 4 A part of the logical tool layer of the sub information system for archiving

e INZ is the abbreviation of the German department name “Zentrum für Innere Medizin”

Wendt et al.

262


on a software product created by the headof the central archive department. The cor-responding application program descrip-tions hold information about the adapta-tion of the software product. All of the foursubcomponents of Patient record archiveINZ have a database system respectivelydocument collection. The computer-basedrecord management system that was imple-mented using MS Access, for example,stores datasets of the type Patient recorddescription INZ/Access in its database. Thepaper-based record lending managementsystem stores documents of the type Lend-ing form. The dataset type and documenttype model elements are mainly needed tolink database systems to entity types on the domain layer (see section about linkingapplication components to enterprise func-tions and entity types).

Another important part of the applica-tion component description is that aboutinterfaces. The application component Ar-

chive operating INZ, for example, commu-nicates documents of the type Lendingform with the component Record lendingmanagement system INZ when records arereturned to the archive. It communicatesmessages of the type Visual data output(Patient Record description) when patientrecords are searched. Similar to datasettype and document type model elements,message type elements can be linked to en-tity types.

The model shows the dual role of docu-ment type elements:They cover the storageaspect AND the communication aspect ofpaper-based data representations. Comput-er-based data representations are dividedin dataset types for storing and messagetypes for communicating.

During the process of identifying appli-cation components we complied with thefollowing principles:1) Application components can be imag-

ined as aggregation of

– algorithms that describe how a func-tion (or a number of functions) is tobe performed

and, not necessarily but typically,– a storage that holds data represent-

ing the information needed to per-form the functions(s) and/or

– component interfaces to communi-cate data to other application compo-nents.

2) Identifying application components de-pends on the required level of detail of amodel. An application component doesnot necessarily have to have a databasecomponent/document collection ANDinterfaces, but should have at least oneof them. But: Application componentsthat aggregate other application compo-nents via the Part-of-association shouldnot have own storage components orinterface components.

Fig. 5 Links between the enterprise function Register lending and application components


263


Linking Application Components toEnterprise Functions and Entity TypesIn the chapter about requirements and ap-proaches we emphasized that the 3LGM2

defines relations to link the different layers.The links between the domain layer andthe logical tool layer describe– which application components are need-

ed to perform what functions and– which database systems respectively

document collections store what entitytypes, i. e. information.

In the Department for Internal Medicinethe function Register lending is performedby the application components Archive

operating INZ, Record lending manage-ment system, and Record managementsystem INZ (INZ/ZA/Archive) in combina-tion (Fig. 5). The function Remind to returnpatient record is performed by the compo-nents Archive operating INZ and Recordlending management system in combina-tion.

Via the dataset types and documenttypes the entity types are linked to data-base systems respectively document collec-tions. The entity type Patient record, for example, is linked to the dataset typesLending form and Patient record descrip-tion INZ/Access. Via message types anddocument types the entity types are linkedto component interfaces. The entity type

Patient record is additionally linked to themessage types Manual data input (Patientrecord description) and Visual data output(Patient record description).

During the process of identifying linksbetween application components and en-terprise functions/entity types we compliedwith the following principles:1) As defined in the 3LGM2, functions are

linked to application component config-urations, which may contain one or several application component(s). Thisconcept is used to express that perform-ing a function may need more than oneapplication component. There may bealternative configurations for the samefunction.

Fig. 6 A part of the physical tool layer of the sub information system for archiving

Wendt et al.

264


2) As defined in the 3LGM_, entity typesare linked via dataset type and docu-ment type to database systems. Messagetype and document type are used to linkentity types to component interfaces.

Describing the Physical Tool Layer:Physical Data Processing Components

On the physical tool layer we describe thephysical data processing components thatare needed to operate the application com-ponents described on the logical tool layer.For the Archive Section of the Departmentfor Internal Medicine our survey yielded

the following physical data processing com-ponents (Fig. 6):1) Staff INZ. In the archive section there

work two persons.2) Storehouse INZ (…). The patient rec-

ords of the Department for InternalMedicine are stored in four storehouses.The primary storehouse contains inpa-tient records of the past three years;the secondary storehouses contain olderinpatient records and outpatient rec-ords.

3) PC 1 INZ, PC 2 INZ. There are two per-sonal computers that are not connectedto a network.

4) Lending note folder. Lending notes arestored in a standard office folder.

5) Fax machine INZ, Copier INZ. A faxmachine and a copier are used as physi-cal base for copying and sending or-dered documents.

The model expresses ONE of two roles ofstaff members in relationship to the infor-mation system: As part of the informationsystem they are modeled on the physicaltool layer. We describe persons as part ofthe information system when they executeorganizational plans to have paper-basedapplication components run. The 3LGM2

does not define elements to model staff mem-bers as users of the information system.

As every data transfer is carried out bythe staff members we modeled physical

Fig. 7 Result of the analysis searching the sub information system for patient record archiving in INZ, inpatient section, presented in a submodel window


265


data transfer connections between StaffINZ and the other physical data processingcomponents.

Also for physical data processing com-ponents there are associated dialog win-dows to describe details. The componentPrimary storehouse INZ, for example, is located on the ground floor of building no.4271. It has the component type Store-house. For computers there is a tab withtechnical details about the operating sys-tem, memory, etc. PC 1 INZ, for example,has the operating system Windows 98, amemory capacity of 128 MB, and a PentiumIII processor.

During the process of identifying physi-cal data processing components we com-plied with the following principles:1) All devices like PCs, server computers,

copiers, fax machines, etc. should bemodeled as physical data processingcomponents.

2) Depending on the required level of de-tail devices may be combined to abstractcomponents without modeling everyphysical part. For example, instead ofrecord shelves, cartons, etc. a modelcould contain elements describing theircombination as a storehouse.

3) When persons act as part of the informa-tion system, i. e. execute organizationalplans to have paper-based applicationcomponents run, they should be mod-eled as physical data processing compo-nents.

Linking Physical Data ProcessingComponents to ApplicationComponentsThe links between the logical tool layer andthe physical tool layer describe what physi-cal data processing components the appli-cation components are installed on, i. e.what persons, computers, record shelves,etc. are needed to have the applicationcomponents run.

In the Department for Internal Medi-cine the paper-based application compo-nent Record lending management systemINZ is installed on the physical data pro-cessing components Lending note folder,

PC 1 INZ and Staff INZ in combination.The computer-based application compo-nent Record management system INZ(INZ/ZA/Archive) is installed on the com-ponent PC 1 INZ.

At a first glance it may be confusing that we added the item Staff INZ to thecombination of physical data processingcomponents needed to run Record lendingmanagement system INZ, but not to a combination of components needed to runRecord management system INZ (INZ/ZA/Archive). We had in mind that – an application program controlling a

computer-based application componentis usually executed by computers that inmost cases also include the physical media to store data, while

– an organizational plan controlling apaper-based application component isusually executed by persons who needadditional physical media to store data.

During the process of identifying linksbetween physical data processing compo-nents and application components we com-plied with the following principles:1) As defined in the 3LGM2, application

components are linked to physical dataprocessing component configurations,which may contain one or several physi-cal data processing component(s). Thisconcept is used to express that an appli-cation component may be installed onmore than one physical data processingcomponents. There may be alternativeconfigurations for the application com-ponent.

2) Computer-based application compo-nents usually need computer(s) but nopersons to run; paper-based applicationcomponents usually need persons andadditional physical tools.

Using the Model: Analyzing and PresentingIn the previous chapter we described thesteps for creating a 3LGM2 model. Now wewant to show how the modeling effort mayremunerate by extracting useful informa-tion from our model. We try to answer twoquestions.

(Q1) Our model describes the sub infor-mation system for patient record archiv-ing in several organizational units. Thedirector of the Department of InternalMedicine wants to know the subsystemonly for his department.

In terms of the model structure the ques-tions may be formed like “Which functionsare linked to the organizational unit INZ,inpatient section, which entity types arelinked to these functions, which applicationcomponents (including detail informationabout database systems, interfaces, etc.) arelinked to these functions, and which physi-cal data processing components are linkedto the selected application components?”

As already described in the chapter in-troducing the 3LGM2 tool, there is a libraryof predefined queries. In case there is nopredefined query fitting our question, onemight define it in the analysis dialog andadd it to the analysis repository. Figure 7shows the result of the query in a submodelwindow.

(Q2) An important aspect of informa-tion management is the reliability of ap-plication components. In this contextone might ask: Is searching of patientrecords at the department INZ, inpa-tient section, still supported by comput-er-based application components whenPC 2 INZ fails?

To answer this question we have to create aquery similar to the first one. We wouldhave to add an additional restriction: Fromthe functions only Search for patient recordshall be included. The result submodelshows that for searching patient recordsthree application components are needed.One of them (Record management systemINZ (INZ/Access)) is installed on PC 2INZ. Without any detail information theanswer to our question would be “NO”.But the description text for Record man-agement system INZ (INZ/Access) explainsthat the information found only in this application component is transferred toRecord management system INZ (INZ/ZA/Archive).

The presentation capabilities are veryimportant for using query results. In thechapter introducing the 3LGM2 tool we

Wendt et al.

266


already mentioned the multilevel presenta-tion feature. The three levels of a modeland connections between them can be presented in one diagram. It is not difficultto imagine that the graphical presentationfeatures are less informative for complexmodels. The submodel feature makes thegraphical presentation more valuable: As apresentation of the entire archive modelproved to be confusing, a presentation of asubmodel for each organizational unit wasuseful.

The XSL-based export feature men-tioned above may also increase the reus-ability of models: via text lists and tablesthe model data can easily be transferred totext processors.

DiscussionWe presented a prototype of the graphical3LGM2 tool which is to build comprehen-sive 3LGM2 compliant models and intendsto support information management espe-cially in hospitals.We reported on modelingthe sub-information system of the UKL for archiving paper-based and electronicdocuments of the patient record. Using themodel as an example, means for analyzingthe model and reducing its complexitycould be demonstrated.

But in our modeling activities we havebeen confronted with two major challeng-es:1) Hospital functions and entity types: As

already stated in [10], determining hos-pital functions and entity types “is a taskthe complexity of which should not beunderestimated”. It is important to keepin mind, that an information systemmodel should contain only those enter-prise functions that deal with informa-tion processing. Hence, the entity typesrepresent information about e. g. patientrecords, but do not represent the recordsthemselves. Publications like [11] mayhelp to create better ‘formulas’ to findfunctions and entity types. A more valu-able approach may be the developmentof reference models for the domainlayer of hospital information systems.They could base on common standards

[12] like the Reference InformationModel (RIM) of the HL7 standard [13]and the Good European Health Record(GEHR) [14] and on the requirementsindex for information processing in hos-pitals [15].

2. Paper-based application components:3LGM2 claims to consider not only com-puter-based but also paper-based infor-mation and data processing in hospitals.Consequently we introduced paper-based application components as ananalogy to computer-based applicationcomponents.Whereas it is no problem toidentify a computer-based applicationcomponent, which is an installation of asoftware product, it is difficult to identi-fy paper-based analogies. It turned out,that (sub-)organizations dealing with in-formation processing in the hospital canusually be considered to be paper-basedapplication components. Again the de-mand for better ‘formulas’ respectivelyfor reference models arises. A referencemodel for the logical tool layer shouldalso provide users with catalogues ofmessage- and event-type combinations –basing on HL7, DICOM, etc.; this wouldreduce efforts for modeling interfacesdramatically.

The model proposed here has been devel-oped in the context of applying for gettingfinancial support for a new digital Docu-ment Management and Archiving Systemfor the UKL. Diagrams like in Figure 5 havebeen used to illustrate the current and fu-ture way of integration. But our experienceshowed clearly, that it cannot be recom-mended to use 3LGM2 and the 3LGM2 toolfor illustration purposes only. Real benefitgains only from continuously documentingthe knowledge of the information system ina clearly structured way and therefore fromusing the 3LGM2 tool as a valuable reposi-tory of knowledge about the hospital andits information system. The usage of the3LGM2 tool itself seemed to be rather trou-ble-free. Certainly, this can be traced backto the fact that the developers of the3LGM2 and the 3LGM2 tool were part ofthe project team and could directly help if any technical or handling problems ap-peared.The general usability of the 3LGM2

tool has to be analyzed in the context of anevaluation study incorporating informationmanagers of other healthcare organiza-tions.

Currently we are working on some en-hancements to increase usability; this isstrongly influenced by the collaborationwith Austrian consultants applying the toolin two projects. A template library for com-mon model elements, based on the refer-ence models mentioned above, may short-en the modeling process. Exporting fea-tures as mentioned in the chapter about the3LGM2 tool will ease to reuse the modeldata in other documents. The current re-search activities on the 3LGM2 include,for example, the coverage of business andcommunication processes and the coverageof different architectural styles for informa-tion systems, especially for better modelingthe interaction between application com-ponents.

AcknowledgmentsThis work is part of the research project ‘Integra-tive modeling of structures and processes in hos-pital information systems’ supported by theDeutsche Forschungsgemeinschaft (DFG), grantno. WI 1605/2-1.

We thank the people doing their importantjobs in the patient record archives for their coop-eration. We also thank our partners at the Uni-versity for Health Sciences, Medical Informaticsand Technology and the Information Technologyfor Healthcare GmbH (Innsbruck, Austria) forfruitful discussions about the functionality of the3LGM2 tool.

References1. Winter A, Brigl B, Wendt T. Modeling Hospital

Information Systems (Part 1): The RevisedThree-Layer Graph-Based Meta Model3LGM2. Methods Inf Med 2003; 42: 544-51.

2. Winter AF, Ammenwerth E, Bott OJ, Brigl B,Buchauer A, Gräber S, et al. Strategic Informa-tion Management Plans: The Basis for system-atic Information Management in Hospitals.International Journal of Medical Informatics2001; 64 (2-3): 99-109.

3. Berg M. Patient care information systems andhealth care work: A sociotechnical approach.International Journal of Medical Informatics1999; 55: 87-101.

4. Quatrani T.Visual Modeling with Rational Rose2002 and UML. Boston: Addison-Wesley; 2002.

5. Heverhagen T, Tracht R. Using Stereotypes ofthe Unified Modeling Language in Mechatron-ic Systems. In: Proc. of the 1. International Con-ference on Information Technology in Mecha-


267


tronics, ITM’01, October 1-3, 2001, Istanbul,UNESCO Chair on Mechatronics. Istanbul:Bogazici University, Istanbul, Turkey; 2001;pp. 333-8.

6. Ebert J, Süttenbach R, Uhe I. Meta-CASE inPractice: a Case for KOGGE. In: Olive A,Pastor JA (eds.). Advanced Information Sys-tems Engineering, Proceedings of the 9th Inter-national Conference, CAiSE’97, Barcelona,Catalonia, Spain, June 16-20, 1997. 1250 ed.Berlin; 1997; pp. 203-16.

7. Noy NF, Grosso W, Musen MA. Knowledge-Acquisition Interfaces for Domain Experts:An Empirical Evaluation of Protégé-2000.Twelfth International Conference on Soft-ware Engineering and Knowledge Engineering (SEKE2000), Chicago, IL, 2000.

8. Dujat C, Schmücker P, Haux R, Winter A. Digi-tal Optical Archiving of Medical Records inHospital Information Systems – A PracticalApproach towards the Electronic Patient

Record? Methods Inf in Med 1995; 34 (5):489-97.

9. Atkinson CJ, Peel VJ. Transforming a hospitalthrough growing, not building, an electronic patient record system. Methods Inf Med 1998;37 (3): 285-93.

10. Winter A, Haux R. A Three-Level Graph-Based Model for the Management of HospitalInformation Systems. Methods Inf Med 1995;34 (4): 378-96.

11. Spewak SH, Hill SC. Enterprise ArchitecturePlanning: Developing a blueprint for Data,Applications and Technology. New York: JohnWiley & Sons; 1992.

12. Klein GO. Standardization of health informat-ics – results and challenges. In: Haux R,Kulikowski C (eds.). Yearbook of Medical Informatics 02. Stuttgart: Schattauer 2002,pp. 103-114.

13. Schadow G, Russler DC, Mead CN, McDonaldCJ. Integrating medical information and knowl-

edge in the HL7 RIM. Proc AMIA Symp 2000:764-8.

14. Griffith SM, Kalra D, Lloyd DS, Ingram D. Aportable communicative architecture for elec-tronic healthcare records: the Good EuropeanHealthcare Record project (Aim projectA2014). Medinfo 1995; 8 Pt 1: 223-6.

15. Ammenwerth E, Buchauer A, Haux R. A Re-quirements Index for Information Processingin Hospitals. Methods Inf Med 2002; 41 (4):282-8.

Correspondence to:Thomas WendtInstitute for Medical Informatics, Statistics and EpidemiologyUniversity of LeipzigLiebigstr. 2704103 LeipzigGermanyE-mail: [email protected]

wendt: modeling hospital information systems (part 2 ... · modeling hospital information systems...

Documents