Software Tools for Rapid Development and Customization of Medical Information Systems

Petar Rajkovic, Dragan Jankovic, Tatjana Stankovic

University of Nis, Nis, Serbia {rajkovicp,draganj ankovic,tanja} @elfak.ni.ac.rs

Abstract - We present data modeling and code generation tools

for easier and faster development and customization of electronic

health record (EHR) based medical information systems (MIS). In development of MIS, it is usually necessary to create a large

number of different, but somewhat similar, graphical user inter­

face (GUI) forms and database tables corresponding to different

medical data. This process can be inefficient and time consuming.

Our software tools enable power users to define meta data mod­els, from which the tools automatically generate database tables,

data object model classes and several common components (input

forms, selection components, components for tracking measured values, reporting profiles, access control configurations) for

EHR-based MIS. While we first developed these tools for clinical

and ambulatory MIS in Serbia, they can be used in other coun­

tries, due to the built-in flexibility and multi-language support.

Keywords-electronic health record (EHR), medical information system (MIS), code generation, rapid application development

I. INTRODUCTION AND MOTIY A TION

In medical information systems (MIS), collected medical data has greater scientific significance than any other data (e.g., financial payment data). Apart from being used for medical (and, more generally, healthcare) decisions, the collected medi­cal data can be used in different ways for subsequent research and in education of future medical staff.

To enable entry of various relevant medical data and gener­ation of appropriate reports, MIS should support diverse healthcare procedures/processes. The diversity of medi­callhealthcare processes causes the need for a large number of different graphical user interface (OUI) forms. For example, there are many medical specializations and they involve differ­ent medical processes, each one of which could be associated with many different medical examinations, lab analyses, thera­peutic treatment reports and many other different documents [1]. Usually, each data entry form should have a mapping to a table in the MIS database. For different forms, it often means that different tables in the MIS database have to be created. However, in addition to differences, the required forms and thus data tables usually have many similarities. Creating many

The presented medical infonnation systems and tools are results of projects supported and funded by the Ministry of Science and Technological Development of the Republic of Serbia.

NICT A is funded by the Australian Government as represented by the De­partment of Broadband, Communications and the Digital Economy and the Australian Research Council through the ICT Centre of Excellence program.

Vladimir Tosic

NICTA & University of New South Wales, Sydney, Australia vladat@computer.org

similar data tables and supporting forms can be an annoying and long process. Therefore, we decided to develop software tools that make this development faster and more reliable. These software tools are the focus of this paper.

Closely related to the need for rapid development of MIS is the need for customization of MIS, which is also associated with generation of various forms and data tables. Several ways of customization can occur. One of them is customization of MIS developed in one country to the healthcare system and lo­cal circumstances in another country. This involves translation of forms to different languages, but oftentimes also adjustment of the structure of various forms (and database tables). We ana­lyzed several existing MIS solutions and realized that adminis­trative and insurance-related parts of MIS are usually country specific, while the MIS parts for collection of medical data (e.g., from medical examinations) often have significant simi­larities (along with some variations that require customization). The need for customization also exists within a single health­care system, when MIS is tailored to specifics and processes in particular healthcare organization (e.g., hospital or ambulant). MIS have much greater chance for practical acceptance when they are customized to the existing healthcare processes and work habits of medical personnel than when medical personnel has to modify their work to comply with the MIS [3]. Thus, there is a need for software tools that not only enable rapid de­velopment, but also easy customization of MIS.

Since 2002, our research group has worked on a number of projects [2, 3, 4, 5, 6] for developing MIS in Serbia, in which the needs for software tools for rapid development and custo­mization of MIS were very prominent. For example, our 2002 MIS for medical data acquisition and reporting in cardio, neu­rological and pediatric clinics in Nis [5] supported specialist doctors with around 150 different examinations and analysis reports kept within a general patient record of hospitalization. Then, in 2008 the Serbian Ministry of Science started a new project [2] to extend our 2002 MIS by implementing specialist support modules for other clinics, including also support for the ambulatory part of the Serbian public healthcare system [3] and introducing effective collaboration and data exchange proce­dures between various clinics and ambulatory institutions. While this new project built upon the previously developed MIS, it required many new forms and reports with appropriate mapping database tables in the background. While there are off-the-shelf form generators, such as Microsoft's Data Form Wizard and OnyakTech's H20, they can only generate forms with all fields from related database tables with basic

978-1-4244-6376-3/10/$26.00 ©2010 IEEE

add/update/delete/navigate options. We needed much more in our MIS: powerful custom form functionalities to fit into our system, more flexible ways to access data, filtered access data from multiple tables, version tracking, specialized selection components, reporting profiles, generation of both Windows and Web forms at the same time, and defining and incorporat­ing objects in the data object model. Since no off-the-shelf tools or routines from the used development environment satis­fied our needs, we decided to follow the modeling methodolo­gies from [7, 8] and develop data modeling and code genera­tion tools that speed up MIS development in our projects and are suitable for developing similar MIS. In particular, due to the similarities in healthcare systems in countries of former Yugoslavia [3], the applicability of our solutions in various countries was our goal from the beginning. Another significant characteristic of our new MIS is high level of customization through different configurations.

