Custom Made Medical Data Reporting Tool Petar J. Rajkovic1, Dragan S. Jankovic2

Abstract – Every organization needs to create clearly formatted reports using some reporting software. Created reports can be used within organization either as a base for further analysis and researches, or as set of data formatted as a document that can be delivered to employees, customers, and partners. Since reporting software usually is not used just by IT professionals, it ought to have simple and easily understandable user interface. A custom build medical data reporting tool is presented by this paper. The main aim of our tool is helping medical researchers and managers to extract and use information stored within medical information system’s database. It can be used for creating medical data models, extracting and filtering data from medical information system, and generating reports. Generated reports can be viewed directly in application or can be exported as XML files, as well as MS Office and Open Office documents.

Keywords – report generation, OLAP, electronic health record (EHR), medical data processing

I. INTRODUCTION

The main task of any piece of software used for medical, or any other data analysis and processing - is to create clearly formatted, well defined and readable reports [1], [2]. These reports must be presented in the way that can be easily used by healthcare professionals for their reports or further research projects. Results of mentioned medical research projects, in final consequence, can affect in better healthcare and better preventive work [3], [4].

Retrieving data directly from the database tables requires pretty good knowledge of SQL which is not so common between non IT professionals [1]. Therefore, OLAP (OLAP is short for On-Line Analytical Processing) tools become very popular recently for purpose of report generation. Usually, OLAP cubes and OLAP tools are often used for creating reports on the base of available medical data [5], but this approach has some limitation. Healthcare professionals, in most of the cases, need some technical assist for building new OLAP cubes and generating reports, which leads in slower report generation process every time they want to apply some new analysis. Also, technical support is needed in many cases when some new dependency between data needs to be added to a cube.

1Petar J. Rajkovic is with the Faculty of Electronic Engineering, University of Nis, Aleksandra Medvedeva 14, 18000 Nis, Serbia, E-mail: petar.rajkovic@elfak.ni.ac.rs

2Dragan S. Jankovic is with the Faculty of Electronic Engineering, University of Nis, Aleksandra Medvedeva 14, 18000 Nis, Serbia, E-mail: dragan.jankovic@elfak.ni.ac.rs

In order to make work of medical researchers and managers more efficient, we have developed custom made medical data reporting tool a software application that provide simple way to create reports based on data that are previously acquired by EHR(Electronic Health Record) based medical information system. Leading idea was developing a report generating software having simplest possible user interface that can be used easily by any member of some medical research team. The main features of mentioned application are presented by this paper.

II. OLAP AND TOOLS

In past several years, OLAP has turned to be very efficient way of providing the user with a tool used for one of the most complex forms of data analysis. Reporting for exceptions, summaries, key performance indicators, trend analysis, comparison over time period analysis and territories, hierarchical analysis are fields of data analysis where OLAP has been used extensively by various organizations.

Fig. 1 ProClarity - an example of OLAP tool

The most important component in OLAP hierarchy is the OLAP server, which is located between a client and database management systems. The OLAP server understands data structure in the database and has special functions for analyzing the data. There are OLAP servers available for nearly all the major database systems. Fig. 1 shows ProClarity, one of wide used OLAP tools, used for analysing data stored in database of Clinic for Neurology in Nis. It is a client for Microsoft Analysis services.

978-1-4244-4383-3/09/$25.00 ©2009 IEEE 306

Fig. 2. Example of OLAP report

III. EHR METADATA MODEL

Report generation process within medical information system (MIS) depends on the EHR metadata model. Generally, MIS systems simplify almost every process in complex healthcare providing process since they targets almost all activities connected with healthcare – from the process of patient tracking and scheduling, over medical documentation management and telemedicine to using stored data for scientific work. Also, MIS systems are extremely helpful in reducing errors and misunderstandings. Anyhow, the very base component of medical information system is electronic health record and underlying metadata model.

Fig. 2 shows EHR metadata model. This part of EHR is important for more efficient creating of database model for single healthcare facility. In the same time metadata model allows faster database recovery. Also, metadata model is used as a source for creating reporting profiles for report generating application.

Tables

PK TableID

TableNameTableDesc

Fields

PK,FK1 TableIDPK FieldID

