Openclinic Technical Documentation

8/11/2019 Openclinic Technical Documentation

1/21

OpenClinic Technical DocumentationBelgium/Rwanda MXS 2010


2/21

IContents

2010 MXS NV/SA

Table of ContentsPart I Introduction 3

................................................................................................................................... 31 Open IT architecture.......................................................................................................................................................... 3Open Source software.......................................................................................................................................................... 3Disclose d s ource license.......................................................................................................................................................... 3Webbased us er interface

................................................................................................................................... 42 GEHR model.......................................................................................................................................................... 4Short description of the GEHR architecture

................................................................................................................................... 43 Application domains

................................................................................................................................... 54 Implementations

Part II OpenClinic software 5................................................................................................................................... 61 General aspects

.......................................................................................................................................................... 6User language

.......................................................................................................................................................... 6Technical requirem ents

................................................................................................................................... 62 Patient administration

.......................................................................................................................................................... 6Patient identification

.......................................................................................................................................................... 7Dem ographic data

................................................................................................................................... 83 Admission, Discharge a nd Transfer (ADT)

.......................................................................................................................................................... 8In-patients......................................................................................................................................................... 8 Admission and identif ication......................................................................................................................................................... 9 Admission......................................................................................................................................................... 9Transfer ......................................................................................................................................................... 9Discharge

.......................................................................................................................................................... 9Out-patients......................................................................................................................................................... 9Visit identification

.......................................................................................................................................................... 9Patient tracking.......................................................................................................................................................... 10Electronic agenda......................................................................................................................................................... 10Resource planning

................................................................................................................................... 104 Financial management

.......................................................................................................................................................... 10Activity data

.......................................................................................................................................................... 10Invoicing and accounting......................................................................................................................................................... 11Discharge and end of visit......................................................................................................................................................... 11Preliminary invoicing......................................................................................................................................................... 11Payment and cash transf ers

................................................................................................................................... 115 Medical record

.......................................................................................................................................................... 11Record identification

.......................................................................................................................................................... 12History of health events

.......................................................................................................................................................... 12Generic SOAP structure

.......................................................................................................................................................... 12Domain specific registration forms

.......................................................................................................................................................... 13Medical prescription m anageme nt......................................................................................................................................................... 13Ward s tock management

.......................................................................................................................................................... 14ICPC2/ICD10 base d thes aurus

.......................................................................................................................................................... 14Technical examinations management......................................................................................................................................................... 14Laboratory data management

......................................................................................................................................... 14Order entry

......................................................................................................................................... 14Results


3/21


4/21

Introduction 3

2010 MXS NV/SA

1 Introduction

MXS is a Belgian Medical Software company that has developed a suite of applications for themanagemen of healthcare information. The company is led by a physic ian who is also a software

engineer and has a permanent staff of 1 more physician with high-level IT skills, 4 software engineersand 1 research coordinator. Furthermore, the company has a team of 5 healthcare IT-consultantsworking on project basis and a local Rwandan team of 1 public health expert, a physician-expert inhealth statistics, 2 technicians and 2 administrative collaborators.MXS has specialized in tailor-made applications, which are built on basic generic technological platform,called the "OpenIT architecture". In this document an introduction is given to the OpenIT architectureand more specifically the Open Clinic Hospital Information Management System that has beendeveloped on top.MXS has a permanent office in Rwanda at the ININD House in Kigali (Kicukiro).

1.1 Open IT architecture

The general OpenIT architecture has been the fruit of many years of experience in medical information

management. The systems built on this architecture thereby have evolved from standalone softwarepackages (early nineties) over client-server sys tems (late nineties) towards nowadays distributed andweb-based software suites. Today, the OpenIT philosophy aims to deliver IT-systems that can bemanaged to a large extend by the customer's IT department. Only widely used and solid technologiesare being integrated in OpenIT sys tems, in order to realize reliable and stable products.

1.1.1 Open Source software

For customers who really want to cut their budget dramatically the standard OpenIT-kernel is availablewith OpenSource and Freeware software backbone only:- Sun's Java Runtime Environment- Tomcat Servlet Engine- PostgreSQL database server (all operating systems) or Sybase Adapative Server Enterprise 11.9.2 for

LinuxServeral OpenIT products have been implemented on such an OpenSource backbone, even for very largecustomers (e.g. Federal Police Medical Service in Belgium)

1.1.2 Disclosed source license

Once installed, all sourcecode of every OpenIT module is provided to the client. The client can freelyuse, modify and evolve the sourcecode whithout permission of MXS. Only reselling of the OpenITmodules is prohibited.The advantages of Disclosed Source code:

No need for MXS-support for modules for which the customer has a sufficiently skilled ITdepartment.The customer can call in other software companies at any time to support the OpenIT-modules

(independency from MXS as a software provider)Internal IT-staff can freely use and copy code-fragments from the OpenIT-kernel for noncommercial (no

reselling permitted) internal purposes.

1.1.3 Webbased user interface

Many members of hospital staff have little or no experience with computer hard- and software. Thereforethe well-known Web interface, one of the easiest and most widely used interface-types in the world, hasbeen selected to be integrated in the OpenIT architecture. All end-user software manipulation can bedone through a standard webbrowser, which many users are familiar with. If a user can surf the web, hecan use OpenIT based software like Open Clinic.