In the next section of the paper, we present an overview of our solution. In Section III, we summarize the main aspects of the data modeling tool. In Section IV, we focus on the code generation tools that automatically create data object model classes and several common components (input forms, selec­tion components, components for tracking measured values, reporting profiles, and access control configuration options) in MIS. In Section V, we describe how we evaluated (verified and validated) our data modeling and code generation tools. The last section summarizes conclusions.

II. SYSTEM OVERVIEW

Since we have been involved in development of several MIS in the past, our general strategy in development of new MIS systems is to support partial reusability and extensibility of past solutions (e.g., the base EHR and administrative parts of the MIS described in [3]), where appropriate. The general ar­chitecture of our MIS is organized into several layers [3]: data­base (Microsoft SQL Server 2005), data object model (Micro­soft Entity Framework), virtual EHR, synchronization services and end user (e.g., doctors', nurses') applications and modules. To make our MIS useful in complex healthcare systems with many different specialists, we enabled plug-in addition of spe­cialists' supporting modules (SSM), but these modules require many different Windows forms and other Gill components. Our generator tool helps in rapid development and customiza­tion of various Gill components and database tables for these modules. In this way, the development of new components for our new MIS is more efficient than starting development from the beginning. It also results in fewer development errors (e.g., in mappings between database tables and code that manipulates this data) and a uniform end user interface.

Before we give a system overview, it is important to ex­plain who is actually involved in the development and custo­mization of our MIS. We distinguish between power users who apply the data modeling and generator tools and end users who simply work with (e.g., enter data into) the resulting MIS. The end users are medical professionals, such as general purpose (GP) doctors, specialist doctors, nurses, laboratory technicians, etc. They need to know medical processes/procedures and oth­er healthcare domain knowledge. Our MIS does not assume high computer literacy of these end users (as explained in [3],

in developing countries such as Serbia computer literacy among medical professionals is low) and we adapt our MIS to their existing work practices instead of requiring from them ex­tensive training in using our MIS. On the other hand, the power users of data modeling and generator tools must have some knowledge and understanding of both the medical domain and IT systems (particularly MIS). IT knowledge is particularly ne­cessary for the use of the generator tool, because it creates dif­ferent software components. Contrary, the results of the data modeling tool (e.g., used terminology, modeled fields, and val­ue ranges) must be developed under supervision and validated by medical experts because these models represent domain­specific knowledge from some field of medicine. In many cas­es, these power users are IT professionals working in medi­callhealthcare facilities (e.g., as system administrators or de­velopers of custom MIS software). Medical professionals with good understanding of IT can also be power users. Oftentimes, no single individual has the right combination of medical and IT knowledge and then a "power user" is actually a small team of medical and IT people with complementary expertise.

reJXlrts Model

Storage Database

Main Database

Entity Framework object

Translation resources

Reporting profile

Windows form

Selection component

Configuration profile

Measured value tracking component

Figure 1 . Developed tools and generated components

The data modeling tool and the generator tool are two Mi­crosoft .NET libraries combined in one Windows forms appli­cation. Relations between these tools and the generated com­ponents are shown in Figure 1. The development process is:

• A power user defines a meta data model using the data mod­eling tool and save is as an XML (Extensible Markup Lan­guage) file or tables in a model storage database.

• The power user starts the generator tool to create the actual tables in the main database, based on the saved meta data model. In case of minor changes in the meta model, the main database tables are only updated.

• The generator tool automatically generates (or, in case of minor changes, updates) the data object model (entity framework model classes) and updates the data access and manipulating library.

• The generator tool automatically generates input value selec­tion components, Windows and ASP.NET Web forms, com­ponents for tracking changes of measured values, and trans­lation resources for multi-language support.

• These generated components are incorporated into the com­ponent library and can be attached to the Microsoft .NET project containing code (including all custom-made controls) of the target MIS application.

• The generator tool produces a reporting profile that can be used for report generator by our reporting tool [4]. This re-

978-1-4244-6376-31101$26.00 ©2010 IEEE

porting profile is stored in the resource folder of the report generation tool.

• The generator tool also produces an access control configu­ration profile for a configuration tool. In the generation process, a power user can set which configuration profile elements can be configurable and associate some basic ac­tions to them (display, add, edit, delete). At run-time, the configuration tool enables application and creation/change of end user access control profiles.

• When the target MIS application is built, the generated com­ponents can be included into different end user modules. The power user can later modify the generated components and continue building and customizing the MIS application.

The use of the generated components is not limited to our MIS. All these generated components can be used independent­ly in development of other systems, since the generator tool can create each of them as an independent file, which can be added to any .NET project. The only requirement that needs to be fulfilled for the proper work of the generated components is that the target application has a data object model developed based on the generated database tables.