FieldNameFieldTypeFullName

MeasurementUnit

PK UnitID

UnitSignUnitNameUnitDesc

Ranges

PK,FK1 TableIDPK,FK1 FieldIDPK RangeID

FK2 UnitIDMinMaxTypeOfPerson

*

*

*

Profile

PK ProfileID

ProfileNameDescription

ProfileItem

PK ItemID

FK1 ProfileIDFieldIDDisplayAlias

Fig. 3. EHR - metadata model

The most important data in system are healthcare related (both medical and non-medical) data that are grouped in adequate database tables, described in metadata model. Each of these tables corresponds to some medical analysis, treatment, or diagnostic. Every table consists of fields, and values of each filed are connected with specific data ranges. Also, each field’s data type as well as measurement unit must be defined. Data type could be of any supported in target database. Those data types will be remapped to EHR Meta types. EHR Meta types are derived from the set of basic data types and any data type of target DBMS can be mapped to

some of EHR Meta types. Following Meta types are defined: Boolean, integer, decimal, shorttext, and longtext.

Data ranges are values associated to some data field of integer or decimal type. Also, Meta system allows definition of pseudo data ranges for fields of shorttext type. Range for some of shorttext field is not range of values, of course, but enumeration. Data ranges represent the most adequate (normal, usual) values for specified single group of patients. Every data field can correspond to more ranges. For example, for field representing concentration of leucocytes per litre, one range for patients younger then 18 years can be defined, one for those in age of 18 to 45, and a range for patients older than 45.

Defined ranges are used to make real values easier. Any real value can be compared with values from a suitable range and later be marked as low, normal, or high.

Report generation process can be based on the fields from a single data table, as well as on the fields from specific reporting profile. In this scope, the term profile is used to describe set of fields, belonging to different tables, grouped logically in order to allow more relevant statistical report creation. From structural point of view, the profile can be represented as a tree, where root node is profile-describing node, branches are related to logical groups of fields and terminal nodes are related to fields from different data tables. Nodes from profile representing tree will be called “profile items” in further text. Each item is defined with two main values – name within database structure and alias, name that will be used for displaying profile on user interface. Profile definitions are part of same database containing Meta data.

IV. REPORT GENERATING TOOL

Report generating software tool has been developed as an extension of existing MIS system and uses data stored in the MIS’s database. Main parts of the application are (Fig. 4):

• Data Module. Manages connection to MIS’s database and retrieves data from the database.

• Profile Manager. Manages data profiles that are used as base for report generation and provides basic operations on them such are creating new profiles, updating and deleting existing ones.

• Query Editor. This component is used for interaction with user in order to create query statement containing profile items.

• Query Parser evaluates created query statements, converts them into SQL queries and forwards to result providing module.

• Result Providing Module. Formats retrieved data and display them in specified format.

Main application window (Fig. 5) consists of the tree on the left side representing structure of groups within active profile, list of profile items within selected group and query editor component (on the bottom of the right side of window). User can create query statement by combining profile items and available logical operators (NOT, AND, and OR). Result is a query closer to spoken language than SQL.

307

Fig. 4 Application Modules

In the context of report generating application, term profile refers to a group of fields from different tables from the EHR supporting database. Each field represents profile item. Also, each item can be a member of some group of items. Group of items has not any equivalent in database structure, but it is used in order to help user. Group items can be data table fields and other groups.

Fig. 5 Report generating application - main window

On the Fig. 5 profile named Kardiološka anamneza (Cardio logical anamnesis) is shown. Items of mentioned profile are organized in several levels, as they have been defined in profile manager. Items of first level (Srčane mane, Eho srca, Kardio dopler and Holter) represent top level groups. Their sub nodes represents depending sub groups. Simple profile items are not shown in profile tree. When user selects some of the group in the tree, list of belonging items is shown in item list (on the top of the right side of main form).

As it was mentioned before, component named Query Editor is used for creating query statements (Fig. 6). Query editor helps user during query creation. It takes care whether

all the open brackets are closed and what next can be added (profile item or operator). For example, user cannot add two profile items or two binary operators (OR immediately after AND) one after another. Except adding items, operators and brackets user can remove last entry (click on “Obriši sve” button) and clear query editor (click on “Obriši sve”). After query statement has been created, user can submit it to component called Query Parser by clicking on “Prosledi upit” button.