5/21

OpenClinic4

2010 MXS NV/SA

1.2 GEHR model

From the beginning, MXS has specialized in health information management. The company's corebusiness lies without any doubt in the healthcare sector (>90% of revenue). Since the early nineties, our IT-trained physicians and information-engineers have been closely following standardization efforts in

Europe and the US in the field of medical information management. Today's OpenIT architecture hasbeen built on one of the most influencing medical standardization-projects in the past 15 years, the"Good European Health Record", renamed later as the "Good Electronic Health Record" (GEHR). TheGood European Health Record, was a three year project within the European Health Telematics researchprogramme (Advanced Informatics in Medicine) 1991-1995. It has developed a comprehensive multi-media data architecture for using and sharing electronic healthcare records, meeting clinical, technical,educational and ethico-legal requirements. The GEHR project consortium involved 21 participatingorganisations in seven European countries, and included clinicians from different professions anddisciplines, computer scientists in commercial and academic institutions, and major multi-nationalcompanies. The architecture object model, exchange format, term sets and the specifications of accessand integration tools have been placed in the public domain.

1.2.1 Short description of the GEHR architecture

All information in a given Electronic Health Care Record (EHCR) implicitly relates to the care of oneperson, the patient. Within each patient record, the GEHR architecture preserves both the originalstructure of the data and how the entries in the record are grouped. Every effort has been made topropose an architecture which is as generic, flexible and non prescriptive as possible. However, whereclinicians have identified the need to be prescriptive (e.g. in situations where medico-legal security mustbe maintained) the architecture incorporates features which may be utilised for this purpose.

Principal GEHR architectural componentsthe EHCR

provides the container for all data about a particular patientthe Transaction

provides most of the features needed for the medico-legal aspects of healthcare dataprovides the mechanism for the control of amendmentsrepresents the smallest amount of data which can safely be transferred between EHCR systems

the Health Record Item (HRI)provides for aggregation of HRIs and other HRI Collections

provides the means of changing the scope (data subject) of the datathe Heading

provides annotation for groups of HRIs/Collections

Each of these constructs is further elaborated using Attributes that address aspects of identification,content and context. They are consistent with the structures apparent in existing records and fullfil therequirements identified by the project for the EHCR. The GEHR project has developed two formaldefinitions in support of the architecture: the GEHR Object Model and the GEHR Exchange Format. Tosupport the development of healthcare record systems incorporating the GEHR architecture, the projecthas produced a term set of 2,000 HRI names available in 9 European languages, and a comprehensiveset of 47 anatomical drawings. The architecture, term sets and drawings have all been placed in thepublic domain.

1.3 Application domains

The generic OpenIT architecture provides a technological foundation for several applications in thehealthcare domain. In fact, the GEHR project proved that a generic mechanism of structuring medicalinformation could be applied to fundamentally different clinical specialties. Typical application domainsare curative medicine (private practice and hospital), preventive medicine, disease management and


6/21

Introduction 5

2010 MXS NV/SA

clinical research.Experience however shows that every specialty has it's own way of using these common structuringconcepts. Every specialty has it's own typical needs with regard to specific content and informationaggregation. Therefore, most OpenIT-based systems are being highly customized to meet the exactrequirements of the end-users.

1.4 Implementations

Today, OpenIT based systems have been or are being used for:Curative medicine:

- Family physicians record management systems (Belgium, Open Clinic: Datamed, Praktis)- Hospital medical record management systems (Belgium, Open Clinic: Hematology, Pneumology,Cardiology)- Hospital Information System (Rwanda, Open Clinic: CHUK, DH Muhima, DH Kibagabaga, DHNyamata, DH Rutongo, Polyclinique du Carrefour, Croix du Sud hospital, Biomedical Center,Polyclinique La Mdicale, Polyclinique Bien-Natre - RDC, OpenClinic: DH Dondo, CHU Kinshasa,CHU Lubumbashi, CHU Bukavu, CHU Kisangani - Burundi, OpenClinic: Centre Mdico-Chirurgicalde Kinindo)

Preventive medecine:Occupational healthcare (Belgium: OpenWork)- Vaccination program management (Zare: Open Clinic)- Industrial hygiene (France, Belgium: OpenWork)

Disease management programs- Dementia distributed medical record (Belgium: Open Clinic: DementiaNet)

Clinical research programs- Pharmaceutical clinical trials (Belgium, Luxemburg: OpenCRF: Olmer3plus, IPAQ, Dilease,

Hyperscreen)Other

- OpenControl (Belgium: Sickness absence & return to work management)- OpenRecrute (Belgium: Recrutement examinations)

2 OpenClinic software

Open Clinic is an integrated Hospital Information System consisting of a series of modules that havebeen built on the OpenIT Medical Information Architecture (OpenMIA). The system automatesinformation management for all basic functions of small to medium-sized hospitals (50-1.000 beds).Open Clinic is the result of more than 15 years of experience brought together by computer engineersand physicians with high-level ICT-training at MXS (Belgium). The Open Clinic program was first startedin 1990 and has been on the market until 2001. In 2004, the OpenMIA architecture and the OpenClinicmodules have been completely redesigned and reprogrammed in the Java programming language, one of the most popular programming languages in the world today.