Our software has advantages over both the commercial form generators (e.g., Microsoft's Data Form Wizard, Onyak­Tech's H20) and previously published academic work. In par­ticular, [9] described a way to automatically generate visual components based on a predefined model. Their generation process results in Microsoft Access Application objects that have customizable forms. Similarly, [10] presented a system based on meta-data driven automatic generation of user inter­faces and discussed differences between static and dynamic ta­ble-based mapping, pointing advantages and disadvantage of both solutions. In static table mapping, one table is generated for each entity defined in the meta-model (in our case, medical records, medical record items, and medical documents). In dy­namic table-based mapping, there are few general-purpose and reusable tables with numerous fields, each mapping to attributes from the meta-model (in our case, medical record item elements). Due to the higher speed (important for big MIS), we chose to use static table-based mapping. While our software is based on ideas similar to [9, 10], it offers much more flexibility, due to generation of both Windows and Web forms, usage of the data object model, generation of additional components (e.g., for data selection, tracking of measured val­ues), reusability of the generated components in various inde­pendent (possibly unforeseen) target applications, compatibility with multiple databases, and multi-language support.

III. THE DATA MODELINO TOOL

Our data modeling is based on the electronic health record (EHR), for which we use the term "medical record". One pa­tient can have more than one medical record, while one medi­cal record is by default linked to only one patient. (This is con­sistent with the organization of the public healthcare system in Serbia and neighboring countries. However, to increase appli­cability of our data models in other countries, we also enabled that more than one patient can be associated with a single med­ical record, e.g., for family medical records.) Usually, the main medical record is the one kept by the patient's general purpose

(GP) doctor. It contains full history of any noted illness, pre­scribed medications, the list of immunizations, the list of aller­gies, notes about hospitalizations, and other general medical data. Beside the main medical record, some departments (such as dental service, gynecology, and pediatrics) can keep addi­tional medical records related only to their scope.

In our data models, all medical records are represented with classes derived from the base medical record class (BaseMedi­calRecord) that contains general properties and is inherited by specific medical records (e.g., GynecologyRecord). A medical record is a collection of data from different medical procedures and each such data item is a medical record item (MRI). The base class for medical record items (BaseMedicaIRecordltem) is inherited by specific classes (e.g., CTMInfarctuscerebriEx­amination). Thus, all medical treatments, examinations, analys­es, procedures, and processes result in a creation of a medical record item. Both medical records and medical record items can contain medical documents. The base class for medical documents (BaseMedicalDocument) can be inherited by specif­ic documents (e.g., LabAnalysisRequest). These hierarchies are illustrated in a figure posted on our project's Web page [2].

MedicalRecordltemElementRange

lowerUmit UpperUmit RangeName

+Ranges TargetGroup

+Mea surementUnit 1 1· 1 + Transla';.,.,s

1

MeasurementUnit MedicalRecordltemElement Translations EHRTranslation 1 Name 1+ TranslationLanguage +Name

Mark +Type Description

1 • t+TranslationValue

+Translalions +Description

Hranslation 1 ; +Elements

Medic:alRecordHeader MedicalDataConlainer

Name Descript ion

�

+Define �MedicalRecords ,....----J:> 1 MedlcalRecordSupportlngDocument MedicalRecordltem

1 +ReouestedDocuments I

OefinedMedicalOocumenls T . +GeneratedDocuments 1 +AnalyzesAndExaminations

EHRMetaModel

+Oefaultlanguage +Intemallndex

1 +lsActive +ModelDescription +ModelName 1 +SupportedLanguages +TranslationResourceFile

Figure 2. EHR meta model structure

To enable easier extensions of data models and their changes and updates (e.g., when during modeling the involved medical professionals realize that some medical information is not appropriately captured), we defined a meta data model that helps and guides definition of medical records, medical record items, and medical documents with all necessary sub-elements. The main parts of this meta data model are shown in Figure 2. The meta data model is defined as a serializable class EHRMe­taModel that contains lists of medical records, medical record items, and medical documents as well as general information about the model (name, description, list of supported languag­es, indicator if the model is active). The classes MedicalRe­cordHeader and MedicalRecordltem define data for different medical examinations, lab analyses, and therapeutic treatments. MedicalRecordSupportingDocument is the base class for defin-

978-1-4244-6376-3/10/$26.00 ©2010 IEEE

ing different medical documents associated with medical record items. The 3 mentioned classes inherit the MedicaLDa­taContainer class. Each MedicalDataConatiner object (in­stance) has a list of properties stored as instances of the class MedicalRecordltemElement. Each of medical record item ele­ments has a name, type, description and measurement unit, and is associated a list of boundaries of normal values, stored in in­stances of the MedicalRecordltemElementRange class. Our modeling approach supports two different types of ranges -regular and ENUM ranges. Regular ranges are defined as or­dered pairs of lowest and highest regular value associated with some target group (e.g. infants, children under 6 years, adults). ENUM ranges (not shown in Figure 2) are used to define cata­logs of allowed values for related medical record item element. There is also multi-language support (see IY.E) through in­stances of the EHRTranslation class, each keeping name of the field to be translated and the term in the destination language.

