OpenClinic Technical Documentation

Belgium/Rwanda MXS 2010

I Contents
I
2010 MXS NV/SA
Table of Contents
Part I Introduction 3
................................................................................................................................... 3 1 Open IT architecture
.......................................................................................................................................................... 3 Open Source software
.......................................................................................................................................................... 3 Disclosed source license
.......................................................................................................................................................... 3 Webbased user interface
................................................................................................................................... 4 2 GEHR model
.......................................................................................................................................................... 4 Short description of the GEHR architecture
................................................................................................................................... 4 3 Application domains
................................................................................................................................... 5 4 Implementations
Part II OpenClinic software
5
................................................................................................................................... 6 1 General aspects
.......................................................................................................................................................... 6 User language
.......................................................................................................................................................... 6 Technical requirements
................................................................................................................................... 6 2 Patient administration
.......................................................................................................................................................... 6 Patient identification
.......................................................................................................................................................... 7 Demographic data
................................................................................................................................... 8 3 Admission, Discharge and Transfer (ADT)
.......................................................................................................................................................... 8 In-patients
......................................................................................................................................................... 8 Admission and identif ication
......................................................................................................................................................... 9 Admission
......................................................................................................................................................... 9 Transf er
......................................................................................................................................................... 9 Discharge
.......................................................................................................................................................... 9 Out-patients
......................................................................................................................................................... 9 Visit identif ication
.......................................................................................................................................................... 9 Patient tracking
.......................................................................................................................................................... 10 Electronic agenda
......................................................................................................................................................... 10 Resource planning
................................................................................................................................... 10 4 Financial management
.......................................................................................................................................................... 10 Activity data
.......................................................................................................................................................... 10 Invoicing and accounting
......................................................................................................................................................... 11 Discharge and end of visit
......................................................................................................................................................... 11 Preliminary invoicing
......................................................................................................................................................... 11 Payment and cash transf ers
................................................................................................................................... 11 5 Medical record
.......................................................................................................................................................... 11 Record identification
.......................................................................................................................................................... 12 History of health events
.......................................................................................................................................................... 12 Generic SOAP structure
.......................................................................................................................................................... 12 Domain specific registration forms
.......................................................................................................................................................... 13 Medical prescription management
......................................................................................................................................................... 13 Ward stock management
.......................................................................................................................................................... 14 ICPC2/ICD10 based thesaurus
.......................................................................................................................................................... 14 Technical examinations management
......................................................................................................................................................... 14 Laboratory data management
......................................................................................................................................... 14 Order entry
......................................................................................................................................... 14 Results
OpenClinic II
2010 MXS NV/SA
......................................................................................................................................................... 15 Medical imaging data management
......................................................................................................................................... 15 Order entry
......................................................................................................................................... 15 Results
......................................................................................................................................................... 15 Pathology lab
......................................................................................................................................... 15 Order entry
......................................................................................................................................... 15 Results
.......................................................................................................................................................... 15 Medical record printing
................................................................................................................................... 16 6 Preventive medicine
.......................................................................................................................................................... 16 Immunization management
......................................................................................................................................................... 16 Vaccination schemes
......................................................................................................................................................... 16 Vaccination card
......................................................................................................................................................... 16 Planning & campaigns
.......................................................................................................................................................... 16 Risk profiles
................................................................................................................................... 16 7 Warnings
................................................................................................................................... 16 8 Reporting
.......................................................................................................................................................... 17 Pathologies per consultation
.......................................................................................................................................................... 17 Pathologies per admission
.......................................................................................................................................................... 17 Pathologies and co-morbidity
.......................................................................................................................................................... 17 Pathology cost
.......................................................................................................................................................... 17 Activity reports
.......................................................................................................................................................... 17 Admission duration reports
.......................................................................................................................................................... 17 Total invoices
.......................................................................................................................................................... 17 Money transfers
.......................................................................................................................................................... 17 Bed occupancy reports
.......................................................................................................................................................... 17 Clinical analyzer
.......................................................................................................................................................... 17 Medical monitoring engine
................................................................................................................................... 18 9 Document printing
................................................................................................................................... 18 10 Human resource management
................................................................................................................................... 18 11 Technical functionalities
.......................................................................................................................................................... 18 Security
......................................................................................................................................................... 18 Access control
......................................................................................................................................... 18 User identif ication
......................................................................................................................................... 19 User prof iles
......................................................................................................................................... 19 Personal prof iles
......................................................................................................................................................... 19 Access monitoring
......................................................................................................................................... 19 Access monitoring
......................................................................................................................................... 19 Intrusion detection
......................................................................................................................................... 19 User tracking
.......................................................................................................................................................... 19 Information archiving
.......................................................................................................................................................... 20 Clinical mailer and user feedback
Index 0
Introduction 3
2010 MXS NV/SA
1 Introduction
MXS is a Belgian Medical Software company that has developed a suite of applications for the
managemen of healthcare information. The company is led by a physician who is also a software
engineer and has a permanent staff of 1 more physician with high-level IT skills, 4 software engineers
and 1 research coordinator. Furthermore, the company has a team of 5 healthcare IT-consultants
working on project basis and a local Rwandan team of 1 public health expert, a physician-expert in
health 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 architecture
and more specifically the Open Clinic Hospital Information Management System that has been
developed 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 software
packages (early nineties) over client-server systems (late nineties) towards nowadays distributed and
web-based software suites. Today, the OpenIT philosophy aims to deliver IT-systems that can be
managed to a large extend by the customer's IT department. Only widely used and solid technologies
are being integrated in OpenIT systems, 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 available
with 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
Linux
Serveral OpenIT products have been implemented on such an OpenSource backbone, even for very large
customers (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 freely
use, modify and evolve the sourcecode whithout permission of MXS. Only reselling of the OpenIT
modules 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. Therefore
the well-known Web interface, one of the easiest and most widely used interface-types in the world, has
been selected to be integrated in the OpenIT architecture. All end-user software manipulation can be
done through a standard webbrowser, which many users are familiar with. If a user can surf the web, he
can use OpenIT based software like Open Clinic.
OpenClinic 4
2010 MXS NV/SA
1.2 GEHR model
From the beginning, MXS has specialized in health information management. The company's core
business 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 has
been 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). The
Good European Health Record, was a three year project within the European Health Telematics research
programme (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 participating
organisations in seven European countries, and included clinicians from different professions and
disciplines, computer scientists in commercial and academic institutions, and major multi-national
companies. The architecture object model, exchange format, term sets and the specifications of access
and 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 one
person, the patient. Within each patient record, the GEHR architecture preserves both the original
structure of the data and how the entries in the record are grouped. Every effort has been made to
propose an architecture which is as generic, flexible and non prescriptive as possible. However, where
clinicians have identified the need to be prescriptive (e.g. in situations where medico-legal security must
be maintained) the architecture incorporates features which may be utilised for this purpose.
Principal GEHR architectural components
the EHCR
provides the container for all data about a particular patient
the Transaction
provides most of the features needed for the medico-legal aspects of healthcare data
provides the mechanism for the control of amendments
represents 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 data
the 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 the
requirements identified by the project for the EHCR. The GEHR project has developed two formal
definitions in support of the architecture: the GEHR Object Model and the GEHR Exchange Format. To
support the development of healthcare record systems incorporating the GEHR architecture, the project
has produced a term set of 2,000 HRI names available in 9 European languages, and a comprehensive
set of 47 anatomical drawings. The architecture, term sets and drawings have all been placed in the
public domain.
1.3 Application domains
The generic OpenIT architecture provides a technological foundation for several applications in the
healthcare domain. In fact, the GEHR project proved that a generic mechanism of structuring medical
information could be applied to fundamentally different clinical specialties. Typical application domains
are curative medicine (private practice and hospital), preventive medicine, disease management and
Introduction 5
2010 MXS NV/SA
clinical research.
Experience however shows that every specialty has it's own way of using these common structuring
concepts. Every specialty has it's own typical needs with regard to specific content and information
aggregation. Therefore, most OpenIT-based systems are being highly customized to meet the exact
requirements 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, DH
Nyamata, 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-Chirurgical
de 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 have
been built on the OpenIT Medical Information Architecture (OpenMIA). The system automates
information 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 engineers
and physicians with high-level ICT-training at MXS (Belgium). The Open Clinic program was first started
in 1990 and has been on the market until 2001. In 2004, the OpenMIA architecture and the OpenClinic
modules 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 Hospital
Extremely 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 language
2. Tomcat web application server (Servlet Engine)
OpenClinic 6
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 compatibility
- Microsoft Windows NT/2000/2003 Server/XP/Vista
- Linux
- Sun Solaris
Availability of all sourcecode to the customer.
Easily extendable 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-10
Open 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 staff-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 transactions
Easy 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 means
that 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 Information
System. Patients must be uniquely identified, in order to keep track of their complete medical and
financial 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. Any
number of data fields that would seem to be missing in the standard implementation, can be added to
the system by the application manager (a specially trained super-user).
2.2.1 Patient identification
As stated earlier, patient identification is crucial when handling sensitive personal information like
medical or financial records.
OpenClinic software 7
2010 MXS NV/SA
The OpenClinic patient identification functions include:
Possibility to attribute an unlimited number of person 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 to
verifying patient identity. These individuals can best identify issues that contribute to errorprone
conditions and develop strategies to reduce their likelihood. Next, they must consistently follow the
procedure and be accountable for their practice by adhering strictly to the policy. Furthermore, clinicians
must hold each other responsible and continually identify risk states and implement processes and
procedures to prevent such errors. Nurses should review existing policies, procedures, and practices
related to patient identification. They need to identify gaps and situations that place patients at risk and
then develop and implement processes to minimize these risks. In many situations, current practices
are not adequate to address
the pace of admissions and number of surgical cases. Many times, the clerk in the admission office
charged 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 Clinic
software 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 the
maintenance of a 'clean' administrative database.
2.2.2 Demographic data
Most common patient-demographic data elements have been integrated in the standard Open Clinic
implementation:
Personal data
1. Name (firstname, lastname, alternate names)
2. Date of birth
3. Record ID number (other than the automatically attributed Open Clinic ID, e.g. reference to a
paper based record)
4. National ID number
5. Language
6. Gender
7. Place of birth (city & country)
8. Nationality
9. AlternateID (e.g. fingerprint or other biometric data)
10. Comments
Medico-administrative data
1. Family physician
2. Other private physicians (specialists)
3. Health Insurance company
4. Health Insurance Contract number
5. Health Insurance status (code + description)
Official addres
1. Street and number
2. Zipcode
3. City
OpenClinic 8
2010 MXS NV/SA
4. Country
5. E-mail
6. Telephone
7. Fax
8. Mobile phone
9. Comments
Residence address
1. Street and number
2. Zipcode
3. City
4. Country
5. E-mail
6. Telephone
7. Fax
8. Mobile phone
9. Comments
For the Rwandan context, the following fields have already been added to the OpenClinic software:
10. Province
11. District
12. Sector
13. Cell
14. Village
Occupational data (work environment)
1. Employer name and address
2. Employee record number
3. Work e-mail
4. Work telephone
5. Work fax
6. Work mobile phone
7. Function
8. Employee category
9. Start date of employment
10. 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 the
healthcare 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-patients
2.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
Admission number. Every medical act, prescription, payment etc... related to the hospital stay will carry
this Admission ID. The Admission number being unique, it can also be used to uniquely identify a
patient within the system.
OpenClinic software 9
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 the
Open Clinic system. The standard Open Clinic implementation holds the following data (some are
optional):
Date and time of admission
Planned date and time of discharge
Ward identification
Bed number identification
Responsible physician identification
Comments
2.3.1.3 Transfer
A transfer in Open Clinic means a change in ward or bed identification data within the context of one and
the 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 identification
New bed identification
New responsible physician identification
New planned date and time of discharge
Reason for transfer
Comments
A unique transfer identification number is automatically attributed 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, the
admission number is closed and the occupied bed is automatically flagged 'available' in the Open Clinic
system. When discharging a patient, the following data can be entered (some are optional):
Effective date and time of discharge
Reason for discharging the patient
Comments
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 will
enable the grouping of all patient data related to one and the same hospital visit. When registering an
outpatient's visit, the following data can be entered into the system (some are optional):
Date and time of the visit
Type of contacts (consultation, examination) to be carried out
1. Contact type
2. Responsible clinician
3. Scheduled contact time
2.3.3 Patient tracking
Patient ADT information permits to keep track of the patient movements within the hospital. A separate
module is provide in Open Clinic to graphically visualize inpatients' bed allocation history and to identify
all medical acts which adhere to a specific moment of the admission period. Open Clinic can also show
a map of the hospital site with the exact location of the patient's allocated bed at any moment.
OpenClinic 10
2010 MXS NV/SA
2.3.4 Electronic agenda
A standard electronic agenda has been integrated into Open Clinic. This user-centered agenda can hold
all scheduled appointments for every user, permitting the definition of 'user groups' which are granted
access 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 users
to make reservations for shared resources such as operating rooms, diagnostic devices, meeting rooms
etc...
2.4 Financial management
Financial management in the standard edition of Open Clinic is based on medical act based billing. This
means that invoices for hospital visits (outpatients) and hospital admissions (inpatients) can be printed
based 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 software
contains a sophisticated module to link specific acts to medical record activity. E.g. the output of a
laboratory result or an X-Ray report will automatically generate the corresponding act codes. But also
medication prescriptions, vaccinations and intellectual activities can be linked to act-codes. This linking
is rule-based and can be maintained by the local application manager.
Acts that are automatically generated by the system, still 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 can
easily be grouped into so called 'activity profiles'. These profiles are being stored into the Open Clinic
database and can be used to quickly add groups of act codes to the medical record (e.g. several
laboratory 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 patient
can be printed by the system. Invoices for a particular patient can be selected on a series of criteria:
Admission ID based invoicing
Visit ID based invoicing
Specific period of time
Selection of specific act codes
1. Manual selection
2. By act code
3. By care provider (user responsible for the act)
Activity code flags (planned, executed, validated)
All criteria can be combined, yet providing a very flexible way of outputting invoice data for specific
situations.
OpenClinic software 11
2010 MXS NV/SA
For every invoice, the following data will be recorded (in supplement of the data retrieved from the
medical record):
1. Date and time of the invoice
2. Identification number of the invoice (automatically attributed by the system)
3. User generating the invoice
4. Total amount of accountable acts
5. Total amount of payments already registered
6. Balance
7. 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 stay or visit can be
printed 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. Cash transfer history related to the Visit ID or the Admission ID
has also been integrated in the invoicing module. This means that the invoicing module will subtract all
registered
payments 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 accountable
activity 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, the
following types of payment and cash transfer have been integrated:
1. Deposits
2. Cash payments
3. 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 ID
2. Date and time of payment
3. Origin of payment
4. Amount
5. Currency
6. 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 hospital
environment, 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 to
more 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 one
medical record (e.g. service based or functional multiplication of records). Sometimes medical records
can 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 1
electronic healthcare record (EHCR). Information in this unique record can easily be clustered in any
form (per service, per ward, time-based etc...) In other words, the EHCR carries the same record
OpenClinic 12
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 and
contains:
Personal history
1. Medications
2. Alcohol & drugs consumption
3. Tobacco usage
4. Medical antecedents
5. Surgery
6. Accidents
Family history
1. Marital status
2. Children & medical antecedents
3. Other family & medical antecedents
Occupational history
1. Professional diseases
2. Work accidents
3. History of relevant occupations & occupational risk factors
4. 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. It
stands for: Subjective, Objective, Assessment and Plan. Each of these sections require the basic
understanding of medical terminology to allow continuity of care. The SOAP format requires medical
terminology that is considered appropriate by the facility where one is working. Each facility has a listed
set of appropriate medical abbreviations and surgical abbreviations. Such a list can easily be integrated
into 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 system
function. The "A" includes the clinician's opinion about the presented case, prognosis, diagnosis and
goals. The "P" includes the plan to progress to the goals set in the "A" and the interventions that are
necessary.
2.5.4 Domain specific registration forms
Although generic SOAP notes might be sufficient for the majority of clinical documentation needs within
the 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 responsible
clinicians, to make sure that the result exactly fits the specific documentation needs and business
processes 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
OpenClinic software 13
2010 MXS NV/SA
- Nutrition
1. Rehabilitation card
2. 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. Medication
prescriptions typically hold the following data:
Name of the prescribed drug
Total quantity of prescribed drug units
Number of prescribed drug units per dag
Begin 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. Stock
modifications 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 exit
has to be attributed to a Visit ID or an Admission ID. Stock exits automatically add accountable act
codes to the patient record.
Stock entry: entry of medication or supplies into the local stock. This information can be entered
manually or can be read electronically from the corresponding SAGE SQL-Tables if available (presuming
that 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 ID
Item name
Item type (medication, bandage...)
Unit (capsule, tablet...)
Package type (box, bottle...)
Units per package
Cost per unit
Invoicing code
Minimum level of local stock
Maximum level of local stock
Furthermore, an 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
OpenClinic 14
2010 MXS NV/SA
calculated by the software (based on data coming from 'active' medical prescriptions and availability in
the 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 Open
Clinic. The software makes use of the same thesaurus as the one requested by the CHUK. The Open
Clinic coding engine is available at all times in any data-entry screen. In order to make real time
coding a feasible procedure, automatic coding will be proposed for selected items in the Domain
specific registration forms. In that way, common symptoms, diagnosis, procedures and prescriptions
can automatically be coded by the Open Clinic package, thus avoiding misinterpretation of clinical notes
in 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 any
other medical documentation transaction. On the other hand, some extra modules have been added to
the system to facilitate the Order entry management.
2.5.7.1 Laboratory data management
2.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 types
Encoding 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 Management
System (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 ward
manager or the laboratory staff). The miniLIMS module enables the retrieval of laboratory requests based
on different criteria:
Laboratory request ID: one particular request
Admission ID or Visit ID: all requests linked to the corresponding ID
Patient ID: all requests linked to this Patient ID
Requesting clinician: all requests coming from the specified clinician
Request status: lists all requests with a specified status (complete, incomplete, received)
All of these criteria can be combined, yet providing a very flexible request retrieval interface. When a
searched 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 immediately
available in the patient's medical record. Every filled-in result automatically generates a corresponding
medical act-code in the patient record (for invoicing purpose). Laboratory results can be viewed by single
result 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
OpenClinic software 15
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 edition
of 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 ID
in 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 physician, the ward manager or
the medical imaging staff). The miniMIMS module enables the retrieval of Medical Imaging requests
based on different criteria:
Imaging request ID: one particular request
Admission ID or Visit ID: all requests linked to the corresponding ID
Patient ID: all requests linked to this Patient ID
Requesting clinician: all requests coming from the specified clinician
Request status: lists all requests with a specified status (complete, incomplete, received)
All of these criteria can be combined, yet providing a very flexible request retrieval interface. When a
searched request has been retrieved, the medical imaging staff can open the corresponding results
record. 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 a
corresponding medical act-code in the patient record (for invoicing purpose). Medical Imaging protocols
can be printed in order to deliver them at the prescribing physician 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 management
system.
2.5.7.3.2 Results
Pathology results are managed exactly the same way as Medical Imaging results. The same miniMIMS
interface is being used.
2.5.8 Medical record printing
Open Clinic provides a complete and sophisticated module for printing of medical record content for a
single patient. Selections can be made on any combination of the following criteria:
Types of examinations
Manually selected examinations
Admission ID or Visit ID
Period of time
OpenClinic 16
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 management
Open Clinic lets the user keep track of every patient's vaccination status. The system integrates
automatic 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 little or no programming knowledge by
configuring a simple XML file. Vaccination schemes can thus easily be adapted to local preferences, yet
permitting clinicians at any time to make any modifications to system-generated dates. Today, Open
Clinic contains international schemes for the following vaccinations:
Tetanos/difteria
Hepatitis A
Hepatitis B
Hepatitis A+B
Yellow fever
Typhus
Menigococ meningitis
Polio
Tick encephalitis
2.6.1.2 Vaccination card
All patient vaccination data are comprehensively summarized on a patient vaccination card, which can
be 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 use
management 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 profiles
aim to help clinicians in deciding which actions should be undertaken in particular risk situations. Risk
profiles 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 are
always shown to the user as soon as he opens the patient medical record. Warnings can also include
lifetime 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 consultation
Pathology distribution per admission
User activity reporting
OpenClinic software 17
2010 MXS NV/SA
Admission duration reporting per pathology
Bed occupancy reporting
Patient origins
Reference center profiles
Status of decentralized stocks
Patient debit and credit operations
Provisional financial status of each admitted patient
Department 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 to
every 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 linked
to any financial data.
2.8.6 Admission duration reports
Duration of admission (average duration & standard deviation) is reported per pathology, per service and
per 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 data
from 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 integrated
Medical Monitoring engine. This engine can be configured to automatically run specific reports on pre
scheduled moments (e.g. every Sunday night) and to send the results to one or more e-mail addresses
OpenClinic 18
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 prints
Microsoft Word-documents
PDF-documents.
Using Adobe Acrobat Professional, any of these forms will be transformed (possibly after scanning) into
a PDF-form that exactly matches the layout provided by the customer. These PDF-forms are stored in
the 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 document
module is being called from within such a screen, the default document list will only display the relevant
(linked) documents.
2.10 Human resource management
Open 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 training
Skills and certificates
Work schedules
Work contracts
Holidays, paid annual leave
Sick leave
2.11 Technical functionalities
A series of functions of the Open Clinic software are pure technical features. Therefore they have been
brought together in this chapter.
2.11.1 Security
An efficient and easy to manage security implementation is crucial for a hospital information
management system. Being a web based system, all medical records are accessible to authorized
users from any workstation in the hospital, regardless the department where the record has been
created. All data is stored in one single database and is managed by one single central application
server (however, the use of multiple application servers would be permitted in case this becomes
necessary in the future).
2.11.1.1 Access control
2.11.1.1.1 User identif ication
Users can be identified and granted access to the Open Clinic application in several ways. The most
common procedure to identify and authenticate users is via a userid/password combination. Specific
password policies (periodic renewal, use of numbers, capitals etc...) can easily be enforced in Open
Clinic 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 system
administrator has no access to the user login data. Users are to be held responsible for not distributing
their userid/password combination to other users.
This usually means that strict password-security policy documents have to be developed and distributed
OpenClinic software 19
2010 MXS NV/SA
to all users. An even stronger user identification mechanism is the use of biometric data/password
combinations. In that case, the userid is being replaced by a biometric (e.g. a fingerprint) ID, which has
previously been registered in the users record. Once the user has been identified by his biometric ID, the
Open 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. Well
designed and elaborated user profiles will enhance the systematic application of a strict security policy
throughout 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 management
system.
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 in
their user profile. This can be done through a specific point-and-click interface. Rights that have been
attributed 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 Access 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 system
using '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 refused
access to the Open Clinic software. This mechanism prevents malicious attacks where a user tries out a
list 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 Audit
Trail 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 by
trained 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 patients
Records which have shown no activity since a specific date
Manual 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 birth
3. Record ID number (other than the automatically attributed Open Clinic ID, e.g. reference to a
OpenClinic 20
2010 MXS NV/SA
paper based record)
4. National ID number
5. Language
6. Gender
7. Place of birth (city & country)
8. Nationality
9. Alternate ID (e.g. fingerprint or other biometric data)
10. Comments
11. 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 place
because of disk space shortage. Application performance is more likely to be a trigger for deciding to
archive medical records. Today, Open Clinic is running in implementations containing about 500.000
active 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. Users
can send messages to each other, send feedback and request to the local IT staff etc... without the
need of any Internet connectivity or associated mail server infrastructure. The user mailbox is
automatically opened at every login whenever unread messages are present.