The most important features of the Open Clinic system:Very easy graphical user interface (web-based) thanks to custom-made data-entry screens , which

exactly match the user-defined business processes in the HospitalExtremely low cost of ownership thanks to the extensive use of OpenSource server- and

development components and the complete absence of recurrent license fees .Unlimited number of users and devices in the system. No additional fees are to be paid when the

system has to grow with your institution.

Use of high-standard proven technologies and software components , such as:1. The Java programming language2. Tomcat web application server (Servlet Engine)


7/21

OpenClinic6

2010 MXS NV/SA

3. Compatibility with a choice of high quality database servers:- Microsoft SQL Server - Sybase Adaptive Server Enterprise- Oracle database server - MySQL database server

- ProgreSQL database server - Cach database server 4. Fully web-based user interface, optimized for Microsoft Internet Explorer (version 5.5 and above)5. Wide Operating System compatibil ity - Microsoft Windows NT/2000/2003 Server/XP/Vista- Linux- Sun Solaris Availability of all sourcecode to the customer.Easily ex tendable multilingual user-interface support (French, English and Dutch provided in

standard version)Very open implementation enhancing the integration of interfaces to other software systems or

medical devices.Standard integration of statistical classification instruments as ICPC/2 and ICD-10Open Clinic is modular , thereby ensuring sustained benefits through changes in technology,

protecting and providing optimal returns from the investment. It is modeled on a unique combination of a'patient-centric and medical s taff-centric' paradigm, beneficial to the recipients and the providers of healthcare.

Integration of clinical as well as financial and administrative applications.Audit logging of all transactionsEasy to manage user security

2.1 General aspects

2.1.1 User language

The standard Open Clinic system is available in French, English, Portuguese and Dutch. Nevertheless,all user interface- and report-related labels have been isolated in separate language-tables. This meansthat is is quite easy to introduce new languages into the system.

2.1.2 Technical requirements

The OpenClinic software is compatible with basic hardware specifications: ordinary PC's with 512 Mb of RAM or Thinc Client infrastructure with Windows, UNIX, Linux or Mac platform.

2.2 Patient administration

Efficient patient administration is one of the cornerstones of a well designed Hospital InformationSystem. Patients must be uniquely identified, in order to keep track of their complete medical andfinancial history within the institution. The Open Clinic patient administration module has been designed

to enable registration of a complete administrative history. Nevertheless, as special (local) needs for particular data fields seem to arise in most Open Clinic projects, the module is easily extensible. Anynumber of data fields that would seem to be missing in the standard implementation, can be added tothe system by the application manager (a specially trained super-user).

2.2.1 Patient identification

As stated earlier, patient identification is c rucial when handling sensitive personal information likemedical or financial records.


8/21

OpenClinic software 7

2010 MXS NV/SA

The OpenClinic patient identification functions include:Possibility to attribute an unlimited number of pe rson identifiers to a patient record (ID card,

National register ID, Passport ID, Fingerprint ID etc...) Automatic attribution of a unique , permanent system wide medical record number by Open Clinic

to each patient. This ID is the key that brings together all person-related information that is brought into

the system. Every person-related document that is printed by Open Clinic can wear this unique ID.Possibility to print patient identification labels to put on paper documents, wrist bands etc... This

printout also comprises barcoded tags, which can reduce patient identification time dramatically.

However, clinicians need to be actively involved in the development of policies and procedures related toverifying patient identity. These individuals can best identify issues that contribute to errorproneconditions and develop strategies to reduce their likelihood. Next, they must consistently follow theprocedure and be accountable for their practice by adhering strictly to the policy. Furthermore, cliniciansmust hold each other responsible and continually identify risk states and implement processes andprocedures to prevent such errors. Nurses should review exist ing policies, procedures, and practicesrelated to patient identification. They need to identify gaps and situations that place patients at risk andthen develop and implement processes to minimize these risks. In many situations, current practicesare not adequate to addressthe pace of admissions and number of surgical cases. Many times, the clerk in the admission officecharged with placing a name band does not understand the risks inherent in incorrect identification. If for some reason a patient ends up with more than one medical record in the institution, the Open Clinicsoftware provides a record merging function, resulting in a fusion of two records into one single record.

An automatic retrieval engine for records that are 'suspicious' (possible duplicates), facilitates themaintenance of a 'clean' administrative database.

2.2.2 Demographic data

Most common patient-demographic data elements have been integrated in the standard Open Clinicimplementation:

Personal data

1. Name (firstname, lastname, alternate names)2. Date of birth3. Record ID number (other than the automatically attributed Open Clinic ID, e.g. reference to apaper based record)4. National ID number 5. Language6. Gender 7. Place of birth (city & country)8. Nationality9. AlternateID (e.g. fingerprint or other biometric data)10. Comments

Medico-administrative data1. Family physician2. Other private physicians (specialists)3. Health Insurance company4. Health Insurance Contract number 5. Health Insurance status (code + description)