MedlcalRecordItem [oliectlOn Editor ���

Members:

���l!:l -.!J R eumatoloski pregled

EKG � EEG

Echo Radiologi ia

H ematologiia

Kardioloski pregled eho srea Licna anamneza

preg�e� u savet�vali;t� za � e,dd Bemove

Kardioloski pregled sreane mane ,Qloperties: � A I I ' 1 0;: I. t ---1 El Misc

Description

Elements (Collection)

GeneratedDoeurr (Collection)

ItemDescription

-

Name Kardiolo.ki pregled

RequestedDoeun (Collection)

T ran.lation. (Collection)

Type examination

OK Cancel I " 1-";;"_..1 ___ ---' ,&

Figure 3. Data modeling tool � definition of a MedicalRecordltem instance

The data modeling tool is the application used for defining instances of the presented EHR meta model. Figure 3 shows how this tool is used for defining an instance of the Medica­IRecordltem class. On our project's Web page [2] we posted an additional figure that illustrates how the data modeling tool can be used for defining instances on different hierarchical levels (EHRMetaModel, MedicalRecordltem, MedicalRecordlte­mElement, and MedicalRecordltemElementRange) of the meta data model. Such meta modeling offers the possibility to per­form various extensions in a uniform and consistent way. It al­so enables our generator tool (explained in the next section) to automatically create a separate object model class, database ta­ble, and GUI form for each MedicalDataContainer object. Since this generated code is stored in a separate library, it can be reused in different MIS.

An additional feature of the data modeling tool enables cre­ation of an EHR meta model from a specific database. (This is opposite from what the generator tool does.) After a power user specifies Object Linking and Embedding (OLE) connection settings and relevant database table names, our modeling tool examines the database structure and automatically creates or updates the corresponding EHR meta model. The tool can au­tomatically resolve situations when changes are detected only on one side (in the database or in the EHR meta model), but when changes are found on both sides, it presents the list of changes to the power user and ask herlhim for guidance in merging the two versions.

IV. THE GENERATOR TOOL

As already mentioned, the data modeling tool prepares in­put for the generator tool that generates tables in the database and related classes and forms used in the further development process. The purpose of the generator tool is to enable automat­ic generation of some parts of MIS modules and, thus, speed up the development and customization process. Before the genera­tion of any application module starts, the power user can choose the programming language for the generated .NET project, from the languages supported by the Microsoft's Co­deDom library. The generator tool connects to the database us­ing an OLE DB provider, examines and verifies its structure, and then generates all requested elements. Currently, the gene­rator tool supports only databases supported by the Microsoft Entity Framework but it can be easily adapted for use with any database supporting OLE. In that case, the power user should define parts of its data object model using external tools. Be­fore the table generation process starts, the power user has to enter a few necessary parameters (e.g., OLE connection set­tings) and to select tables that are related to the base medical record and the base medical document. After this, the power user can start specifying the structure of the new medical records and documents, including the corresponding ele­ments/fields and data ranges. When this definition process is finished, the power user can run the table generation process. This process generates new tables in the database and saves the model in an XML file. Once the data model is mapped into the database, it can be used by a MIS. Generator tool's customiza­tion screen is shown in Figure 4. The following sub-sections explain how the customization is performed.

!!] Generator tool- Customrzation .'

Select data table IPaedi atricRecord [Data object model class

Name Ip ,'ho

P" same as table name

Field 1 I"",O<dCode Field 2 l�artDate Field 3 I(empty)

Generate forms rv generate Win form �

Translations rv Enable multilaoguage support r Generate single language form �G....-ate ReportER definition module P' Generate ReportER definition module

-

--. = ---.� -= = .= .-�

rv generate ASP.NET Web form

Delault language ISR i1 Choose language ISR i1

Figure 4. Generator tool - customization form

A. Creation of data object models

A data object model is a set of classes generated from data­base tables and enabling communication with the database. Usually, each class represents one database table and class attributes map table's columns, while class methods allow ex­ecution of basic SQL (Structured Query Language) operations (selectlinsertlupdate/delete) over table's records. In our soft­ware, database tables are created from an EHR meta data mod-

978-1-4244-6376-31101$26.00 ©2010 IEEE

el and then the data object model is generated (or updated) from these tables. Power users can define data object model generation options applicable either to all database tables or on­ly to a particular database table. By default, the generated data object model classes have the same names as database tables, but power users can define different names. The result of the data object model generation is a single .NET class library that can be included into .NET projects for target MIS.

Our generator tool supports two different data object model generators. The default is to generate data object models based on the Microsoft Entity Framework (we use the EdmGen2 tool for this). However, the Entity Framework was introduced in .NET version 3.5 and cannot be used in applications using old­er versions of . NET, which are used in some of the MIS rele­vant for our work. Thus, we also developed our own data ob­ject model generator working in older .NET applications but using the same naming conventions and providing functionali­ties and fac;ade interface analogous to the Entity Framework. Due to this compatibility, it is possible to easily substitute be­tween data object models generated using our data object mod­el generator and the Entity Framework, based on the used .NET version. On our project's Web page [2], we have posted a UML (Unified Modeling Language) diagram showing how our generator uses the Factory pattern to create classes that work with Microsoft SQL Server and Oracle databases. This can be easily extended to any other database (e.g., PostgreSQL) sup­ported by Microsoft's OLE DB drivers or conforming to the ODBC (Open Database Connectivity) interface.

Lek Sifra 0101

0103290 0101355 0105140

0105031 0102182

Naziv

EBAANTIL 5 DO 25 mo/5 ml COADARONE 6 pO 3 mil 150 mg) DOPAMIN 5 po 50 mg/5 ml ADAENALIN HCL 50 pO 1 mg/lml NIRMIN 50 DO 1 mo/1.6 ml