Fig. 6. An example of created query statement

User can add all Boolean, numeric or textual items. When user selects Boolean item it will be directly transferred to the query editor, appearing there after last operator added. If user selects some field of string type he has to enter some string value for comparing. Entered value and field name will be connected with LIKE operator, and added to query editor. If there’s an enumeration with predefined values exists, list of all predefined values will appear, so user should select one value from the list.

On the other side, if user selects some numeric item, prompt for entering range will be shown. Now, user can enter minimal and maximal values that are interested for him. After that, new entry in query editor containing entered range will appear. This entry is comprised of field’s name and values entered in range definition dialog, connected with special words “between” and “to”. If user right clicks on some of query editor entries, list of related ranges with normal values will be shown in pop-up window, so user can compare defined values with regular values.

Important notice here is: beside presented tool helps medical stuff to create queries, user must have relatively good domain specific knowledge in order to create queries that can result in useful reports. Reporting tool can help user to create queries exposing them interface closer to spoken language than SQL. Also, ranges of normal values can help user in case of numeric values, but for Boolean and string data fields, user need to have knowledge about their real meaning and real values.

Query statement created by query editor can be forwarded to parser at any time. Parser will transform query to SQL statement and it will try to execute it. If query was not well formed, parser will prompt an adequate error displaying message and pass control back to the editor.

308

Fig. 7. Example of generated report

Fig. 8. Example of created report (titles are on Serbian language)

When parser validates query, query is transformed to SQL statement and executed on the database. Each profile item will be mapped to assigned field of specific database table, and operators are converted to fit SQL specification. After that parser prompt configuration dialog to the user. User can configure how retrieved data should be displayed – in form of

table, or in form of the chart. User can get total number of patients as result of passed query statement, or some additional distribution of patients can be added to query such are – distribution by regions, counties or towns; distribution by sex, age, occupation or marital status; distribution by percentage of total number of patients from some specific group of people (diabetic, etc).

Results of query, retrieved from database server, are passed to the result providing module. This module will open new modal window that will show retrieved data as they have been configured before. Fig. 7 represents a report where user includes, list of patients, geographical distribution (by town), and distribution by gender. Now, user can save report as XML file, or export result to RTF, PDF (Fig. 8) or XLS file.

V. CONCLUSION

The main aim of report generating application developing was making medical researchers’ work more comfortable. Statistical reports are part of many researches in the different areas of medicine but existing OLAP tools did not give so friendly environment for non-IT professionals such doctors or physicians are. Also OLAP tool is constrained by previously generated cubes. So, application has been created as a response for a specific need, and it was designed as medical stuff from Niš Clinical Centre defined it.

Presented report generating tool is created, basically, for medical reports creation, but since it is developed on Meta data model, it can be generally used for any database built on the same structure of basic Meta entities. This paper has presented a custom made reporting especially built on the demands of physicians and medical researchers, but in perspective it can be used as general reporting tool as well as a part in some medical decision making and expert systems.

REFERENCES

[1] Thomas A. Lang, Michelle Secic, How to Report Statistics in Medicine, American College of Physicians, Philadelphia, USA, 1997.

[2] Betty Kirkwood, Jonathan Sterne, Essentials of Medical Statistics, Blackwell Publishing, USA, 2003.

[3] Stephen B. Hulley, Steven R. Cummings, Warren S. Browner, Deborah G. Grady, Thomas B. Newman, Designing Clinical Research: An Epidemiologic Approach, Lippincott Williams & Wilkins, 2006.

[4] R.H. Riffenburgh, Statistics in Medicine, Academic Press, San Diego, USA, 2005.

[5] Rajeev Tatkar, OLAP Comprehensive Analysis of a Large Pool of Clinical Data, Article taken from http://www.ehealthonline.org

[6] Srebrenko Pešić, Tatjana Stanković, Dragan Janković, “Benefits of Using OLAP Versus RDBMS for Data Analyses in Health Care Information Systems” (on Serbian), INFOTEH-JAHORINA, Vol. 8, Ref. E-VI-5, pp.751-755, March 2009.

309