Official addres1. Street and number 2. Zipcode3. City


9/21

OpenClinic8

2010 MXS NV/SA

4. Country5. E-mail6. Telephone7. Fax8. Mobile phone

9. Comments

Residence address1. Street and number 2. Zipcode3. City4. Country5. E-mail6. Telephone7. Fax8. Mobile phone9. CommentsFor the Rwandan context, the following fields have already been added to the OpenClinic software:10. Province11. District 12. Sector 13. Cell 14. Village

Occupational data (work environment)1. Employer name and address2. Employee record number 3. Work e-mail4. Work telephone5. Work fax6. Work mobile phone7. Function8. Employee category9. Start date of employment10. End date of employment

Any number of missing data fields can easily be added to the Patient administration module.

2.3 Admission, Discharge and Transfer (ADT)

The Open Clinic ADT module enables the detailed follow-up of all patient movements within thehealthcare facility. Data collected in this module will also be used to calculate bed occupancy rates or provide reports on the actual numbers of available beds.

2.3.1 In-patients2.3.1.1 Admission and identification

Every contiguous period of time a patient occupies a bed in the hospital, is being identified by a unique Admiss ion number. Every medical act, prescription, payment etc.. . related to the hospital stay will carrythis Admission ID. The Admission number being unique, it can also be used to uniquely identify apatient within the system.


10/21


2010 MXS NV/SA

2.3.1.2 Admission

At the admission of a patient, a number of admission-related data can be collected and stored in theOpen Clinic system. The standard Open Clinic implementation holds the following data (some areoptional):

Date and time of admissionPlanned date and time of dischargeWard identificationBed number identificationResponsible physician identificationComments

2.3.1.3 Transfer

A transfer in Open Clinic means a change in ward or bed identification data within the context of one andthe same hospital admission. Transfer registration is essential to keep track of bed occupancy and -availability. At the occasion of a transfer, the following data can be entered (some are optional):

Date and time of transfer New ward identificationNew bed identificationNew responsible physician identificationNew planned date and time of dischargeReason for transfer Comments

A unique transfer identification number is automatically att ributed to every transfer in the hospital.

2.3.1.4 Discharge

Discharge means the end of a hospital admission. After discharging a patient from the hospital, theadmission number is closed and the occupied bed is automatically flagged 'available' in the Open Clinicsystem. When discharging a patient, the following data can be entered (some are optional):

Effective date and time of discharge

Reason for discharging the patientComments

2.3.2 Out-patients

2.3.2.1 Visit identification

For outpatients, every visit to the hospital is identified by a Visit identification number. This number willenable the grouping of all patient data related to one and the same hospital visit . When registering anoutpatient's visit, the following data can be entered into the system (some are optional):

Date and time of the visitType of contacts (consultation, examination) to be carried out

1. Contact type2. Responsible clinician3. Scheduled contact time

2.3.3 Patient tracking

Patient ADT information permits to keep track of the patient movements within the hospital. A separatemodule is provide in Open Clinic to graphically visualize inpatients' bed allocation history and to identifyall medical acts which adhere to a specific moment of the admission period. Open Clinic can also showa map of the hospital site with the exact location of the patient's allocated bed at any moment.


11/21

OpenClinic10

2010 MXS NV/SA

2.3.4 Electronic agenda

A standard electronic agenda has been integrated into Open Clinic. This user-centered agenda can holdall scheduled appointments for every user, permitting the definition of 'user groups' which are grantedaccess to each others agenda. The medical record of a patient can then easily be opened by clicking on

the patient's name in the agenda (quick identification).2.3.4.1 Resource planning

In the Open Clinic agenda, a resource planning facility has been integrated. This module enables usersto make reservations for shared resources such as operating rooms, diagnostic devices, meeting roomsetc...

2.4 Financial management

Financial management in the standard edition of Open Clinic is based on medical act based billing. Thismeans that invoices for hospital visits (outpatients) and hospital admissions (inpatients) can be printedbased on medical and technical acts that have been linked to a specific Visit ID or Admission ID.

2.4.1 Activity data Accountable activity data (medical and technical acts) can be provided to the system in multiple ways:1. By manually adding acts to the patient record.2. By automatically generating act codes based on medical record data entry. The Open Clinic softwarecontains a sophisticated module to link specific acts to medical record activity. E.g. the output of alaboratory result or an X-Ray report will automatically generate the corresponding act codes. But alsomedication prescriptions, vaccinations and intellectual activities can be linked to act-codes. This linkingis rule-based and can be maintained by the local application manager.

Acts that are automatically generated by the system, stil l have to be validated by a dedicated user.For every act, the following data can be added to the Open Clinic system :1. Planned flag to indicate that the act has been planned.

2. Executed flag to indicate that the act has been executed.3. Validated flag to indicate that the act has been validated by a user.

Acts that are manually added to the system will automatically have the 'validated' flag set. The 'executed'flag is set for acts which are automatically generated from medical record data entry. Activity codes caneasily be grouped into so called 'activity profiles'. These profiles are being stored into the Open Clinicdatabase and can be used to quickly add groups of act codes to the medical record (e.g. severallaboratory analyses grouped together)

2.4.2 Invoicing and accounting