Figure 5. Selection component for a medicine ("Lek" in Serbian)

B. Generation of selection components

For each database table a selection component can be de­fined. This is a Gill component that applies filters defined in search fields and when a MIS end user (e.g., doctor, nurse) types some text in these search fields, the selection component automatically displays a drop-down list of filtered results from which the end user can choose one. Figure 5 illustrates how en­tering the first 3 digits of a medicine code (label "Sifra" in Ser­bian; this is the search field) produces a drop-down list of cor­responding medicine names (label "Naziv" in Serbian). For a selection component for one database table, up to three search fields can be defined. This is shown in the middle of Figure 4, in the section "Selection component". Selection components are particularly useful for large catalog tables (such are cata­logs of medicines, diagnoses, physicians, and similar), but can be defined for any database table. When a selection component is generated as a Windows (end) user component, it can be in­cluded into any Windows form. Each generated selection com­ponent inherits the GeneralSelectionComponent class contain­ing base features (which can be overridden in the code of de­rived classes, if needed). One of these base features is minimal length of the text typed in a search field. By default, filtering is started after the third character entered in a search field (be-

cause catalogs have many items). Another base feature is the maximum number of items displayed in the drop-down list.

C. Generation of forms

Windows forms are the main GUI elements in our MIS ap­plications, so our generator tool allows power users to (if they wish) automatically generate these forms and save them in a selected destination folder. The generated forms can be reused in various end user application modules. Currently we support generating Windows forms for .NET versions 1.0 to 3.5, using Microsoft's CodeDom library. We recently made progress on automatic generation of Web and XAML (Extensible Applica­tion Markup Language) forms, which will be used in our forth­coming software.

Different forms can be generated based on the data stored in database tables, data object model related classes, as well as multi-language translation resources. However, all generated forms use the same conventions allowing creation and update of underlying data objects (which are managed within the cen­tral application component). For example, each element from a medical record item object (and, thus, each field from the cor­responding database table) is represented with a label and an appropriate field allowing editing. Different data types corres­pond to different visual components: shorttext is represented with a regular textbox, description with a multiline textbox, numeric value with a light orange background, image with an image boxe, Boolean value with a checkbox, while collections of ENUM range objects with combo boxes (allowing an end user to choose from a list of offered values). Measurement unit is represented as a label on the right of the editing component, while all ranges are combined in a label placed right of the measurement unit. Figure 6 shows a Windows form generated for the temperature_list entity that represents a set of values from the basic medical examination of a patient: body tempera­ture (label "temperatura"), systolic and diastolic blood pressure ("sistolni pritisak" and "dijastolni pritisak"), and heart beats per minute ("puis") along with general remarks ("napomene").

Zapls u temperaturnoJ hst. I

lme i prezime: CIRIC AlEKSANORA Adresa:

Datum rodenia: 05.05.2005

LBO: 28302614723 JM8G: 0505005735089

Vid: . temperatura

sistolni pritisak

dijastolni pritisak

Duls

napomene

