| Health Information Systems for Low-Income Countries: An Overview Canadian Society for International Health |
![]() |
Introduction
The South Caucasus Health Information Project (SCHIP), which is funded by the Canadian International Development Agency (CIDA) and managed by the Canadian Society for International Health (CSIH), began in September, 2001 and completed its operations in June, 2005.
The aim of the project was to strengthen health reform in Armenia, Azerbaijan and Georgia through the appropriate application of health information technology and information management strategies. SCHIP focused on the development of long-term, sustainable tools for health reform, including the development of a computerized health information system (HIS). This demonstration project comprised: software development, short-term training programs for the participating institutions, and equipment and telecommunication networks where appropriate. It showed how health information concerning the catchment population can be used for health planning and governance. The experience gained can be transferred to other modalities of health care and the HIS can be replicated at additional institutions.
HIS application software is a database system built for modern information requirements, which also accommodates existing forms and procedures. The system is conceptually based on an electronic health record; it supports the collection of data that describe patient health care events, demographics and social status. The software uses international standards to code signs, symptoms, diseases and procedures. The system captures data about hospital stays and outpatient visits, which include diagnoses, medications, procedures, diagnostic tests, immunizations, consultations, pregnancies, deliveries and reproductive health counseling.
The CSIH demonstration system is currently running at the following sites in three South Caucasus countries, including:
![]() |
Center for Disease Control and Medical Statistics, Tbilisi, Georgia using a wired local area network |
![]() |
Gori City Public Health Department, the Regional Health Office and four hospitals, Gori, Georgia using wireless telecommunication |
![]() |
Center for Perinatology, Obstetrics and Gynecology, Yerevan, Armenia using a wired local area network |
![]() |
Maternity hospital and women's polyclinic, Artashat, Armenia using a wired local area network |
![]() |
Five medical facilities and the Public Health Department, Ganja City, Azerbaijan using stand alone computers |
HIS design objectives
The HIS provides support to decision makers at the institutional, regional and national levels to promote maternal health. In order to achieve this, the database has been designed to capture fine grain patient management and clinical data that can be used directly for patient care and operational management while simultaneously being aggregated and analyzed by health authorities to better administer the distribution of limited healthcare resources. The system captures data from hospital stays and outpatient visits, which include events resulting in diagnoses, medications, procedures, diagnostic tests, immunizations, consultations, pregnancies, deliveries and reproductive health counseling.
The HIS permits various institutions to share data thereby ensuring continuity of care. The choice of maternal health as a point of focus, then, has resulted in a system design that is less rather than more restrictive. Except for the collection of perinatal data, the HIS is little different from one providing support for general care.
The system conforms to international coding standards yet accommodates the most critical regional data requirements. Because the regional requirements are country specific, they are configurable as are indeed the choice of alphabet, language, data encoding and font.
The HIS was designed to meet the needs of low-income countries. The infrastructure in the South Caucasus is weak: the power is unreliable and there are few personal computers. The existing computers are often quite old, have slow CPU's, limited memory, and old operating systems. Because the HIS makes use of a web client-server topology, it is possible to use these older computers effectively as workstations.
Principal system features
| Multi-institutional | Data is identified by the server where it was entered and the facility making the entry. It can be merged into a single database and shared by other facilities. |
| Multiple institution types | Inpatient and outpatient institutions can be accommodated provided that "cases" are managed appropriately. An inpatient is assigned a case number when he or she is admitted to a given facility; an outpatient is assigned a persistent case number when he or she is first admitted to a given facility. |
| Electronic patient record | Provided proper procedures are followed, a single electronic patient record can be compiled and, within confidentiality constraints, shared among participating facilities. |
| Graphical user interface | A comparatively simple graphical user interface has been deployed consistently throughout the system. |
| Data confidentiality | A user password system has been implemented that places read and write permissions on patient case data. It also restricts access to programs. An audit log is maintained that records changes to the database and user activities. |
| Data security | Utilities can be assigned to a user application menu to backup and restore the database, verify and repair database indexes, and report and verify the audit log. Some of these utilities can be installed to run automatically at specific times of the day. |
| Web client-server | A server can be accessed simultaneously by multiple browser clients at multiple facilities. |
| Case-based data | The database captures patient symptoms, signs, diagnoses, procedures, medications, immunizations, consultations, diagnostic tests, pregnancies, deliveries, and reproductive health observations. |
| Customization | The HIS has programs to enter translations for the text displayed in the entry windows, online help windows and choices in list boxes. Some of the fields can be reassigned to collect other than their intended data. |
| ICD-10 diagnoses | An electronic code book of diagnoses is available in Armenian, Georgian and Russian. A code book with incomplete text descriptions is available in English. The code book is used both to display the text with the "includes" and "excludes" as well as to validate the codes entered by users. Two languages can be used simultaneously in the same system, for example, Armenian and Russian. |
| ICD-9CM procedures | A list of ICD-9CM procedures is available in English. The code book works in the same way that the ICD-10 code book does. If the code book were translated, the software would permit two languages to be used simultaneously in the same system. |
| Patient identifiers | Although use of unique patient identifiers is recommended, there is no prerequisite that such identification be used. Patient identification can be based on a large number of personal characteristics that include family relationships. If duplicate patient records were created by accident, there is a program that could be used to locate and merge them into one. |
| Ensured data consistency | All event transactions are retained in the database even after they have been superseded. There is only one process that actually deletes superseded data from the database and it can be run manually by the system administrator. Normally, data is "disabled", not deleted. |
| Cloning | A server can be cloned to build other servers. This makes it possible to "roll out" a collection of servers after an initial installation. It also makes it possible to prepare a redundant server as a precaution against server failure. |
| Data exchange | Data from one server can be imported to another. In a collection of servers, data can be transferred from the satellites to the master server that accumulates the data and transfers the result back to the satellites. |
| Report writer tools | The system has a universal report builder and report generator. A number of standard reports have been defined that can be modified as desired using the "Report Entry" program. |
| List reports | Each database entry program has a "List" capability that generates a printer-friendly display of the data. |
| Online help | Each entry program has online help. |
| Data dictionary | A complete specification of the database is available with appropriate descriptions for each table and element. |
| Program source | The program source code for the HIS is supplied as part of the installation. The system can be rebuilt with the desired changes made to the database tables and programs. |
| No licensing costs | The Linux platform has no licensing cost provided that the conditions of the GNU General Public License and the GNU Free Documentation License are observed. The HIS software has no licensing cost but the user organization must respect the copyright and contractual conditions placed on the software distribution. |
Software Licensing, Copyright and Distribution
The HIS is built on an open source platform. The Linux operating system, standard Linux tools, a high performance database engine and a web service are used. Consequently, the platform is far less expensive to implement than other proprietary systems such as Microsoft® Windows©. The application software itself has a copyright that is held by CSIH and Dr. Jim McDaniel, the software designer and developer. At the end of the project, copies of the software will be donated to the partner organization of each country with an agreement that permits the organization to distribute the software to not-for-profit institutions within the country. Further development and software maintenance will become that organization's responsibility.
Technical Specifications
The HIS software uses a web client-server architecture. The server runs the MySQL database and the Apache web services. The application software is written in PHP and it generates HTML web pages for the clients. A client workstation can have any operating system and requires only a network card and a compatible web browser. Older workstations can be used provided they support a recent version of a compatible browser.
The following are the minimum technical configurations of a server and a workstation:
| Server: | |
![]() |
Pentium III processor or better with floppy drive, keyboard, monitor and mouse |
![]() |
128 MB memory minimum |
![]() |
two 20 GB hard disk drives |
![]() |
CD-RW drive |
![]() |
10 Mbps Ethernet interface (if installed on a local area network) |
![]() |
Red Hat Linux or Mandrake Linux version 8.x or 9.x |
![]() |
PHP 4 (bundled with Linux) |
![]() |
m4 (bundled with Linux) |
![]() |
MySQL version 3.23 or later but not version 4 (bundled with Linux) |
![]() |
Apache versions 1.3.27, 2.0.43 or later (bundled with Linux) |
![]() |
HIS application software |
| Workstation: | |
![]() |
Intel 80486 or better with floppy drive, keyboard and mouse |
![]() |
16 MB memory minimum |
![]() |
1 GB hard disk drive |
![]() |
color monitor with a minimum resolution of 800 x 600 |
![]() |
10 mbps Ethernet interface |
![]() |
printer |
![]() |
Internet Explorer, Netscape, Opera, Mozilla, Mozilla Firefox web browser |
![]() |
UltimateZip or WinZip file compression software if file decompression software is not bundled with the operating system |
Database Characteristics
Patient care data are entered as health care events occur. Although this is often done by clerical transcription from paper forms, physicians and nurses are being encouraged to take an active role in entering and viewing data as the events occur. Because the data are differentiated by case at the event level, they can be used effectively by clinicians, chief doctors, administrators, and local, regional and national managers. Summary information can be easily processed and compiled by defining and producing the appropriate reports.
The HIS database has been designed to accommodate multiple facilities of varying types. Data can be imported from several servers into a single central database for redistribution. Consequently, a patient's encounters are compiled into a single electronic health record and comprehensive patient histories and summary management reports can be produced. Where facilities are geographically close such as co-located ambulatory clinics and a hospital, it is possible for the facilities to share a single database server. This substantially reduces the operational overhead of the HIS.
Although personal identifiers simplify data entry and substantially improve health record integrity, the HIS does not require a personal identifier for each patient or client. A person can be identified by a wide range of personal attributes, which include but are not limited to name, date of birth, gender, passport number, and family relationships. As well, the application software provides tools to identify and consolidate fragments of patient health records.
A patient catchment area is classified by its health region and health district. It can be assigned arbitrarily to either, as health regions and health districts are independent of each other. Consequently, summary reports can be defined for geographical areas that may or may not be overlapping or hierarchical.
The database is fully normalized; this means that codes are used throughout to reference all critical entities such as providers, facilities, catchment areas, health regions and districts. For example, if a catchment area, which was originally identified to belong to a particular health region, is assigned to another health region, only one change must be made to reassign every patient and facility - the region assignment itself.
As an entry screen is formatted for display, list box and check box choices are retrieved from a code table. A code entry program can be used to change choice descriptions, and to add or remove choices. The changes are reflected immediately in all entry and report programs.
The HIS database can be further augmented with tables containing the standard costs for materials and services so that a health authority can produce financial and accounting reports. As well, the patient record can be expanded to include conditions for insurance reimbursement.
If the database does not have a table defined for a specialized patient encounter event, a "survey" can be designed that collects data and stores it in an "observation" table. The survey program requires no specialized programming skills; it requires only that the screen fields be defined.
Standard Coding Systems
The following international standard coding systems are used in the CSIH system:
![]() |
ICD-10 diagnoses |
![]() |
ICD-9CM procedures |
Although the database is designed for ICD-9CM procedures, other procedure codes can be used provided the coding system conforms to the same structure. It is also possible to assign non-standard alternate procedure codes to ICD-9CM procedures for the purposes of reporting.
As data can be shared among institutions, it is important that other national standards be used. Most countries have "blue books" of standard drugs and these can easily be copied to the database. For example, the U.S. National Drug Classification system can be used. Other national standards include the coding of health regions, health districts, facilities, catchment areas, immunization agents and diagnostic tests.
There is no requirement for a national registry of providers. Each provider is uniquely identified at the database server where the profile has been entered. An additional field permits a unique provider registry number to be referenced for consolidated reporting should a provider have multiple profiles caused by her or his attendance at more than one facility.
User Interface Characteristics
The user interface designed for clinicians and hospital staff. It is simple and consistent in order to encourage users to enter data accurately as events occur. It accommodates both normal and "expert" users. On-line help is available for every data entry screen.
The ICD-10 diagnosis coding subsystem is sophisticated; a user can enter one or more phrases to search an electronic code book. The code book can be viewed as a web page and references between codes can be followed by clicking on relevant links. Two code books, which are available in the English, Russian, Armenian and Georgian, can be installed and so that a user can switch from one language to another.
The application screens are displayed in the language that is native to the participating country. Currently there are translations from English to the Armenian, Georgian and Azerbaijani languages. The HIS has application programs to install the translations. This feature also increases the flexibility of the database by allowing some data elements to be renamed. If, for example, there were no need for "patient occupation", this element could be used for some other data.
Reports
Users can design their own reports using a report writer tool that is integrated into the HIS. The tool makes use of a "data dictionary" that describes the data elements and their relationships. As well, every entry program has a "List" function that produces report. Finally, there are 16 predefined reports that show clinical, operational and management information. These reports are can be modified using the report writer tool. Other reports are being defined as software development nears completion.
Data Security and Confidentiality
The HIS has a number of security features to ensure data confidentiality and to maintain data integrity. The following contribute to this security:
![]() |
Online and offline backups can be made. |
![]() |
Backups can be archived to CD-ROM. |
![]() |
Each user must log into the system using a password. |
![]() |
Each change to the database is written to an audit log. |
![]() |
Every version of a health care transaction is retained until a system administrator culls them from the database. |
![]() |
The Linux operating system provides built-in crash recovery and file journaling. |
![]() |
Each user has a profile that determines his or her role and capabilities. |
![]() |
Application programs are displayed on menus according to the role of each user. |
![]() |
Normal users, that is users who are not "super users", have access to data from only their own facility or to data to which they have been granted access. |
![]() |
A server that has a network can be locked in a physically secure room. |
![]() |
If the server is physically secure, the database can be accessed only by the application programs. |
![]() |
A server can be shut down automatically by the uninterruptible power supply. |
![]() |
Many other security features can be installed using standard hardware and operating system features such as firewalls, encryption, mirroring, and RAID. |
Functional Description
This section describes the functionality of the programs displayed on the HIS menus. An item is assigned to its menu according to a database attribute that can be changed easily. Menu items can be multiply defined in order to place them on several menus, moved from one menu to another or removed entirely from the system. Also, as part of the security system, any menu item can be restricted to specific user roles. It should be noted that users who are given "super user" privilege are able to perform more actions than users who are not. For example, a super user is able to reopen a patient case once it has been closed.
The database table, apptbl, determines the structure of the menus. The value specified in the menu column for a given application program determines the menu on which the program is displayed: "A" - "Database administration menu", "M" - "Main menu", "O" - "Database operations menu", and "R" - "Reports menu". The main menu program, itself, has no value specified for this column. This table must be updated manually using SQL.
Figure 1 is a menu flowchart that shows each program name with a superscript that references its functional description in one of tables I, II, III or IV. Although the functional descriptions provide a list of input fields, they do not provide a list of all data fields that are displayed. Menu items on the "Database administration menu" that are shown in parentheses are programs that are not yet integrated into any subsystem.
![]() Figure 1 - Menu Flowchart |
Menu items are displayed on each menu with submenus first, followed by program names in alphabetical order. This order is reflected in Fig. 1 except for those items that have been separated by a divider because of their unique functionality. A change in the program name can result in a reordering of the menu items. For example, the "Report entry" program is shown at the top of the"Reports Menu" because its name contains a leading space that causes it to be sorted to the top of all other items on the menu.
Each entry program has a "Browse" button and a "List" button that can be used to search for or to display data records. The records are filtered according to criteria specified in the entry fields. Wild card characters may be specified in many of the fields so that a range of records may be retrieved. All entry programs have on-line help that can be tailored to suit the users.
The items shown on the "Reports Menu" that are standard reports that are distributed with the system. Additional user-defined reports can be installed on this menu. Further information about the reports can be found in the "SCHIP Health Information System: User's Manual".
In addition to the programs described here, there is an "HIS Clone Builder" program that is used to create a copy of an existing HIS. This program, which is described in the "SCHIP Health InformationSystem: System Administrator's Installation Manual", is not displayed on any menu.
Table I - Functional Descriptions of Programs on the Main Menu
| Reference | Description | |
| 1 | Main menu This is a collection of submenus and frequently used programs. If a submenu is missing from this menu, so too are all of the programs that would have been displayed on that submenu. | |
| Admission discharge and transfer entry This is used to register inpatient encounters, to assign and reassign a patient's bed and ward, and to discharge a patient. A patient "case" applies to only one admission. Once a patient has been discharged the patient case is closed automatically. The program has multiple pages in which data is entered: | ||
| Case | o Patient data (described by item 16) o Registering facility o Case registration book and case number (manually assigned) o Case status ("Open" or "Closed") o Case note (free text) o Facility and user access restrictions (defaults to the registering facility) | |
| Admission | o Admission date, time and type ("Emergency", "Scheduled", "Referral"etc.) o Provider who supervised the admission (mandatory) and provider who is attending the patient's care (optional) o Facility and provider making the referral (if applicable) o Ward and bed assignment (optional) o Admit note (free text) | |
| Diagnosis | o One main reason for admission coded in ICD-10 (symptom) o Unlimited number of diagnoses coded in ICD-10 characterized as "Primary", "Final", and "Discharge" each with a diagnosis date, the provider who made the diagnosis, and the prevention program code associated with a diagnosis. (The program entry field can be disabled.) | |
| Discharge | o Discharge date, time, type ("Self" or "Provider") and disposition ("Recovered", "Died", etc.) o Provider who ordered the discharge o Discharge destination ("Referred" or "Home") o Facility referred to (if applicable) o Discharge note (free text) | |
| Transfer | o Unlimited number of transfers o Date and time of current assignment o Provider who ordered the assignment o Ward and bed assigned o Transfer note (free text) | |
| 12 | ICD-10 code finder The "ICD-10 code finder" is available for manual coding; it does not alter data in the database. It is integrated into the other encounter entry programs - "Admissions discharge and transfer entry", "Inpatient care entry", and "Outpatient encounter entry". The code finder can be used to search for signs, symptoms, and diagnoses either hierarchically using chapter, block or code or using a search expression. A code is displayed with a "flag" if dual coding is required,whether or not the code can be the cause of death, and the age range and sex of the patient to whom it is applicable. If fully and appropriately installed, the code finder can search and display the text descriptions that are in the ICD-10 code book in two languages. The "Include" and "Exclude" conditions for each code provide hypertext links to other codes in the electronic code book. | |
| Immunization entry This program can be used to enter immunizations without specifying a patient encounter. The "Inpatient care entry" and "Outpatient encounter entry" programs associate an immunization event with a specific patient encounter. The program permits entry of the following data. | ||
| o Facility and provider that are responsible for the vaccination o Patient data (described by item 16) o Date and type of immunization o Supplier, lot number and dose of the immunizing agent o General and local adverse reactions to the immunization o Contraindications for the immunization | ||
| Inpatient care entry This is used to enter events related to inpatient diagnosis and treatment. It is designed to complement the "Admission discharge and transfer entry" program, which is used to admit and discharge the patient. Data can be entered for open cases only. Although other data entered using the "Admission discharge and transfer entry" program is displayed, the program permits entry of the following data using multiple pages. | ||
| Case | o Patient data can be used as a search criteria and may be modified (described by item 16) o Case registration book, case number and case status can be used as search criteria only | |
| Status | o Attending provider o Date and time of ward and bed assignment o Provider who ordered the assignment o Ward and bed assigned o Transfer note (free text) | |
| Symptom | o Unlimited number of symptoms coded in ICD-10 o Provider who diagnosed the symptom o Date the symptom occurred and date when it ended o Reason for recording the symptom (main reason for admission, alternate reason for admission, etc.) o Note (free text) | |
| Sign | o Unlimited number of signs coded in ICD-10 o Provider who diagnosed the sign o Date when the sign occurred and date when it ended o Note (free text) | |
| Diagnosis | o Unlimited number of diagnoses coded in ICD-10 o Provider who made the diagnosis o Date when the diagnosis was made and the date when it was no longer appropriate o Type of primary diagnosis (optional) o Type of final diagnosis (optional) o Note (free text) | |
| Test | o Unlimited number of diagnostic tests o Status of the order for the test ("Pending", "Normal results", "Abnormal results") o Provider who ordered the diagnostic test o Code of the test o Date and time of the test o Provider who conducted the test o Note describing the results (free text) | |
| Procedure | o Unlimited number of medical procedures o Status of the order for the procedure ("Pending" or "Complete") o Provider who ordered the procedure o ICD-9 procedure code o Date and time of the procedure o Department that conducted the procedure o Outcome of the procedure ("Succeeded", "Succeeded with complications", etc.) o Provider who performed the procedure o Note describing the results (free text) | |
| Medication | o Unlimited number of prescriptions o Status of the prescription ("Pending" or "Complete") o Date and time of start of regimen o Provider who filed the prescription o Drug code o Quantity ordered and dispensed o Strength, dosage, dispensing units and frequency of administration | |
| Immunization | o Unlimited number of immunizations o Date and type of immunization o Supplier, lot number and dose of the immunizing agent o General and local adverse reactions to the immunization o Contraindications for the immunization | |
| Consult | o Unlimited number of consultations o Status of the consultation request ("Pending" or "Complete") o Provider who ordered the consultation o Requisition (free text) o Date and time of the consultation o Facility making the consultation o Consultant o Consultation report (free text) | |
| Pregnancy | o Unlimited number of pregnancies that are independent of recorded deliveries o Status of the consultation request ("In progress", "Full term", or "Terminated") o Date of conception o Projected date of delivery (default is based on date of conception) o Pregnancy details that include such items as height and weight, number of ultrasound scans, risks, etc. o Facility making the consultation o Provider making the report o Facility making the report o Note (free text) | |
| Delivery | o Unlimited number of deliveries that are independent of recorded pregnancies - multiple deliveries must be recorded separately. A live born delivery establishes a biological relationship between the mother and her infant and registers the infant as a case. o Date and time of delivery o Outcome ("Live born", "Prenatal death", "Aborted", etc.) o Delivery details that include such items as birth method, units of transfusion blood, analgesics used, anestheia used, etc. o Provider responsible for the delivery o Sex, surname and given names of the infant o Birth details that include such items as weight, length, head circumference, cord-blood pH, Apgar, etc. o Note (free text) | |
| Outpatient encounter entry All encounters and events for outpatients are recorded using this program. Each patient has a facility-specific case that remains open for any number of visits until the case is closed manually. Data can be entered for open cases only. The entry program combines the functionality of the inpatient "Admissions discharge and transfer" and "Inpatient care entry" programs but different data validation edits are applied and, in some cases, different data are collected. | ||
| Case | o Patient data (described by item 16) o Registering facility o Case registration book and case number (manually assigned) o Case status ("Open" or "Closed") o Case note (free text) o Facility and user access restrictions (defaults to the registering facility) | |
| Encounter | o Encounter date, time o Provider who attended the patient o Main reason for the patient visiting the facility ("Referral", etc.) o Facility and provider making the referral (if applicable) o Encounter note (free text) | |
| Symptom | o Unlimited number of symptoms coded in ICD-10 o Provider who diagnosed the symptom o Date the symptom occurred and date when it ended o Note (free text) | |
| Sign | o Unlimited number of signs coded in ICD-10 o Provider who diagnosed the sign o Date when the sign occurred and date when it ended o Note (free text) | |
| Diagnosis | o Unlimited number of diagnoses coded in ICD-10 o Provider who made the diagnosis o Date when the diagnosis was made and the date when it was no longer appropriate o Note (free text) | |
| Test | o Unlimited number of diagnostic tests o Status of the order for the test ("Pending", "Normal results", "Abnormal results") o Provider who ordered the diagnostic test o Code of the test o Date and time of the test o Provider who conducted the test o Note describing the results (free text) | |
| Procedure | o Unlimited number of medical procedures o Status of the order for the procedure ("Pending" or "Complete") o Provider who ordered the procedure o ICD-9 procedure code o Date and time of the procedure o Facility that conducted the procedure o Outcome of the procedure ("Succeeded", "Succeeded with complications", etc.) o Provider who performed the procedure o Note describing the results (free text) | |
| Medication | o Unlimited number of prescriptions o Status of the prescription ("Pending" or "Complete") o Date and time of start of regimen o Provider who filed the prescription o Drug code o Quantity ordered and dispensed o Strength, dosage, dispensing units and frequency of administration | |
| Immunization | o Unlimited number of immunizations o Date and type of immunization o Supplier, lot number and dose of the immunizing agent o General and local adverse reactions to the immunization o Contraindications for the immunization | |
| Consult | o Unlimited number of consultations o Status of the consultation request ("Pending" or "Complete") o Provider who ordered the consultation o Requisition (free text) o Date and time of the consultation o Facility making the consultation o Consultant o Consultation report (free text) | |
| Pregnancy | o Unlimited number of pregnancies that are independent of recorded deliveries o Status of the consultation request ("In progress", "Full term", or "Terminated") o Date of conception o Projected date of delivery (default is based on date of conception) o Pregnancy details that include such items as height and weight, number of ultrasound scans, risks, etc. o Facility making the consultation o Provider making the report o Facility making the report o Note (free text) | |
| Delivery | o Unlimited number of deliveries that are independent of recorded pregnancies - multiple deliveries must be recorded separately. A live born delivery establishes a biological relationship between the mother and her infant and registers the infant as a case. o Where the delivery occurred ("Home delivery" or "Facility delivery") o Date and time of delivery o Outcome ("Live born", "Prenatal death", "Aborted", etc.) o Delivery details that include such items as birth method, units of transfusion blood, analgesics used, anestheia used, etc. o Provider responsible for the delivery o Sex, surname and given names of the infant o Birth details that include such items as weight, length, head circumference, cord-blood pH, Apgar, etc. o Note (free text) | |
| RH | o Unlimited number of reproductive health assessments that are independent of pregnancies and deliveries o Date of the assessment o Provider who made the assessment o RH details such as height, weight, blood pressure, WHO well being score, risks, etc. o Method used for contraception o Quantity of contraceptives dispensed by the facility o Reason for changing contraceptive method (if applicable) o Currently pregnant o Observations (free text) | |
| Patient record entry Inpatients and outpatients are entered using this program. It also is the program that is used to locate an existing patient record for other programs such as the "Admission discharge and transfer entry" and "Outpatient encounter entry" programs. It has three pages with input fields. Most of the fields are optional - in fact, many of the fields may be renamed and substituted for other data. The "Browse" and "List" capability is able to exploit the relationships among parents and children to locate patients. | ||
| Identity | o Name (mandatory) and patronymic o Catchment area where the patient lives (mandatory) o Personal health identifier for the patient o Nationality and passport number o Dates of birth (mandatory) and death o Gender (mandatory) o Blood group o Name of the family practitioner o Name and relationship of the patient's nearest contact o Allergies and contraindications | |
| Status | o Marital status o Level of education o Where the patient lives, i.e., urban or rural, and type of residence o Types of cohabitants o Occupation, i.e., type of employment, and type of industry o Health status and index of activities of daily living o Race and ethnicity o Languages spoken o Refugee status | |
| Family
| o Name of spouse o Name of mother and father, whose parent/child relationships are entered in the database. o Unlimited number of children each with his or her respective date of birth, gender and catchmentarea whose child/parent relationship is entered in the database. A relationship that is entered as a result of a recorded delivery is shown here as well. | |
| Survey entry A user may define a custom encounter entry program, which is run as a "survey". Although "Survey entry" does not permit users to register patient cases, it does permit users to add survey data to existing open cases. Each survey displays a standard "Case" and "Encounter" page as well as other pages that are user-defined. | ||
| Case | o Patient data can be used as a search criteria and may be modified (described by item 16) o Case registration book, number and status can be used as search criteria only o Type of survey encounter | |
| Encounter | o Encounter date and time o Provider who took the survey o Facility and provider making the referral (if applicable) o Note (free text) | |
Table II - Functional Descriptions of Programs on the Database Administration Menu
| Reference | Description | |
| 2 | Database administration menu This is a collection of programs that are typically restricted to trusted users. Many of the programs are used to maintain data in the essential master tables of the database, such as the provider and facility tables. | |
| Catchment area entry Facilities and patients are assigned to geographical areas for reporting purposes. A catchment area can be optionally grouped within a district or region for cumulative reports. Each area has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o Area code and name o Region (optional) o District (optional) | ||
| Code entry Codes are used to define picks found in check and list boxes. They are also used by the "Survey entry" program to define labels. Picks belonging to a form "element"can be added, changed or deleted by changing the code table "element" set. | ||
| o Element name, description and type which group zero or more codes o Numeric code value o Code-associated datum o Code label | ||
| Contact entry The names and addresses of people who are patients or patient contacts are stored in a single table. The "Patient record entry" program calls this program. | ||
| o Surname and given names o Telephone numbers o Addresses o E-mail address | ||
| Department entry Departments are areas of a facility that provide medical procedures to inpatients. At least one department must be defined for each facility. (Outpatient facilities do not make use of departments.) | ||
| o Facility o Department code and name | ||
| Diagnostic test entry This program is used to maintain a system-wide table of standard diagnostic tests that can be conducted at any of the facilities that use the HIS. Each test has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o Test code and description | ||
| District entry A district is a geographical area that can contain one or more catchment areas. It belongs optionally to a region or vice versa. It is used for reporting purposes only. Each district has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o District code and name | ||
| Drug entry This program is used to maintain a system-wide table of standard drugs that can be prescribed or dispensed at any of the facilities that use the HIS. The program and its underlying table have been designed to store data similar to that in the U.S. National Drug Classification. | ||
| o Drug code and trade name o Labeler code, i.e., code used to identify the supplier o Product code given to the drug by the supplier o Strength, units, dosage form of the drug o Multiple classes to which the drug belongs | ||
| Equipment type entry This program is used to maintain a system-wide table of different types of equipment. The program has been developed for an equipment inventory subsystem that has not yet been written. Each equipment type has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o Equipment type and description | ||
| Facility entry This is used to maintain a system-wide table of facilities. Although it is possible to enter only those facilities that are using the HIS, it is far better to have a list of all major facilities so that patient referrals can be recorded properly. A facility should have a designated catchment area so that meaningful reports can be defined. Each facility has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o Facility code and name o Telephone and FAX numbers o Facility type, jurisdiction, specialization and type of patients served o Capacity, e.g., number of beds o Catchment area o Address o E-mail address | ||
| ICD-10 code setup The ICD-10 classification (or classifications, if an alternate language is installed) can be modified. Although chapters and block descriptions may be changed, they may not be added or deleted. New codes can be added to existing chapters and blocks only. Although the code descriptions may be entered, this program does not permit changes to be made to the electronic code book, which contains "Include" and "Exclude" conditions. (The ICD_10 tables must be preloaded with the chapters and blocks before this program can be used.) | ||
| o ICD-10 code for a symptom, sign or diagnosis o Description o Wether or not the code can be the cause of death o Age range and sex of the patient to whom it is applicable | ||
| ICD-9 procedure code entry This program is able to maintain codes in an existing classification such as ICD-9CM. Like the ICD-10 subsystem, the ICD-9 procedure subsystem is capable of managing codes in two languages. New codes can be added to existing chapters and sections only. Although the code descriptions may be entered, this program does not permit changes to be made to the electronic code book, which contains "Include" and "Exclude" conditions. (The ICD_9CM or similarly structured tables must be preloaded with the chapters and sections before this program can be used.) | ||
| o ICD-9 code for a medical procedure o Description o Age range and sex of the patient to whom it is applicable | ||
| Immunization procedure entry A table of standard immunizations also provides a schedule for the immunization of children. This table is referenced by all facilities using the HIS. An immunization is identified by its type and its place in a series of like immunizations. This accommodates those situations where booster vaccinations are required after an initial vaccination. As well, each immunization procedure has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o Immunization series, sequence number and description o Comment (free text) o Reason for the immunization ("Required", "Recommended", etc.) o Age in years, months, weeks or days when the procedure is to occur | ||
| Program entry A standard table of prevention programs, which applies to all facilities using the HIS, can be maintained. These programs are used to track specific cases of disease incidence and prevention assistance. Programs may be associated with disease diagnoses using the "Admission discharge and transfer entry" program. This feature can be installed or removed by changing the HIS configuration. Each prevention program has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o Program code and description | ||
| Provider entry Ideally, a complete table of all physicians, diagnostic technicians and nurses for all facilities within the region served by the HIS should be entered. The program is designed to permit each facility to enter its own providers but care should be taken to enter a provider only once even though they may work at more than one facility. If a provider from an "outside" facility makes a patient referral, he or she should also be entered. The provider code must be a unique identifier that is system wide. | ||
| o Provider code, surname and given names o Telephone numbers o E-mail address o Employee type ("Physician", etc.) o One main facility and up to three alternate facilities o One main specialty and up to three alternate specialties | ||
| Provider specialty entry This permits a system-wide classification of specialties for physicians and, possibly, other providers to be entered and maintained. Each specialty has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o Specialty code and description | ||
| Region entry A region is a geographical area that can contain one or more catchment areas. It belongs optionally to a district or vice versa. It is used for reporting purposes only. Each region has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o Region code and name | ||
| Role entry A role specifies a of application programs that are displayed on the menus of users who have been assigned that role. As with user logins, roles can not be transferred from one HIS server to another. A role that specifies submenu programs must designate both the programs and the submenus on which they are displayed. | ||
| o Role o Programs (modules) that are accessible by the role | ||
| Supplier entry This permits entry and maintenance of a system-wide table of vendors of drugs, vaccines and other types of supplies. A supplier that is classified as being a "vaccine supplier" is listed by the immunization subsystem. | ||
| o Supplier number and name o Labeler code used to identify drug suppliers o Multiple supplier types ("Drug", "Vaccine", etc.) | ||
| Supplier type entry This program is used to maintain a system-wide table of different supplier types. The program has been developed for an materials management subsystem that has not yet been written. Each supplier type has a unique, manually-assigned "number" that is used internally to link database tables. | ||
| o Supplier type code and description | ||
| Survey field entry The "Survey entry" program uses fields to dynamically structure a survey form. A survey form is characterized by an "Encounter type". Then the form is broken down hierarchically by pages, page sections and fields. This program is used to enter this structure and relies on those codes entered in advance using the "Code entry" program. | ||
| o Encounter type (references code element "enctype") o Specification type ("Page", "Section" or "Field") o Page name (references code element "fldpage") o Section name (references code element "fldgroup") o Sequence ordering number o Field label (references code various elements) o Type of entry ("Checkboxes", "Listbox", "Listbox and value", "Value" or "Note") o Method of field initialization ("Clear" or "Carry forward") o Whether or not field entry is mandatory o Field validation method ("Whole number", "Date", etc.) | ||
| User entry Each system user must have his or her own login with associated password. A login is associated with a role that determines which menu items are displayed. Also, a login can be used to enter data at only one facility. (If a user works at more than one facility that user must have more than one login.) User logins and roles can not be transferred from one server to another. Only "super users" have the privilege of changing more than their name and password. | ||
| o User login and name o Password o Facility where the user works o Wether or not the user is a "super user" o User's role | ||
| Ward entry Wards are areas of a facility that have beds for inpatients. (Outpatient facilities do not make use of wards.) The wards of each inpatient facility should be entered each with its respective capacity in order to report on ward occupancy. | ||
| o Facility o Ward code and name o Capacity, e.g., number of beds | ||
| 223 | Georgia form 66 data extraction This program generates dBase IV files to export closed inpatient cases to the Georgian information system. | |
| 224 | HIS Labels and text setup On-line help, labels that are shown on forms and reports, error messages and notification messages are stored in the database in English (the base language) and any alternate language which is to be used by the programs in the system, which also may be English. This program permits this alternatetext to be changed in order to translate it or otherwise customize the programs. Only those records that already exist may be modified - no new records may be added and no records may be deleted. Once the text has been modified, the programs must be rebuilt. For further information, see Chapter VIII in the "SCHIP Health Information System: User's Manual" and the on-line help for this program. | |
| 225 | Merge patient history This program is used to merge patient records for those patients who have been defined more than once in the database. Although it does permit patient records to be modified, its primary purpose is to locate duplicates and permit the user to choose a "master" patient record with which to merge the duplicates. See the on-line help for this program for more information. | |
| 226 | OBSQID data extraction This program generates flat files to export obstetric data to the WHO OBSQID system. | |
| 227 | RH data extraction This program generates flat files to export obstetric data to the UNFPA reproductive health system. | |
Table III - Functional Descriptions of Programs on the Database Operations Menu
| Reference | Description |
| 3 | Database Operations Menu This is a collection of programs that are used to manage the HIS programs, the HIS database and the server computer. |
| 31 | Analyze table indexes The analyze process inspects the distribution of the index keys. The database query optimizer makes better choices when the the table indexes have been analyzed. If during the analysis, the table index is discovered to becorrupt, an attempt is made to repair the index. |
| 32 | Archive to CD-ROM The backup files created by the "Database backup" program are copied to CD-ROM. If the backup files are archived successfully, files that are 30 days old or older are deleted. (This parameter can be configured.) |
| 33 | Cull superseded transactions When a transaction is changed, its most current version supersedes its previous version, which is then disabled. This program culls disabled versions that are older than 180 days. (This parameter can be configured.) |
| 34 | Database Backup This program backs up the current programs, the data in the database and the database transaction log. If the backup is successful, the transaction log is cleared and the event is recorded in the new transaction log. |
| 35 | Database Integrity Check The database tables are tested for structural errors but not checked for referential integrity among the tables. The program attempts to fix any corrupt index that is discovered. |
| 36 | Database Restore The programs, database files and transaction log file are restored from a backup that the user chooses from a list of available on-line backup files. The event is recorded in the restored transaction log. |
| 37 | Export Data This is used to transfer database records from one HIS server to another. A date range can be specified to reduce the size of the export set. The "Import Data" module is designed to read and apply exported database records. |
| 38 | Import Data The database is updated by applying one or more export files to it. This functionality is useful for aggregating databases from several different servers. The export files are generated using the "Export Data" module. |
| 39 | List Active Users The login and name of each active user is displayed. An active user is one who has submitted a web page in the recent past, that is, one whose session has not "timed out". |
| 310 | Server Shutdown This performs a safe shutdown of the database and an orderly shutdown of the operating system on the server computer. The shutdown event is written to the transaction log. |
| 311 | Set Multi-user Mode This places the HIS in a multi-user mode if it has been running in single-user mode. |
| 312 | Set Single User Mode This places the HIS in single-user mode so other users may not access the database. Although many of the programs on this menu place the HIS in single-user mode, each returns it to multi-user mode when it complete its task. By manually placing the the HIS in single-user mode, users are prevented from logging into the system between tasks. |
| 313 | Transaction Log Audit Report This program produces an audit journal. Parameters can be entered to limit the date range of the report and the types of entries reported. Critical errors are always reported, regardless of the types specified. |
| 314 | Transaction Log Integrity Check The transaction log is checked for any database update transactions that were interrupted. If the check fails, there may be one or more referential integrity errors in the database. Recovery from these errors may be performed by checking the transaction or by restoring the database from backup. |
Table IV - Functional Descriptions of Programs on the Reports Menu
| Reference | Description |
| 4 | Reports menu This menu currently shows the entry program for entering report definitions and a collection of report definitions to which a user has access. It may in the future display other custom report programs that have been written in PHP. Although access to the entry program and other PHP programs is determined by the user's role, access to a report definition is determined by data stored with the definition: user ownership, whether or not the definition is "locked", and whether or not the definition is "public". |
| 41 | Report entry This program permits users to enter their own report definitions. Chapter IX in the "SCHIP Health Information System: User's Manual" provides extensive information about the report writer tools. |
| 42 | Client immunization history This is an outpatient operational report that shows the complete immunization history of each patient or client. |
| 43 | Client Immunization Schedule This is an outpatient operational report that produces a personalized immunization schedule for each patient or client who is reported. It shows any immunizations that are past due and immunizations that are due in the future. |
| 44 | Encounter History Index This is an operational report that lists all events captured for either an inpatient or outpatient grouped by the type of event, that is, diagnoses, diagnostic tests, procedures, and others. The events are summarized and, where appropriate, each is accompanied by its case reference and encounter date. This report is used to cross-reference the detailed data which can be viewed using either the "Inpatient Care Entry" program or the"Outpatient Encounter Entry" program. |
| 45 | Facility Statistics This is an inpatient report that shows, at the facility level, basic admission and discharge statistics and other statistics based on the "most responsible diagnosis", that is, the principal final diagnosis if the patient has fully recovered upon discharge or the principal discharge diagnosis if not. |
| 46 | Facility Statistics by Catchment Area This is an inpatient report that shows, at the facility level, basic admission and discharge statistics and other statistics based on the "principal final diagnosis". If a patient catchment area is specified, each statistic reported relates to those patients who reside in the catchment area. If no patient catchment area is specified, the basic admission and discharge statistics are broken out by catchment area but the diagnosis statistics are summary statistics for the facility. |
| 47 | Immunization Journal This is an inpatient and outpatient operational report that lists all immunizations administered over a user-specified report period for a given facility. |
| 48 | Inpatient Journal This is an operational report that produces a journal of all admissions and discharges over a user-specified period of time. |
| 49 | Inpatient Register This is an operational report that producesa census of patients for a facility on a user-specified day. |
| 410 | Length of Stay by Diagnosis This is a statistical report that shows average length of stay and occupancy by principal final diagnosis for discharged inpatient cases. |
| 411 | Length of Stay Outliers by Diagnosis This is an operational report used to compare and monitor inpatient lengths of stay by principal final diagnosis for discharged cases. |
| 412 | Open Cases This is an operational report used to identify those inpatient cases that remain open, that is, undischarged. |
| 413 | Patient Readmissions This is an operational report used to identify those inpatients who were readmitted within a user-specified number of days. |
| 414 | Patients without Bed Assignments This is an operational report used to identify those inpatients that have not been assigned to a hospital ward. |
| 415 | Utilization Statistics by Catchment Area This is a report that can be used by inpatient or outpatient facilities to show, for a given facility, reasons for visits to the facility, disease diagnoses by ICD-10 category and various utilization measures for the facility. If a patient catchment area is specified, the visits, diagnoses and utilization measures are given for those patients who reside in the catchment area. If no patient catchment area is specified, the visit statistics are broken out by catchment area but the diagnoses and utilization measures are given for the facility as a whole. |
| 416 | Vaccine Requirements by Catchment Area This is a operational management report that gives a projection of future vaccine requirements for each catchment area based on patients in the database and the standard immunization schedule. |
| 417 | Ward Occupancy This is a statistical report that shows, at the ward level, the occupancy of admitted inpatients and the 10 principal final diagnoses most responsible for the occupancy of discharged inpatients. |
| © 2005 Canadian Society for International Health and the Contributors last update: 2005-06-28 |
||