The Open Clinic invoice module is patient centered. This means that only invoices related to a patientcan be printed by the system. Invoices for a particular patient can be selected on a series of criteria:

Admiss ion ID based invoicingVisit ID based invoicingSpecific period of timeSelection of specific act codes

1. Manual selection2. By act code3. By care provider (user responsible for the act) Act ivity code flags (planned, executed, validated)

All criteria can be combined, yet providing a very flexible way of outputting invoice data for specificsituations.


12/21


2010 MXS NV/SA

For every invoice, the following data will be recorded (in supplement of the data retrieved from themedical record):1. Date and time of the invoice2. Identification number of the invoice (automatically attributed by the system)

3. User generating the invoice4. Total amount of accountable acts5. Total amount of payments already registered6. Balance7. Destination of the invoice (patient, employer, insurance company...)

2.4.2.1 Discharge and end of visit

At the moment of discharge or when closing a visit , a final invoice for the hospital st ay or visit can beprinted out. This invoice holds all accountable act data related to the Visit ID or Admission ID and for which the 'validated' flag has been set. C ash transfer history related to the Visit ID or the Admission IDhas also been integrated in the invoicing module. This means that the invoicing module will subtract allregisteredpayments from the amount due and it will print out the balance on the invoice.

2.4.2.2 Preliminary invoicing

Preliminary invoices related to a Visit ID or an Admission ID can be printed out, holding all accountableactivity codes for which the 'planned' flag has been set.

2.4.2.3 Payment and cash transfers

Payment and cash transfer registration is part of the standard Open Clinic system. Summarized, thefollowing types of payment and cash transfer have been integrated:1. Deposits2. Cash payments3. Other mony transfers (insurance companies)

For every payment or cash transfer, the following data are being recorded (some are optional):1. Visit ID or Admission ID2. Date and time of payment3. Origin of payment4. Amount5. Currency6. Wicket or front office identification

2.5 Medical record

The medical record is the core object of the Open Clinic Hospital Information System. In a hospitalenvironment, accurate and persistent storage of clinical information is crucial to patients and care

providers. Therefore, special attention has been paid to this extended module, for which MXS can refer tomore than 15 years of high level experience.

2.5.1 Record identification

Medical record identification is a complex matter. In some hospitals, patients have more than onemedical record (e.g. service based or functional multiplication of records). Sometimes medical recordscan only be identified by admission numbers or visit id's (time based or temporal multiplication of records). In Open Clinic, according to the adopted GEHR architecture, every patient has only 1electronic healthcare record (EHCR). Information in this unique record can easily be clustered in anyform (per service, per ward, time-based etc...) In other words, the EHCR carries the same record


13/21

OpenClinic12

2010 MXS NV/SA

identifier as the patient itself.

2.5.2 History of health events

The standard patient medical history is comprehensively summarized on a tab-based screen andcontains:

Personal history1. Medications2. Alcohol & drugs consumption3. Tobacco usage4. Medical antecedents5. Surgery6. Acc idents

Family history1. Marital status2. Children & medical antecedents3. Other family & medical antecedents

Occupational history

1. Professional diseases2. Work accidents3. History of relevant occupations & occupational risk factors4. Stress assessment

2.5.3 Generic SOAP structure

For the purpose of entering data into the patient medical journal, Open Clinic provides a generic SOAP-based data-entry form. The SOAP format is used in most medical schools and allied health schools. Itstands for: Subjective, Objective, Assessment and Plan. Each of these sections require the basicunderstanding of medical terminology to allow continuity of care. The SOAP format requires medicalterminology that is considered appropriate by the facility where one is working. Each facility has a listedset of appropriate medical abbreviations and surgical abbreviations. Such a list can easily be integratedinto Open Clinic.The "S" includes the patient's goal, patient's pain complaint, medical history and social history. The "O"includes the clinician data collection of strength, range of motion, skin integrity and organ systemfunction. The "A" includes the clinician's opinion about the presented case, prognosis, diagnosis andgoals. The "P" includes the plan to progress to the goals set in the "A" and the interventions that arenecessary.

2.5.4 Domain specific registration forms

Although generic SOAP notes might be sufficient for the majority of clinical documentation needs withinthe hospital, Open Clinic permits the development of specific custom-made data entry-screens for special purposes. These data-entry forms are being developed in close collaboration with the responsibleclinicians, to make sure that the result exactly fits the specific documentation needs and businessprocesses of the concerning service. Examples of such data-entry screens already developed in the past

are:- General Practice- Cardiology- Internal medicine- General surgery- Gynecology- Hematology- Pediatrics- Occupational healthcare- Vital signs record


14/21


2010 MXS NV/SA

- Nutrition1. Rehabilitation card2. Daily follow-up form

- Malaria follow-up- Family planning

- Tuberculosis follow-up- Birth certificates- Death certificates- Surveillance of severely ill patients- FATE record- Cash withdrawal authorization- Check withdrawal authorization- Medico-legal expertise- Physical fitness certificate...

2.5.5 Medical prescription management

Medication prescription management has been readily built-in into the Open Clinic software. Medicationprescriptions typically hold the following data:Name of the prescribed drugTotal quantity of prescribed drug unitsNumber of prescribed drug units per dagBegin date and end date of the therapy