13 6,7 O( Granica: 37,0

1r.:12::::: 0--- mmHg Granica: 120

170 mmHg Granica: 80

1"'63"1 --- okucaja/min

Prosledi I Ponisli I ,4

Figure 6. Form for entering and editing values on the temperature_list record

D. Generation of components for tracking measured values

Another type of automatically generated component shows (tracks) how a particular measured value changes over time. It is illustrated in Figure 7, for the same example as the form in Figure 6. This type of component is generated based on the generated forms - each form can have a corresponding meas­ured values tracking component. After a form is generated, a power user can specify which numeric fields (measured values) from the form should be displayed in the corresponding meas-

978-1-4244-6376-31101$26.00 ©2010 IEEE

ured values tracking component. Each tracked measured value appears on the top of the generated component with a name la­bel and a check-box. At run-time, an end user can choose which measured values are displayed on the graph in the meas­ured values tracking component. This plotted graph shows changes of the measured values over time. Ranges are represented with horizontal lines. For example, Figure 7 dis­plays body temperature values from several measurements and the horizontal line is the temperature of 37 degrees Celsius.

,! , Ime i pre,me: CIRU5 AlEKSANDRA

Adresa: • Datum rcxlenja: 05.05.2005

LBO: 28302614723 JM8G: 0505005735089

Vid: -

Prijem T empel'aturn� �st� I Pregledi I elM I L�b. �Mljze I Sk�le UI Plocenu bolesnik� I Dtpust I 8 P tempeaKlMa r pr�isak

Figure 7. Measured values tracking component for temp_list entities

E. Building of translation resources

Multi-language support is another feature of our software, necessary for its applicability in different countries. As men­tioned in Section III and shown in Figure 2, multi-language support is an integral part of the EHR meta data model, which enables translation on every definition level. Currently, we support two ways of defining translation resources: translation incorporated into a model and translation defined in a separate external file. In the first approach, a power user defines transla­tion values for different languages in the class EHRMetaModel. Since this multi-language support is fixed during design-time, it is not very efficient. Therefore, the second approach, based on external XML or Microsoft Excel XLS files, is more flexi­ble. In this approach, our generator tool creates a translation XML or XLS file that lists all strings (e.g., "[.#Echo.]" unique label identifier) that can be translated and power users then en­ter translation terms in different languages (e.g., "Exo" in Ser­bian Cyrillic script, "Eho" in Serbian Latin script, "Echo" in English) into this file. We have posted on our project's Web page [2] a figure showing an XLS translation file where names of strings properties and translation terms for 3 languages are in different columns and each row corresponds to translation of a single string. If there is no translation term in a particular lan­guage, the name of the string property is used by default.

These translation resources are used during form genera­tion. Each form can be defined either as a single language form or as a form supporting labels in multiple languages (one of which is chosen during run-time). For a single language form, labels are fixed during the generation process to terms (in the chosen language) defined within the translation resource. For forms supporting multiple languages at run-time, the genera­tion process represents each label with a unique identifier (in the first column of a translation resource file) and embeds all

available translations for these labels into a resource added into the .NET library containing the generated form. At run-time, one language is selected and unique label identifiers are re­placed with corresponding terms from this language.

F. Generation and customization of reports

In MIS, there is a frequent need to generate various reports. During the code generation process, our generator tool can de­fine a new reporting profile containing all fields from a single database table for which a Windows form is already generated. After all forms have been generated, the end user will have a list of predefined reporting profiles containing all fields from all tables. Each profile contains a list of medical record item elements that can be grouped to achieve more efficient organi­zation of item elements. Groups are particularly useful when one medical record item contains a many elements (30 and more). At run-time, the reporting profiles are used by our re­port generation software tool [4], the main parts of which are: the Profile Manager, the Query Editor, the Query Parser, the Data Module and the Result Providing Module.

The main window of the report generation tool is illustrated in Figure 8. On the left side is a tree structure of medical record item elements (groups and item elements that are not members of any group) within the active profile. In the upper part is a list of sub-groups or medical record item elements within the selected medical record item element group. On the right side is a set of buttons for easier query writing. In the central part (with the blue background) is the query editor that enables end users to create query statements by combining medical record item elements (but not groups or sub-groups) and available logical operators (NOT, AND, and OR). The re­sulting query is closer to spoken language than SQL and, thus, more understandable to medical professionals.

� ...

NOT Tetraloaie Fallo! OR

( Eho: Ap: Vrnax (mfsec) BETWEEN 0 9 AND 1

AND Dopler:QplQs(-) BETWEEN 0.5 AND 1

) AND

(

D� Obmil�red I

)( Obri;i�

Prosledi�

Figure 8. Main window of the report generation tool

G. Configuration of end user access control profiles

Similarly to reporting tool profiles, the generator tool can create configuration tool extensions that define end user access control profiles. These profiles specify allowed application ac­tions and/or visibility of database table fields (each correspond­ing to a medical record item element) for a particular end user (or an end user class) [11]. Here, application actions are dis­play, addition, editing and deletion of objects of the class Med­icalDataContainer and its subclasses. Each database table filed can be specified as visible or invisible. A power user can speci­fy which actions and which fields are configurable and which are disabled. Disabling an action will prevent the end user from executing it, while disabling a database table field makes that

978-1-4244-6376-31101$26.00 ©2010 IEEE

all corresponding visual elements in the generated forms are disabled. Figure 9 shows a window of the access control confi­guration tool extension. In the upper-left part a user class is se­lected, while in the lower-left part a form to be configured is selected. The right part shows a list of access privileged to ac­tions and database table fields ("Dozvoli" means "Allow" in Serbian). This possibility of fine-grained definition of end user access control profiles is needed when working with sensitive data, and most medical data are sensitive. Configuration pro­files also enable defining groups of related medical record items, as well as end user classes. The defined access control configurations are stored in the main database of the target MIS system, so that they can be applied at run-time. Run-time changes in end user access control profiles are applied without the need to restart the running MIS software.

'" " . , !!I ZaposJeni I Grupe privilegiJa Konflgutisan;e ptivilegije I

Grupe privilegila Pode§avanle lzabJanog modula

I Pronadl I r.:: � l l Aciniristrator Iaboratorlje

DozvoIiBJlsanjelrruizaclja False � Amnstrator SIstema .1 DolvoIiBrisanjeKatec;p'ijaZcka� False

Aootekar DozvoliBfisanjeLecenja False

DozvoliBrlsanjelecenjaU8oh::. False Med:inSka sestra

..:J DolvoIiBriSanjePreQled,JSavet( false 0s00a za zakazivanje p'eQledajdijagnostf<e

I :::J DozvoliBrlsanjePreQleclJSavetl False

�

..J DolvoIiBrlsanjeSistematskiPre(" false

Q".Alu"aj I ;;Codaj I Q".Cb� I DozvoIiOcxIavcYljeCianaPorodic False

DozvoiDodavanjelm...rizacija False

Moduli vazani za grupu privileglJa DozvoIiOodavanjeKatec;p'ljalc False

����:���� �VOlecenje True .

DozvoliBrisan)eKategorilaZdr avstveneZastlte

KcnwacljaForrrKartcnSkoiskaDeca KonfQxadjaPrljerma �

Codaj <rocIJJ - Cb� <rocIJ Id S_aj Izmene I

Figure 9. Access control configuration tool

H. Building applications with the generated components

All generated components are used for building MIS appli­cations, primarily to support doctors' work. Based on a medical record item in the meta-model, our generator tool creates a da­tabase table, a corresponding data object, a Windows form, as well as some other components. The generated form interacts with the database using the data object. Every data object is controlled by the data object model of the central MIS applica­tion, which creates data objects, passes them to appropriate forms, receives updated versions from the forms, and saves them. In this way, the generated forms only need to implement a very simple interface for displaying and updating data ob­jects. All generated forms are automatically stored in the same .NET library referenced by the central MIS application, so no further coding is needed to make them available to the MIS.

Figure 10 illustrates the dispatcher form of a central MIS application used at a neurological clinic in Serbia. Patient data is specified in the upper part, in the middle are tabs with differ­ent medical record items, while doctor's license and name are shown in the bottom part. Each tab page contains a data grid displaying medical record items grouped logically. Each col­umn is associated with one medical record item, and each item object is represented in the data grid with its "last-modified" timestamp. The data grid context menu (available through right clicking within the data grid) contains "add"/"edit"/"delete" options. Choosing "add" creates an empty data object for the medical record item of the right-clicked column and passes it to the corresponding Windows form, which is opened. This form is also opened after choosing "edit", which results in storing

the old object with the flag "edited" set and in creation of a new record that contains the edited values. When "delete" is chosen and this action is confirmed, only the flag "deleted" is set for the chosen data object. In other words, "edit" and "de­lete" operations do not actually destroy any data. This is be­cause MIS systems work with sensitive data, for which a record of changes should be kept. These tab pages and their content are automatically created on startup of the MIS applica­tion, based on the generated database tables and the end user access control profile.

'!. , lme i prezime: CIRIC AlEKSANDRA

Adresa: I Datum rodenja: 05.05.2005

LBO: 28302614723 1MBG: 0505005735089

Vid: -

Priiem I T emperaturna lista PreQledi I elM I lab analize I Skale za procenu bolesnika I Otpust I

.1

glaune tegobe

licna porodicna

.. 11.2.20101629:22 1 1.2.2010 16:29:15 9.2.201015:0800

psihicki status

11.2.20101629:19

1

sadasnja bolest

Lekar kOJI J8 otvono IstOriJU bolestl

2000312 Draqan Grasic

Figure 1 0. An example of a medical data collection application

V. VERIFICATION AND VALIDATION

We evaluated (verified and validated) our data modeling and code generation tools in several ways, discussed in this section. Note that this evaluation is different from the evalua­tion of the resulting MIS, summarized in our previous publica­tions (e.g., [3]). While there are many end users of our MIS, there are only a few (currently: 6) power users who use the data modeling and code generation tools. They are IT professionals and specialist doctors from the Central Ambulatory Facility in Nis and the Clinic for Neurology of the Clinical Centre Nis.

To verify functional correctness of our data modeling and code generation tools, we conducted both black-box functional testing and white-box structural (control flow and data flow) testing. This testing (performed in our university lab by mem­bers of our development team) was done for the code of our tools, but also for the code of the generated modules. For sev­eral forms we compared in detail the code generated by our tools and the code manually written by programmers. During this testing, we corrected found errors, but also got several in­sights about possible improvements of our tools. This resulted in several iterations of tool improvement and re-testing.

To validate our data modeling and code generation tools and to estimate its impact on efficiency of customizing our MIS for different healthcare organizations, we interviewed all current power users of our tools and solicited their impressions and improvement suggestions. They were satisfied with the tools, but provided several suggestions, particularly about in­creasing their work efficiency. The main measure of this effi­ciency is the speed of development of a set of various modules (particularly, forms) with our tools compared to manual cod­ing. Since there are many similar forms in our MIS, the power users were able to give a subjective opinion about the increased efficiency. They agreed that the overall development time was significantly shorter (less than 50% of the time needed with manual coding), particularly to get an initial functional version

978-1-4244-6376-31101$26.00 ©2010 IEEE

of the generated modules (only 10% to 30% of the time needed before). However, since we used only 1 layout template for form generation, there was often a need for some additional layout customization of the generated initial functional version. While this layout customization is somewhat quicker using our tools (80% of the time needed before), the power users noted that the need for customization should be reduced. To achieve this, we are working on developing additional layout templates, as well as software for easier creation of such layout templates. The power users also remarked that it would be good if several people could work on the same model simultaneously. There­fore, we allowed storing the meta-data model in the Model Sto­rage Database, to which a number of modeling tools (used by different power users) can connect simultaneously and access the same models. Another suggestion by the power users was introduction of a translation table, which we addressed with the translation resources explained in Subsection IY.E. Additional power user requests that are still not incorporated into the mod­eling tool are: enabling the generator tool to support other pop­ular databases in addition to Microsoft SQL Server, enabling merging different models. We are currently working on support for several additional databases (PostgreSQL, Oracle, DB2), while merging models will be done next.

To validate our data modeling and code generation tools and to determine their effects on the work of end users, we also performed interviews with several end users of our MIS. Their comments were positive. For example, they commented that the use of these tools resulted in consistency of various charac­teristics (e.g., layout, style, size, fonts, and colors) of the gener­ated forms, which helped these end users shorten the time needed to learn how to use our MIS.

VI. CONCLUSIONS

MIS are very complex information systems. An important part of this complexity is the need to create a large number of different, but somewhat similar, forms and database tables for different medical data. The past commercial form generation tools provided at best coarse-grained and semi-automatic im­plementation of these forms. This can be inefficient and time consuming. A much more powerful approach to implementa­tion of various MIS components (not only forms) related to en­try, storage, and reporting of diverse medical data was needed.

In this paper we presented our answer to this need - the da­ta modeling and code generation tools for development of EHR-based MIS. The data modeling tool enables a power user to define meta-data models, from which the generator tool au­tomatically creates database tables, data object model classes, Windows and Web forms for input of medical data, selection components, components for tracking measured values, transla­tion resources, reporting profiles, end user access control con­figuration profiles, and dispatcher forms for central MIS appli­cations. Over the last several years, we have successfully used early versions of these tools for development of several MIS for public healthcare institutions in Serbia [2, 3, 4, 5, 6]. The recent solutions presented in this paper systematized our soft­ware engineering approach to rapid development of MIS and significantly increased the power of our tools.

These tools can be very helpful in development of MIS (and other information systems) modules that share similar functionality, but work with different data formatted in differ­ent ways. They enable significantly easier, faster, and more ef­ficient development of MIS. Their use also resulted in fewer development errors, more compact code, and uniform end user interfaces (an important feature for medical staff with low computing literacy - a frequent case in developing countries). These tools also facilitate reusability and customization of MIS in several ways. First, they enable that modules developed for one type of MIS can be more easily adapted to a different type of MIS. For example, these tools allowed us to reuse and ex­tend modules developed for past MIS for ambulatory facilities [3] for development of new hospital (clinical) MIS in Serbia. Second, the built-in flexibility and support for use of additional configuration tools facilitate that developed MIS can be easily customized for different work practices in seemingly similar healthcare organizations (e.g., two hospitals in the same health­care system). Last but not the least, these tools and the resulting MIS require only minor customizations for use in public healthcare systems in countries neighboring Serbia, which have similar organization of public healthcare systems. Due to the inherent adaptability and multi-language support, these tools can also be adjusted for use in other (particularly developing) countries worldwide, but the level of required changes depends on differences between the EHR meta-model built into our sys­tem and characteristics of health records used in the country for which our software tools and MIS are to be customized.

REFERENCES

[ 1 ] Stein, T. (ed.), "The electronic physician: Guidelines for implementing a paperless practice", Allscripts Healthcare Solutions, USA, 2005.

[2] Jankovic, D. (ed.) "Web page of the Medisc project (Innovation, integra­tion and collaboration of health institutions' information systems)", Web resource at:

[3] Rajkovic, P. , Jankovic, D., Tosic, V. , "A software solution for ambulatory healthcare facilities in the Republic of Serbia, in Proc. of Health­Com2009, Sydney, Australia, December 2009, IEEE, pp. 1 6 1 - 1 68.

[4] Rajkovic, P. , Jankovic, D., "Custom made medical data reporting tool", in Proc. of Telsiks 2009, Nis, Serbia, October 2009, IEEE, pp. 306-309.

[5] Rajkovic, P. Jankovic, D. , Stankovic, T.N. , "An e-health solution for ambulatory facilities", in Proc. of ITAB 2009, Larnaca, Cyprus, No­vember 2009, IEEE, pp. 1 -4.

[6] Rajkovic, P. , Vuckovic, D. , Milojkovic, J., Jankovic D. "Cardio clinic in­formation system realization", Electronics, Banja Luka, Bosnia and Her­zegovina, Vol. 9, No. 1 (Oct.2005), pp. 4 1 -45.

[7] Butler, K.A. , Bahrami, A. , Esposito, C., Hebron, R., "Conceptual models for coordinating the design of user work with the design of information systems", Data & Knowledge Eng. , Elsevier, Vol. 33 , No. 2 (May 2000), pp. 1 91-198.

[8] Anh0j, J., "Generic design of Web-based clinical databases", Journal of Medical Internet Research, Vol. 5 , No. 4 (Oct.-Dec. 2003), paper e27.

[9] Alexandrescu, A. , "A development process for enterprise information sys­tems based on automatic generation of the components", Int' l Journal of Computers, Communications & Control, Agora University Editing House, Vol. III (2008), Suppl. Issue: Proc. of ICCCC 2008, pp. 1 68- 172.

[ 1 0] Nadkarni, P.M, Brandt, C.M., Marenco, L. , "Automatic metadata-driven generation of Web interfaces to entity-attribute-value databases" , Jour­nal of American Medical Informatics Association, AMIA, Vol. 7, No. 4 (Jul.-Aug. 2000), pp. 343-356.

[ 1 1 ] Blobel, B. , Nordberg, R., Davis, J.M., Pharow, P. , "Modelling privilege management and access control", int'I Journal of Medical Informatics, Elsevier, Vol. 75, No. 8 (Aug. 2006), pp. 597-623.

978-1-4244-6376-3/10/$26.00 ©2010 IEEE