Medical prescriptions can be printed out on paper or can be exported electronically in any format.

2.5.5.1 Ward stock management

Open Clinic provides a simple module to manage local medication and medical supply stocks. Stockmodifications can be the result of any of the following actions:

Stock inventory: with this module initial stock levels can be fixed. The same module is used for recurring stock-corrections (e.g. yearly inventory assessment)

Stock exit : removal of medication and supplies from the stock by ward personnel. Every stock exithas to be attributed to a Visit ID or an Admission ID. Stock exits automatically add accountable actcodes to the patient record.

Stock entry : entry of medication or supplies into the local stock. This information can be enteredmanually or can be read electronically from the corresponding SAGE SQL-Tables if available (presumingthat stock exits from the central stock are stored in an SQL-Table by the SAGE application).

For every stock element, the following data can be stored:OpenClinic Item IDItem nameItem type (medication, bandage...)Unit (capsule, tablet...)Package type (box, bottle...)Units per packageCost per unitInvoicing codeMinimum level of local stockMaximum level of local stock

Furthermore, a n additional module has been developed to enable printing of Stock entry request forms,specifying a list of items that are requested from the central hospital stock. Items and their corresponding quantities can manually be added to the Stock entry request or automatically be


15/21

OpenClinic14

2010 MXS NV/SA

calculated by the software (based on data coming from 'active' medical prescriptions and availability inthe central stock).

2.5.6 ICPC2/ICD10 based thesaurus

The complete ICD-10 and ICPC-2 classifications have been integrated in the standard edition of OpenClinic. The software makes use of the same thesaurus as the one requested by the CHUK. The OpenClinic coding engine is available at all times in any data-entry screen. In order to make real timecoding a feasible procedure, automatic coding will be proposed for selected items in the Domainspecific registration forms. In that way, common symptoms, diagnosis, procedures and prescriptionscan automatically be coded by the Open Clinic package, thus avoiding misinterpretation of clinical notesin the final coding process.

2.5.7 Technical examinations management

Technical examination results and requests are being treated by the Open Clinic system just like anyother medical documentation transaction. On the other hand, some extra modules have been added tothe system to facilitate the Order entry management.

2.5.7.1 Laboratory data management2.5.7.1.1 Order entry

A complete and comprehensive laboratory prescription module is available in the standard edition of Open Clinic. The most important features of the module are:

Usage of a Lab analysis reference table, specifying every available analysis.Possibility to use lab analysis profiles (e.g. sets of analysis that go together for certain pathologies,

investigations etc...) Automatic calculation of needed sample typesEncoding of requesting clinician

Automatic generation of a laboratory request ID.Print-out of already filled-in or blank laboratory prescription forms. The forms carry the laboratory

request ID in numbers and in barcode for easy identification by the laboratory personnel.

2.5.7.1.2 Results

Lab results can be entered into the system in 3 ways:1. Automatic integration of electronic data coming from an existing Laboratory Information ManagementSystem (LIMS). Open Clinic supports several laboratory information exchange formats.2. Automatic integration of electronic data coming from Laboratory analyzers.3. Manual data-entry via the Open Clinic miniLIMS user-interface (accessible to the physician, the wardmanager or the laboratory staff). The miniLIMS module enables the retrieval of laboratory requests basedon different criteria:

Laboratory request ID: one particular request Admiss ion ID or Visit ID: all requests linked to the corresponding IDPatient ID: all requests linked to this Patient ID

Requesting clinician: all requests coming from the specified clinicianRequest status: lists all requests with a specified status (complete, incomplete, received)

All of these c riteria can be combined, yet providing a very flexible request retrieval interface. When asearched request has been retrieved, the laboratory staff can open the corresponding results record.Results can then manually be entered in the results screen. Filled-in results are immediatelyavailable in the patient's medical record. Every filled-in result automatically generates a correspondingmedical act-code in the patient record (for invoicing purpose). Laboratory results can be viewed by singleresult record or with full result history from previous laboratory examinations. Every numeric analysis-result can be viewed as a graph. Finally, results can be printed in order to deliver them at the prescribing


16/21


2010 MXS NV/SA

physician or the patient.

2.5.7.2 Medical imaging data management

2.5.7.2.1 Order entry

A complete and comprehensive medical imaging prescription module is available in the standard editionof Open Clinic. The most important features of the module are:

Usage of an Imaging examination reference table, specifying all available imaging examinations.Encoding of requesting clinician

Automatic generation of an Imaging request ID.

Print-out of already filled-in or blank imaging prescription forms. The forms carry the imaging request IDin numbers and in barcode for easy identification by the Medical Imaging staff.

2.5.7.2.2 Results

Medical imaging results can be entered into the system in 2 different ways:1. Automatic integration of electronic data coming from an existing PACS system. Open Clinic supports

several Medical Imaging information exchange formats.2. Manual data-entry via the Open Clinic miniMIMS user-interface (by the phys ician, the ward manager or the medical imaging staff). The miniMIMS module enables the retrieval of Medical Imaging requestsbased on different criteria:

Imaging request ID: one particular request Admiss ion ID or Visit ID: all requests linked to the corresponding IDPatient ID: all requests linked to this Patient IDRequesting clinician: all requests coming from the specified clinicianRequest status: lists all requests with a specified status (complete, incomplete, received)

All of these c riteria can be combined, yet providing a very flexible request retrieval interface. When asearched request has been retrieved, the medical imaging staff can open the corresponding resultsrecord. The result protocol can then manually be entered in the results screen. Filled-in results are

immediately available in the patient's medical record. Every filled-in result automatically generates acorresponding medical act-code in the patient record (for invoicing purpose). Medical Imaging protocolscan be printed in order to deliver them at the prescribing physic ian or the patient.

2.5.7.3 Pathology lab

2.5.7.3.1 Order entry

The Pathology order entry module is completely similar to the Medical imaging data managementsystem.

2.5.7.3.2 Results

Pathology results are managed exactly the same way as Medical Imaging results. The same miniMIMSinterface is being used.

2.5.8 Medical record printing

Open Clinic provides a complete and sophisticated module for printing of medical record content for asingle patient. Selections can be made on any combination of the following criteria:

Types of examinationsManually selected examinations

Admiss ion ID or Visit IDPeriod of time


17/21

OpenClinic16

2010 MXS NV/SA

2.6 Preventive medicine

Preventive medical acts have been separately integrated in the Open Clinic hospital information system.However, they can be consulted at any time from any module in the system.

2.6.1 Immunization managementOpen Clinic lets the user keep track of every patient's vaccination status. The system integratesautomatic calculations of vaccination dates based on configurable vaccination schemes.

2.6.1.1 Vaccination schemes

Any vaccination scheme can be programmed in Open Clinic with lit tle or no programming knowledge byconfiguring a simple XML file. Vaccination schemes can thus easily be adapted to local preferences, yetpermitting clinicians at any time to make any modifications to system-generated dates. Today, OpenClinic contains international schemes for the following vaccinations:

Tetanos/difteriaHepatitis AHepatitis BHepatitis A+BYellow fever TyphusMenigococ meningitisPolioTick encephalitis

2.6.1.2 Vaccination card

All patient vaccination data are comprehensively summarized on a patient vaccination card, which canbe easily printed out.

2.6.1.3 Planning & campaigns

A complete planning engine has been integrated in Open Clinic in order to provide an easy to usemanagement tool for those who whish to organize large-scale vaccination programs.

2.6.2 Risk profiles

Open Clinic fully supports the definition of medical and occupational health risk profiles. These profilesaim to help clinicians in deciding which actions should be undertaken in particular risk situations. Riskprofiles also enhance the implementation of hospital-wide protocols for treating common pathologies(basic implementation of clinical pathways).

2.7 Warnings

Important information that should be read by any care provider treating a particular patient (such as

allergies, important contagious diseases...) can be stored in a specific Warnings module. Warnings arealways shown to the user as soon as he opens the patient medical record. Warnings can also includelifetime data (beginning an end of validity)

2.8 Reporting

Several standard reports have been developed in Open Clinic. The most important reports are:Pathology distribution per consultationPathology distribution per admissionUser activity reporting


18/21


2010 MXS NV/SA

Admiss ion duration reporting per pathologyBed occupancy reportingPatient originsReference center profilesStatus of decentralized stocks

Patient debit and credit operationsProvisional financial status of each admitted patientDepartment activities reporting

2.8.1 Pathologies per consultation

Lists the distribution of all main (top 10 or top 20) pathologies per service or per user based on ICD-10(and eventually ICPC-2) codes.

2.8.2 Pathologies per admission

Lists the distribution of the main pathologies per admission

2.8.3 Pathologies and co-morbidity

Lists for all main pathologies mortality and co-morbidity (associated pathologies) data

2.8.4 Pathology cost

Lists costs distribution per main pathology. It is presumed that a main pathology will be associated toevery admission (and eventually to every outpatient visit).

2.8.5 Activity reports

Lists all activities (total numbers) per user and per service. Includes also all activities that are not linkedto any financial data.

2.8.6 Admission duration reports

Duration of admission (average duration & standard deviation) is reported per pathology, per service andper responsible clinician

2.8.7 Total invoices

Total invoice values per day.

2.8.8 Money transfers

Total money transfers per day, per wicket or front office.

2.8.9 Bed occupancy reports

Lists evolution of bed availability and -occupancy per service.

2.8.10 Clinical analyzer

MXS developed in cooperation with PatientWeb NV a sophisticated engine for extracting statistical datafrom clinical data sources. Open Clinic is fully compatible with the SHAMe Clinical Analyser.

2.8.11 Medical monitoring engine

Frequently used reports and statistical extracts can be automatically executed by the integratedMedical Monitoring engine. This engine can be configured to automatically run specific reports on prescheduled moments (e.g. every Sunday night) and to send the results to one or more e-mail addresses


19/21

OpenClinic18

2010 MXS NV/SA

within the institution (e.g. the department of statistics staff).

2.9 Document printing

Open clinic offers an integrated module for management of external documents. These documents are

usually provided by the customer (hospital) in one of these forms:paper printsMicrosoft Word-documentsPDF-documents.

Using Adobe Acrobat Professional, any of these forms will be transformed (possibly after scanning) intoa PDF-form that exactly matches the layout provided by the customer. These PDF-forms are stored inthe Open Clinic software and can be used by any user of the system. Any zones on the PDF-forms,containing medico-administrative data that is present in Open Clinic, will be automatically filled in.Documents stored in Open Clinic can be assigned to specific data-entry screens. If the documentmodule is being called from within such a screen, the default document list will only display the relevant(linked) documents.

2.10 Human resource managementOpen Clinic is pre-equipped with a an extended Human Resource Management software package(HRM). The HRM module enables follow up of all kinds of personnel data like:

Education and trainingSkills and certificatesWork schedulesWork contractsHolidays, paid annual leaveSick leave

2.11 Technical functionalities

A series of functions of the Open Clinic software are pure technical features. Therefore they have beenbrought together in this chapter.

2.11.1 Security

An efficient and easy to manage security implementation is crucial for a hospital informationmanagement system. Being a web based system, all medical records are accessible to authorizedusers from any workstation in the hospital, regardless the department where the record has beencreated. All data is stored in one single database and is managed by one single central applicationserver (however, the use of multiple application servers would be permitted in case this becomesnecessary in the future).

2.11.1.1 Access control

2.11.1.1.1 User identification

Users can be identified and granted access to the Open Clinic application in several ways. The mostcommon procedure to identify and authenticate users is via a userid/password combination. Specificpassword policies (periodic renewal, use of numbers, capitals etc...) can easily be enforced in OpenClinic through a simple point and click interface. Technically, not the password but only a hash-code of the provided password is being stored in the Open Clinic database. This means that even a systemadministrator has no access to the user login data. Users are to be held responsible for not distributingtheir userid/password combination to other users.This usually means that strict password-security policy documents have to be developed and distributed


20/21


2010 MXS NV/SA

to all users. An even stronger user identification mechanism is the use of biometric data/passwordcombinations. In that case, the userid is being replaced by a biometric (e.g. a fingerprint) ID, which haspreviously been registered in the users record. Once the user has been identified by his biometric ID, theOpen Clinic application will ask for a password before granting access to the system.

2.11.1.1.2 User prof iles

Access to administrative and medical data is managed through definition of user profiles. Such user profiles define precise access rights (read, write, delete) in every data-entry screen of the system. Welldesigned and elaborated user profiles will enhance the systematic application of a strict security policythroughout the institution. Consequently, every user in the system is attributed a user profile (e.g.physician, nurse, administrative clerk...), defining his role in the hospital information managementsystem.

2.11.1.1.3 Personal prof iles

In some rare cases, users need to be granted specific access rights above those they have received intheir user profile. This can be done through a specific point-and-click interface. Rights that have beenattributed in this interface apply only to that single user and have no further influence on other users with

the same user profile.2.11.1.2 Access monitoring

2.11.1.2.1 Acc ess monitoring

Open Clinic offers a module that temporarily blocks a login if a user tries to connect a specified number of times with a wrong password. This prevents malicious attempts to login to the Open Clinic systemusing 'stolen' login data.

2.11.1.2.2 Intrusion detection

In case a user tries a predefined number of times to enter the system with a non-existing user id, the ip-address of the workstation where the unsuccessful attempts come from, will temporarily be refusedaccess to the Open Clinic software. This mechanism prevents malicious attacks where a user tries out alist of logins.

2.11.1.2.3 User tracking

Every access by any user to any single application web-page is being logged by OpenClinic. This AuditTrail feature enables post-factum analysis of 'who has had access to what' in case of complaints or privacy violations. Furthermore, for every page access that is made, performance data (download time,bandwidth usage,data volume) are stored in the system in order to facilitate performance monitoring bytrained IT staff.

2.11.2 Information archiving

If production databases become to big, patient record information can be archived based on a number of

criteria:Deceased patientsRecords which have shown no activity since a specific dateManual selection of patient records

Archiving a record means removing it from the production database and copying it to another medium(hard disk, CD, DVD). The core administrative patient data always remains in the production database:1. Name (first name, last name, alternate names)2. Date of birth3. Record ID number (other than the automatically attributed Open Clinic ID, e.g. reference to a


21/21

OpenClinic20

paper based record)4. National ID number 5. Language6. Gender 7. Place of birth (city & country)

8. Nationality9. Alternate ID (e.g. fingerprint or other biometric data)10. Comments11. Archive medium ID

A previously archived medical record can easily be restored from the archive medium identified by the Archive medium ID in the production database. Usually, medical record archiving will not take placebecause of disk space shortage. Application performance is more likely to be a trigger for deciding toarchive medical records. Today, Open Clinic is running in implementations containing about 500.000active medical records and more than 2.000.000 stored examinations (CBMT).

2.11.3 Clinical mailer and user feedback

The standard edition of Open Clinic offers a simple to use, yet powerful internal mailing system. Userscan send messages to each other, send feedback and request to the local IT staff etc... without theneed of any Internet connectivity or associated mail server infrastructure. The user mailbox isautomatically opened at every login whenever unread messages are present.