Date First Published: December 2, 2014
Date Last Revised: March 8, 2023

This article is in the process of being updated.
Disambiguation: the term Clinical Information System (CIS) is used here to describe the system that facilitates clinical care functions. However, very often and in many countries the term EMR is used instead. In this article, it will be shown that the EMR is not equivalent to the CIS

FUNCTIONS OF CLINICAL INFORMATION SYSTEM (CIS)

The Clinical Information System (CIS) is the system that facilitates the clinical function. It does not stand on its own but is part of the Hospital Information System (HIS). The clinical function is performed by clinicians i.e. care providers involved directly with activities of patient care characterized by:

• face to face  interact interaction with patients
• the performance of procedures that affect patients physically, physiologically or psychologically

The term ‘clinicians’ refers not only to doctors, nurses and midwifes but also includes Dietitians, Therapists, Clinical psychologists, Clinical pharmacists, Clinical Microbiologists, Interventional Radiologists, Endoscopists, Optometrists, Audiologists, Social workers and many others.

CLINICAL CARE PROCESSES

Traditionally, clinicians consider their work activities as a series of steps that are both technical and cognitive. These ‘Clinical Care Processes’ form the series of  procedures performed by  care providers in providing clinical services to a patient. The term processes is used in clinical practice to include all types of activities whereas the term procedure is often incorrectly restricted to the act of performing something on the patient. The processes (or procedures) consist of:

1. Interview
2. Physical Examination
3. Investigation
4. Formulation of Diagnosis
5. Planning
6. Treatment (including therapy, rehabilitation, counseling)
7. Monitoring, Review and Evaluation
8. Case Disposal

The CIS software is designed to facilitate these processes.

Interview, examination, observation, providing treatment (invasive and non-invasive) and data documentation are examples of technical processes. The cognitive processes are thought processes where the clinician put together information, analyze and interpret them to arrive at conclusions such as formulating the diagnosis, planning and making decisions like choosing appropriate methods and modalities. The information available to the clinician includes his/her own knowledge, reference information from various sources and information about the patient obtained by various means.

Within patient care institutions, the content and structure of clinical care processes are fairly standard, despite the vast array of clinical specializations. While different specialties (Medicine, Surgery, Obstetrics, Psychiatry, etc.) serve different patient types, the basic tasks and information needs are similar. The entire set of clinical processes may be completed during a session or may be stretched across several sessions. Often, all or part of these steps is iterative (cyclical), being repeated as progress is reviewed. This may happen at each outpatient visit or as often as is required during an inpatient stay. The  Clinical Care Processes are depicted as a work-flow diagram  below:

The subject of Clinical Care Processes​​ is discussed in detail in another article.
An effective CIS promotes the integration of work flows, and standardization of procedures. The use of common terminology enables effective communications. Since clinicians follow a common approach to patient care, the functionalities of the CIS application is shared among all specialties. Peculiar requirements stemming from differences in tasks, data elements and the needs of different categories of care providers are met by addition of data elements or modification of the means of data entry, using different modes of displaying information and through the introduction of special features if necessary.

CLINICAL CARE PROCESSES AS DATA MANAGEMENT ACTIVITIES

The functions of the CIS, can be better understood if clinical care is envisaged as a series of data management activities. The main steps are:

1. Data collection (gathering, input, entry)
2. Data storage (capture, accumulate and make available)
3. Data extraction (retrieval, re-arrangement)
4. Data transmission (submission, transfer, retrieval)
5. Data presentation (GUI, display, views, reports)
6. Data analysis and interpretation (use)

With the use of computers and databases, these processes become more organized and standardized. Most importantly, the storage of data in a database allows for data sharing, data aggregation and data analysis. It also enables the computation of data to create derived data (e.g. calculated data) and to offer decision support. Computerization also enables data transfer of the system to and from machines via interfaces, and thus enabling automation. These data management steps are illustrated in the flow chart below:

The CIS make it possible to plan tasks and to gather data that is generated when the tasks are performed. It also enable descriptions of unplanned clinical events (incidents) to be recorded. These data are accumulated in the pool of data regarding the clinical characteristics of the patient (clinical patient data), and then combined with non-clinical data regarding the patient (e.g. test results) to form the Patient Information Database. The CIS application software is built around this database.

Structure and Content of CIS

The CIS is the most important part of a composite system (the patient care information system) that facilitates the whole patient care activity. The other essential components are the Patient Management (Administration ) System and the information systems for clinical support services. The former facilitate the administrative functions of patient care. The latter consists of separate sub-systems that facilitate the functions of the Laboratory (LIS), Radiology services (RIS), Pharmacy services (PhIS), the Blood bank and other services that support the clinical function. Pathologists, laboratory technologists, pharmacists, assistant pharmacists, radiologists, radiographers and other technicians perform ‘Clinical Support’ functions. They submit results to the Patient Information Database via the relevant Clinical support applications software and database. They are non-clinical care providers. The exception is when they provide care directly to patients (e.g. clinical microbiologist, clinical pharmacist, interventional radiologist), in which instance they carry out the clinical function and the processes they perform plus the results relating to the care of the patient are documented in the CIS. Pharmacists perform both clinical and clinical support services.
The Clinical Information System (CIS) are tightly linked to the Clinical Support applications  through the following mechanisms:

1. Provision of the means of communications between the clinician and clinical support group of care providers via the Order Entry system
2. Transfer of results from the clinical support applications to the database of patient data (the Result Reporting mechanism)
3. Provision of relevant summarized clinical information to clinical support personnel to assist them perform their work

Information gathered through clinical processes are stored in a database designed specially for the clinical function. This can be a separate database: Clinical Information Database or alternatively an operational database that not only retain data acquired by clinical care providers but all data concerning the patient from the other sub-systems of HIS: the Patient Information Database.
Data from these other systems are replicated in this database such that views and reports of CIS can contain laboratory results, radiology reports, images, dispensation of drugs and supply of blood products (among others).

The links between various components of the information systems for patient care is shown below:

Access to Clinical Data

For the purposes of privacy and confidentiality, access to the entire clinical data is restricted to only privileged care providers (i.e clinicians involved in the case). Clinical support providers are not given direct access to the CIS. Instead, knowledge about the patient are provided in the form of summaries. These summaries are made to contain relevant clinical data required by each category of clinical support providers. This obviates the need for them to access to the CIS. On the other hand, clinicians do not have to provide clinical information every time they make an order for services such as tests.

The EMR Is Not Equivalent to the CIS

Computerization of the clinical services is often thought to be achieved through a system of documentation to generate the EMR (despite opinions to the contrary). Therefore, the term EMR system is often used (incorrectly). Its objective is supposed to be enabling the care provider to write their findings, as and when they thought necessary, just as in the paper medical record. The main functionality within the EMR system is said to be “Clinical Documentation” which in turn is made up of various types of forms.

In many places for example the USA, the term EMR refers a system to assist clinical functions. In this discussion, the CIS is not equivalent to the EMR. It is not designed only as a system to generate the EMR. Instead, it deals with data that may not necessarily be considered as part of EMR (for example data used for communications, automation, quality control and administration).
The Electronic Medical Record (EMR), being a record of data generated as a result of clinical care processes (events, procedures or tasks) and incidents, is a product of the mix of data from the Clinical Information System (CIS) and the various clinical support systems.

Nevertheless, an important function of CIS is to help create the Medical record.

A more detailed discussion on the EMR is given in another article

FUNCTIONS AND COMPONENTS OF CIS

It is important to conceptualize, the CIS as a set of applications that facilitates every aspect of direct patient care or, in other words, clinical care. Forms used for data entry must be associated with events (procedures or incidents). Data to be recorded must be that generated by the procedure performed (not from memory or copy pasted from elsewhere). Data documentation is only part of the functions of CIS.

The CIS facilitates clinical operations (direct patient care) including the planning of care, implementation of care, quality control and the capture, storage plus distribution of clinical data. The CIS contains application modules or functionalities (however named) that enable the following functions:

1. Planning of care (use of Care Plans)
2. Execution of Clinical Care procedures and processes
3. Provision of Clinical Decision Support
4. Management of Patient Data
   • Clinical Data Documentation (Data entry and Data Storage)
   • Presentation of Patient Data (Data Retrieval and Display)
   • Construction of the EMR

The division into modules is only for purposes of description. In reality, all the functionalities are intricately intertwined throughout the CIS. Each function is discussed further below.

Function 1: PLANNING OF CARE

The CIS is designed such that the planning of care is one of its main drivers. The incorporation of planning in the CIS enables patient care operations to achieve the following objectives.

1. Encourage activities to be performed in a planned rather than ad hoc manner
2. Create uniformity and standardization of objectives, procedures and processes
3. Ensure appropriateness, comprehensiveness and efficiency of care

INCORPORATION OF CARE PLANS

The realization of care objectives is achieved through the incorporation of Care Plans as the means for planning, implementation and evaluation of care. Care plans, when embedded in the CIS, anticipate the needs of the clinician in delivering care for various patient types and provide direction to the clinician on tasks to be performed according to scenarios, occasions and events. For this purpose, the CIS has the following capabilities:

• Provide Reference Care Plans for various health problems at various points of care
• Enable the conversion of these plans into Actual Care Plans which are executed via orders/tasks

CONSTRUCTION OF CARE PLANS

The development of Care Plans is discussed in detail in another article

Care plans are what is termed as Standard Operating Procedures (SOP) in other industries. The mechanisms used to create care plans need to be based on a sound approach and valid evidence. Care plans should be the driver for the development of CIS. For this reason, a good CIS developer or vendor should provide the following:

1. Tools for building or customizing Reference Care Plans according to the needs of the health care facility
2. A ‘starter pack’ of ready-made care plans for common conditions

The health care facility should develop the Care plans themselves or study and verify the authenticity of the methods of creating the care plans. It is expected that these care plans would be endorsed by  an appointed body of clinicians (e.g. Clinical Governance Committee) and other care providers of that particular health care facility.

In the CIS, Care Plans take the form of sets of care packages made up of tasks arranged, sequenced, bundled together and scheduled according to work flows. Tools bundled with the CIS (provided by the vendor) would enable appointed teams of clinicians and others (care plan designers) to  customize Care Plans already provided or to build new ones, according to their needs. These tools provide the means to:

1. Arrange, sequence and schedule sets of tasks according to work flows or care pathways
2. Put together various orders to create care sets and order sets that will initiate the above tasks
3. Fashion and make available guides on how tasks are to be performed
4. Design documentation forms or charts for the capture of data generated by the planned tasks

It is also expected that the clinical governance body of the hospital continue to review existing care plans, develop new ones and endorse them. The care plans are then incorporated in the CIS as the main driver for it structure and content.

Content of Care Plans

Care plans are designed and constructed such that the contents and their arrangement caters for various groups of patients categorized mainly according to the diagnosis and its ramifications (stage, severity, effect and complications). The entire service is then considered as a service product. The CIS application software have the capability of linking an appropriate plan to a documented diagnosis. Because the accuracy and specificity of the diagnosis changes with time and with the data available, any change in the diagnosis warrants (triggers) a change in the content of the Care Plan.

In this context diagnosis refers to  any of the following:

1. a symptom (as in Nursing Diagnoses) or Symptom complex or Reason for visit
2. a syndrome (e.g. Intestinal obstruction, Obstructive jaundice or Bradyarrythmia, Acute coronary syndrome)
3. a diagnostic related group (DRG)
4. a specific disease and its variants

Hence, Care Plans are designed for the stage when the diagnosis is uncertain (symptom complex, syndrome, disease group) and also for the case types where the diagnosis is certain (specific illness and variants of it). Care plans are also made available for specific treatment programs e.g. specific procedure and treatment regimen. Modules are also created for various severity levels and patient profiles.

The Role of Diagnosis in patient care is discussed in detail in another article.

The entire overall Care Plan needs to be available for reference especially for the care provider who is overall-in-charge (the primary provider or case manager). The content need to be comprehensive  i.e. contains combinations of the following patient care tasks:

1. Administrative tasks (Admission, Referrals, Transfer & Discharge, visit registration, follow up appointment, referral, transfers and discontinuation of visits.)
2. Generation, gathering and collection of data about the patient’s illness and the effect on his/her health (clinical data). Data collection tasks e.g. Clerking or Assessment using a specific clerking form and Progress reviews guided by various forms or note types.
3. Analysis and interpretation of data to determine the diagnosis and needs of patients
4. Investigation tasks, Diagnostic tests
5. Treatment using various modalities including
   • nursing,
   • therapeutic procedures,
   • medication to be supplied or administered,
   • blood product supply & transfusion, 
   • Nutrition provision ,
   • Counseling,
   • Rehabilitation and
   • other therapeutic tasks
6. Monitoring plus Review of the progress of the illness, status of the patient’s health and effects of treatment (including assessment of outcome)
7. Review of diagnosis and management
8. Patient education
9. Continuation of care (frequency of review) or Final disposal of the case

For purposes of execution, the entire plan need to be decomposed into modules which are activated/made available in a just-in-time manner.

Breakdown of Care Plans into Task Lists

Because various tasks in patient care are performed by  different professionals, tasks within modules need to be assigned to the respective care provider or care  provider group by creating task lists.

Variations of the care plans are created  for each diagnosis  by taking into consideration the following possibilities and eventualities:

1. stage and severity of the illness
2. complication of illness
3. the patient profile (e.g. paediatric vs. adult, adolescent or geriatric, concomitant pre-existing chronic illness).

Care Plan Modules

The clinician is given guidance on each aspect of care according to the scenario, occasion or event. To achieve this, the care plan for a health problem is broken further into modules which are provided at the right time.

Modules are tasks grouped to match  the following criteria:

1. Division of care into periods (phases)
2. The way the care is to be given (diagnostic or therapeutic modalities)
3. Predicted (anticipated) events or outcome

The system also enables care providers to vary the composition of content in response to:

• unexpected events
• outcome and complications

The system presents these modules for execution at appropriate  points in the sequence of the workflow. This sequence is not necessarily linear but is dependent on alternative decisions and choices of modalities, besides other factors. 

Modules Based on Phases of Care

The whole duration of patient care (the care episode) has inherent stages or phases. To some extent, these phases coincide with different stages in the natural history of the disease. By taking into account the needs of every phase, the plan is divided into modules. The CIS enables the automatic or manual execution of a module at each change-over point of the phase.

The entire care episode are divided generally  into the following phases:

1. Inception of care administratively  (Admission, Referrals, Transfer)
2. Initial assessment and derivation of diagnosis
3. Resuscitation (if necessary)
4. Stabilization
5. Prevention
6. Definitive treatment
7. Evaluation and modification of treatment
8. Rehabilitation
9. Continuity of care
10. Termination / Cessation of care (Discharge)

The beginning and end of each phase are transitions defined by fulfillment of certain criteria. The most important factor is the emergence of a clearer diagnosis mandating a more definitive treatment plan. Often, the end of a phase occurs when certain objectives have been met. For the next phase, the care plan would discontinue certain tasks while continuing those that are necessary and introducing relevant new tasks. The duration of application of a plan before change-over to another for acute illness is different from that of chronic illness because of differences in triggers.

Modules Based on Other Considerations

The basic Care Plan is designed to follow a predicted evolution of care (the care pathway). However, occasions will arise where the plan requires modification, variation or diversion in response to other triggers such as:

• variance in the outcome of illness or treatment (the actual outcome varies from the expected outcome)
• occurrence of complications, side effects and incidents

Variance in outcome is detected through monitoring, progress review and evaluation. These are process control steps. Abnormal results, unexpected or undesirable outcome are used as triggers to modify care plans. Incidents usually require a certain response. For example, when a certain incident or complication happens, a care plan to address it is triggered. Preconceived plans are made available for common incidents. For others the plans are constructed  ad hoc (as and when needed) by the user.

Function 2: Execution of Patient Care Processes

Execution of patient care processes should happen largely according to plans rather than in an ad hoc manner. There will be circumstances when clinicians may have to deviate from standard plans and vary the care according to their considered judgement.

There is a lot of confusion regarding the execution of care plans when used in the context of paper records. Unfortunately, often this is carried forward into CIS design. An understanding of the three distinct activities that happen in relation to the care plan clarifies the issues:

1. Use of plans as reference (guide)
2. Customization of the reference plan into executable operations plan
3. Documentation of the outcome of the tasks performed
   • the name of the clinical care process performed
   • the result or outcome of that process

First, the care plan is given as a read only document to provide knowledge and guidance on the care of a certain symptom complex, syndrome or specific illness. The document is used for reference. Next, mechanisms are provided to create a customized plan and execute tasks as well as document the results.

In its execution, a Care plan should not be dissociated from the clinical care process e.g. by putting information regarding its functions in a separate table. The activities of planning, execution and outcome assessment occurs as a sequence of events and should be documented chronologically. Unfortunately, the documentation currently is often haphazard (as is the practice with nursing care plans)  despite a good understanding of the clinical care processes (Nursing Process).

Execution of Plans through Orders

The plan is a statement of intent and objectives. It is executed through orders using the Order Entry application.

The intricacies of the planning of care is discussed in another article

In the CIS, Care plan modules take the form of predetermined sets of orders (order set, care-set, care packages, care-bundle) which are basically planned tasks. The type of orders within an order set would include any or all that is necessary to carry out a particular patient care process. All or some of the items listed in a plan/order set can be made mandatory or modifiable. The care provider retains control of decisions and choices. He/she is given the choice of modifying the care set by activating-inactivating the orders that it contains or adding extra orders.
Plans, as it were, need to be executed. Therefore, it is the performance of tasks in response to these orders that makes the plan effective. The main mechanism for the execution of care plans is the Order Entry application.

Process Control Mechanisms

The status of placing orders, their execution and outcomes can be displayed separately as views and reports by deriving the information from the database. Instead of writing outcomes achieved in a separate table, they are documented as part of the progress review and evaluation. Execution of plans i.e. performance of procedures, is controlled and evaluated based on two criteria i.e.,

• Have the plan been followed?
• Have the objectives/desired outcome been met?

Quality control mechanisms such as detection of deviations or variance from the plan, unexpected results and tasks not completed should be built into the system. The usual method is to compare what was planned with what was executed. This can be accomplished by mechanisms built in the software or performed manually using check lists.

The use of Order Entry Application is discussed in detail in another article.

Depending on the certainty of the diagnosis and other factors, order sets can be quite open or otherwise didactic in content (to encourage uniformity) but modifiable (to allow for customization).

Status of Orders & Task Execution (Reminders and Alerts)

Decision support is also given when care providers perform various tasks or processes. This is embedded within the Order Entry application. Orders are converted into tasks and grouped as tasks lists. By assigning groups of tasks to the assigned person or team care providers aware of each other’s plans, needs and roles in the care of the patient. This mechanism ensures that the person responsible performs his or her duty. A completed task would have a result which can be in the form of:

• success (completion) or failure to perform the task
• the data generated by the task

Knowing these status help to ensure that plans are executed.

Triggers, Prompts and Reminders

When a patient is first seen, the choice of care plans is determined mainly by the purpose of the visit (visit type, reason for visit), which can be:

• a symptom complex, a clinical syndrome or a diagnostic related group
• a particular disease or health problem

The patient care workflow begins with visit registration (check in), followed by various clinical care processes and ends with termination of the visit (discharge, check out). There is a major difference between the workflow of new cases compared to follow-up patients. Generally, the care of new patients starts with data gathering to determine the diagnosis and the patient profile. The exception is when this and other processes have been done elsewhere. Follow-up patients usually would have part of their care  already done. Information regarding this is available in referral letters or through shared information systems.

The objectives with regards the care of patients, categorized by visit types are:

1. New Case: To obtain information so that care can be initiated for a new health care problem (symptom, symptom complex, syndrome, definite disease)
2. Referral case: to continue care provided earlier at another unit/institution
3. Elective Follow up or Readmission: to continue the remainder of care previously planned
4. Emergency Follow up or Readmission to seek care for:
   • a complication of illness or
   • complication of treatment or
   • unexpected event (recurrence, exacerbation)

The visit type indicates whether a new plan need to be activated or a previous plan continued.

Triggers for a New Case

For a new case, the ‘reason for visit’ (symptom complex, syndrome) provides the pointer for the selection of a care plan. This decision need to be made by a clinical care provider at the very beginning of care. The main activity within initial care plan is data collection tasks. Based on the data thus acquired, the next step i.e., clarifying diagnosis can be performed. If the data is insufficient efforts are made to gather more data. When the disease condition or health problem is identified, the corresponding care plan, consisting of various processes or tasks for the case, is chosen and initiated. 

Triggers for a Follow-up Case

If the care plan has been ascertained at the previous visit, the plan is continued at the follow up visit. For the category of cases the plan can be at the status of pending because of the uncertainty of the diagnosis, awaiting some conditions to be fulfilled (test results or observations), or awaiting the the consent of the patient to accept the plan. Hence, the definite plan has to be decided at the initial review at the beginning of the current visit or even later during the visit.
When a definite plan is being followed, the doctor or nurse can assess the outcome and decide if the patient can proceed to the next phase of care or a change of plan is necessary.

Execution of Care Plans through Order Sets

Planning involves determining what is to be done currently as well as in the future both in the short term as well as long term. Therefore, the care plan takes the form of a set of various types of planned tasks or orders (care sets / order sets) including:

1. Current orders (meant to be performed immediately)
2. Recurrent orders (meant to be repeated at certain intervals)
3. Future orders (meant to be activated at a proposed date or time)

Design and Execution of Care Plans

The current orders are to be executed in the immediate period. Recurrent orders allow for certain tasks to be performed at a regular interval (e.g. certain observations or tests). These tasks are listed and the care provider responsible is alerted when they are due. Future orders enable the placement of an order to be executed later. The execution can be triggered by an event (e.g. discharge, follow up, admission) or a defined date and time. 

Care Plan for Acute Illness

In acute illness, the phases of care include:

1. Triage & initial diagnosis,
2. Resuscitation,
3. Stabilization,
4. Further data gathering (monitoring, investigations)
5. Definitive diagnosis
6. Definitive treatment
7. Rehabilitation
8. Continuity of care

The care process is designed to enable rapid actions to be carried out from the initial stage, based mainly on symptom complex or syndromic diagnosis. Monitoring is instituted right at the outset, to obtain more data to aid in diagnosis plus to assess the development of the illness and the effect of treatment.
Trends of various parameters guide the user on whether to proceed to the next stage. Many processes are carried out simultaneously rather than sequentially and roles need to be clearly assigned to various members of the care team. Priorities also need to be defined. By predicting eventualities, likely interventions are anticipated and preparations are made.

Example of Care Plan Triggered by Change in Certainty of Diagnosis

Example: Care Plan for Patient Presenting with Symptom Complex of Acute Chest Pain and later Diagnosed as Non-STEMI

Example of Order Set for Initial Phase (Acute Chest Pain)

The care plan in this example is at the Initial Phase/Stage of Care for Acute Coronary Syndrome. The “Acute Chest Pain clerking form” is used to collect data through interview and physical examination. The Tests and monitoring tasks are mainly geared towards the confirmation/exclusion of Acute Coronary Syndrome. The treatment consists mainly of symptom relief and supportive therapy. For the next phases, different plans with appropriate content would be triggered and executed.

Triggers for Chronic Illness

In the context of the care of chronic illness, the phases include:

1. Phase of diagnosis or problem identification and elaboration
2. Phase of initiation and stabilization of therapy
3. Phase of maintenance of therapy aimed at optimal control
4. Phase of detection and amelioration of complications.

The composition of the Order set corresponds to the diagnosis. At the early stage, the order set contains mainly orders for diagnostic tests, resuscitation (if necessary), symptom relief and counseling. When a definitive diagnosis has been made the order set would consist of orders relating to definitive treatment (e.g. medication/procedures) and monitoring of progress (clinical, laboratory, imaging). Once the optimum objectives are reached, the care goes into the maintenance phase; where from then on the plan remains relatively unchanged. However, certain parameters are reviewed to detect the emergence of complications of the illness and treatment that would warrant intervention. Plans for such eventuality should be available.

Function 3: DECISION SUPPORT

An outline of the use of decision support is discussed here. Since it is built into almost all of the clinical care processes, it would be discussed further in detail in the sections discussing each process and in a separate article.

INCORPORATION OF CLINICAL DECISION SUPPORT IN CIS

Clinical care is a knowledge driven and information dependent activity. Modern clinical practice must be re-engineered to take advantage of the advancement in knowledge and practice of clinical sciences, management science, and information and communications technology. A Clinical decision support system that provides guidance and knowledge at the point of care is an integral part of the CIS. However, while the system can provide advice, prompts and triggers, it is the duty of the clinician to appraise them and make his/her own decisions.

Clinical decision support is envisaged not as a single system or application but as built-in functions within all the patient care application components (functionalities) especially the CIS.

Decision support can be for various functions is applied through several approaches i.e.:

1. Guide to the data to be gathered and choice of data collection methods
2. Guide to the determination of diagnosis
3. Providing direction through Care Plans (selection of plans from a set)
4. Display of data required prior to the performance of tasks (in a just-in-time manner)
5. Presentation of analyzed and interpreted results (views and reports)
6. Guide to proper use of methods or modalities (work instructions )
7. Response to unexpected developments or unmet objectives
8. Provision of reference information.
9. Ensuring continuity of care

Each of these is discussed further below.

1. Guide to the data to be gathered and captured (choice of forms)
2. Guide to making a diagnosis (diagnosis decision support)
3. Provision and matching of care plans for various categories of patients at different phases of care (discussed earlier)
4. Analysis and interpretation of results (normal, abnormal, scoring, stratification, grading, staging, comparison with standards for quality control)
5. Provision of guides, instructions, alerts, prompts, reminders and suggestions
   • Before or during the performance of certain procedures
   • In response to certain situations, occurrences, incidents, non-conformance and abnormalities
6. Provision of displays of essential patient data according to needs at various (events) instances of care in the form of summarized just-in time and up-to-date data; especially for clinical support providers
7. Selection, arrangement and presentation of the patient’s own data previously acquired or generated to help care providers make decisions
8. Use of the hospital’s own analyzed (aggregated) population data to guide decision making (e.g. selection of antibiotic based on incidence of bacterial resistance in the facility)
9. Provision of concise reference information, from either internal or external sources, on request or as a rule at certain identified steps in the care process (knowledge at point of care)

The clinical decision support application/functionality should be designed to match agreed policies, procedures and standards created and accepted by the hospital, based on evidence-based medicine and best practices. It should also concur with the case-type or scenario based on interpretation of individual patient data and information derived from aggregated data of current patients with similar issues and problems (e.g. antibiotic sensitivity pattern, current epidemic etc.).

Method 1: Guide to the Data to be Gathered and Choice of Data Collection Methods (Forms & Charts)

Mandating Data Collection and Providing Appropriate Tools

The type of information to be collected by the care provider varies depending on the type of case based on diagnosis and visit type (new case, referred case, follow up or readmission case). It is also dependent on the stage or phase of the care process. Data collection forms and charts are designed according to the case type and are triggered as soon as this is determined. Hence, the task of data collection is part of the care plan.
The instrument used for data entry is data collection forms. Data may be captured automatically e.g. electronic devices such as but measuring those for measuring blood pressure, counting pulse or estimating oxygen saturation. Yet, the values obtained will be will be passed tot the database by inserting them into forms.

Providing Appropriate Forms and Charts

There are two main instances when clinical data collection forms (clinical documentation) are used:

• initial data collection for a new case (clerking form)
• progress review (progress notes)

For a new case the Reason for Visit can be used as a trigger. For an ongoing case, Progress review forms are used to detect progress of the disease and response to treatment. Subsequently,  a  change in diagnosis (e.g. from provisional to definite) may occur and forms that mandate the collection of  more data will be provided to the care provider.

Other types of forms include:

• plans and intentions (instructions to admit, discharge planning, instruction to discharge
• incident report
• communications with care providers outside of the care team (referrals and replies)

The subject of data collection is discussed further in the discussion on the data management function.

Method 2: Guide on the Determination of Diagnosis

A diagnosis is made by analyzing and interpreting certain variables including signs, symptoms, clinical test results, investigation findings (laboratory, imaging, and endoscopy), monitoring parameters, clinical progress and response to treatment. Through research and experience the medical profession has identified sets of variables i.e. the criteria that predict a diagnosis. This knowledge can be presented to care providers to assist them in making a diagnosis. In certain instances, especially when a scoring system is used, these predictions have a high level of accuracy. For this purpose there must be a facility to assign values to each criterion, calculate the score and present it in a calculated data field. A comparison is made with the accepted scores to determine the likelihood of the diagnosis. However, a rough guide can be just as useful to the clinician. Read more at:

http://www.isabelhealthcare.com/Scienceline.html

Risk Stratification, Severity Grading & Staging

Having made the diagnosis the clinician needs to clarify further:

1. which variant or grade of the illness is affecting the patient
2. which stage of the natural history of the illness has been reached
3. what complications has accompanied the disease
4. how the patient has responded to the disease

This information allows the clinician to assign the patient into one or more categories according to disease variant, possible risks, severity of illness, stage of development and therefore prognosis. Categorization in turn allows the clinician to choose the right approach and initiate an appropriate care plan. Grading and scoring systems for various diseases have been developed and tested. Their use depends mainly on applicability (e.g. are tests available in a timely and cost effective manner). Care providers involved in the care of disease groups or specific diseases need to agree on which grading and scoring system they prefer.

Method 3: Providing Direction through Care Plans

The use of care plans is the main method of providing decision support in clinical patient care. The whole CIS is designed such that the clinician uses care plans right from the first encounter based on the reason for visit and the case type. He/she have the choice of adhering to the plan, to modify it or choose another care plan. There would be a change in direction if the diagnosis becomes more certain as more data is acquired. Also as the patient passes into a different phase of care, the care provider is given appropriate plans to choose from.

Guide to Selection of Care Plans

Care plans play an important role in clinical decision support. These roles relate to the provision of:

1. Direction
2. Choices
3. Reminders
4. Instructions and advice to the care provider
5. Knowledge at the point of care.

Providing Reminders, Prompts and Alerts

Mechanisms are made available to provide reminders for instances such as:

1. failure to complete a care plan or non-conformance to it
2. failure to act on an incident

Alerts may be given for instances like:

1. the result obtained is abnormal or the trend is disturbing
2. the desired outcome is not achieved
3. presence of allergies may contraindicate a certain treatment or caution is advised
4. an untoward event has occurred probably as a result of treatment  (allergy, peculiar symptom or sign, side effects)
5. an underlying disease may affect choice of treatment

Method 6: Guide to Proper use of Methods or Modalities

Providing Work Instructions

While it may be assumed that being professionals, every clinician is familiar with various care processes; nonetheless some would welcome guides being made available. Some processes are so critical or so infrequently performed that the strict steps to be followed need to be provided didactically. Two alternative mechanisms available are to display the instruction as a rule (the push method) or to provide the means of requesting for it (the pull method).
It is expected that the Decision Support System should provide instructions on the way to perform the following:

1. Perform a clinical procedure
   • preparation before performing a procedure
   • how to use of a method or modality (chemicals, instruments, machines)
   • Prescribing medication
   • Provide patient education
2. Carry out responsibilities beyond immediate care of the patient
   • Submit Incident reports when an event occurs
   • Submit data for registries and audits
   • Submit mandatory reports to authorities e.g. notification of infectious disease
3. Use of the CIS and other applications

Indications and Contraindications for the Use of a Method or Modality

Investigation and treatment modalities however efficacious has limitations such as unwanted effects like interactions, side effects, lack of effectiveness in certain situations etc. Care providers need to be reminded of these indications and contraindications as part of the decision making process.

Decision Support for Prescribing and Drug Administration

The Pharmacy-Medication Information System (PhIS) integrates the distinct functions of the Pharmacy service with the prescription and medication functions carried out by nurses and doctors within the CIS. An essential component of the Pharmacy Information System is a decision support system that provides information on correct dosage, side effects, drug reactions, drug interactions and contraindications (e.g. allergies). This will enable the pharmacist to track, vet and verify drugs being prescribed. Some of the information required may originate from the EMR (e.g. allergies and diagnosis) or from the Laboratory Information System (e.g. for biochemical or microbiology results). It is obvious that the Pharmacy Information System need to be interfaced with many other systems within the Hospital Information System.

The system should be able to alert clinicians at the time of prescribing and pharmacists when supplying the medication. The alerts should include checks and advice regarding:

1. allergies
2. drug interactions
3. chronic conditions e.g. chronic renal failure
4. LMP as indicated
5. Conflicting orders
6. Duplicate orders
7. Others

The decision support function is usually provided by a purpose built Drug information – Decision Support System (e.g. MIMS) which is integrated with the PhIS. Support can be in the form of alerts, advice or even disallowing transactions to proceed

Providing Advice

The Decision Support System provides advice, suggestion or direction to the care provider regarding:

1. Derivation of Conclusions (re: diagnosis, staging, prognosis)
2. Further actions to be taken in the clinical care process such as alternative care plans
3. Choice of modalities or methods to be used for:
   • Investigations
   • Monitoring
   • Treatment

Guide to Use of CIS and other Applications of HIS

Instructions on how to use various functionalities of the CIS is built in such that they are given at appropriate places when deemed necessary. If there is a necessity to interact with or use other applications information may be provided directly or via links.

Method 7: PROVIDING KNOWLEDGE AT THE POINT OF CARE

With the availability of computerized information technology, an opportunity exists to provide relevant and accurate information as and when required (at the point of care). This information can be made available on demand (pull approach) or be presented automatically: activated by certain conditions or rules (push approach). Whatever pertinent information that care providers would need is made available as documents in files kept in a file storage system within the CIS database. Since only pertinent information is provided and in a ‘just-in-time’ manner, it is not useful to provide it through a link to the world wide web.

Types of Reference Information in Clinical Decision Support Documents

References can be prepared by the health care facility itself. These internal sources of information include work procedure, work instructions and standards. Externally sourced references may must be first vetted and endorsed by the organization before being made available from within the CIS. They include evidence based guidelines and basic medical knowledge such as anatomy, physiology, pharmacokinetics, staging systems, body mass index, surface area, nutritional requirements etc. These are as listed below:

1. Diagnostic criteria based on analysis of any or all of the following facts:
   • symptoms and signs
   • diagnostic test
   • post-procedure finding
   • Risk Stratification / Severity Grading / Staging
2. Choice of various modalities for investigation, monitoring and treatment
3. Criteria used to make various decisions (classification, Indications/contraindications)
4. Appropriate investigations for a clinical problem
5. Various aspects of treatment (surgery, anaesthesia, invasive procedure, chemotherapy, radiotherapy)
6. Management of complications of a treatment regime (e.g. total parenteral nutrition, ventilatory support)
7. Pre-requisites for use of a modality, drug or procedure

Data Retrieval and Display

As an essential step in the way care is given, at the start of any session the care provider should try to know as much information about the patient as possible especially what had transpired. To facilitate this, the CIS has the ability to display such information. While in paper records the display is the same page that the data was initially written on, in a computerized system data is displayed on the computer screen. Displaying on a screen, make it possible to for data stored in the database to be extracted, rearranged and presented to the user as information as views or reports which can take the form of text, lists, tables or charts. This is unlike in traditional paper medical records where information needs to be sought on the page where it is initially written with the original arrangement and appearance unchanged. Creating an Operational database (clinical data repository) for the clinical function allows data regarding the patient from various sources to be in one location. This makes it easier to make queries and extract data for display.

Views

The care provider need to look at data from the current or recent transaction in a useful format. For example a nurse who has just taken vital signs data would like to see all the results immediately after she has performed the task and entered the data. Such information can be provided through views. Also, data accumulated in the database can be analyzed and interpreted before being displayed as a view.
Data may be transformed by the computer program to create lists, calculated values and other computations obviating to need for care providers to do so themselves. For example, the Glasgow Coma Scale is automatically calculated based on primary data. Values such as PEFR measured by the care provider in L/min can be converted to percentage of expected value for a patient of the same age or size. Indeed, it is possible for more complex computations to be made.

Views are fashioned to provide relevant information regarding a certain aspect. A view can consist of data entered into the database tables by different care providers using different forms. The view can be derived from a subset of one table or a combination of data from two or more tables.

Views are configured when the CIS is designed. When first created they are only a structure without the data but reside in the database as named queries (codes written in data query language). Data to be incorporated in views are accumulated into temporary tables. The data is not retained permanently but erased once the view is no longer useful. As such, the tables are said to be virtual tables. They are displayed spontaneously according to the flow of the processes or can be requested by the care provider by activating GUI items. Their purpose is to allow a user to see the relevant subset of the recorded data. Views are used to help the care provider perform tasks by providing:

• confirmation that correct data has been entered
• create lists (e.g., list of orders made)
• status of transactions

While forms are designed for ease of data entry, views make it easy to read the data already captured. If a series of items are selected or tasks performed, a view can show them as list. Interactions with the computer can be considered as transactions. It is useful to know that the interaction has been successfully completed.

Method of Creating a View

In a relational database, a view is created by querying one or more database tables using *CREATE VIEW command of the standard query language (SQL)

CREATE VIEW – Name of view
SELECT – the required data fields (columns in database table)
FROM – name of database table
WHERE

A view that combines data from two or more tables can be created by naming more than one table in the FROM clause.

Since a view is also a database table (albeit virtual), data can be extracted from it to create other views. For example, values can be sequenced in an orderly way to create lists.

SELECT Author, Title
FROM name of view
ORDER BY Author

Limitation in Use of Views

Since views are queries that are run as and when required, it should be used only for simple queries like to look for particular sets data in a database for a limited purpose. Otherwise it can overwhelm the systems memory (RAM). For more complex queries and presentations it is better to use reports.

Reports

The database enables relevant sets of useful information to be extracted and made available as reports in the format that will help users carry out both clinical and business activities.

A report is a way of presenting data from a database, in a more useful manner than just showing back the forms or database tables. Data can be presented as lists, tables, charts, graphs and other formats making it easier for decision-making and analysis. Reports are of use to primary users (care providers). Data can be aggregated for secondary use by managers and researches) such as for purposes of clinical audits, creation of registries, utilization reviews, epidemiology and health care planning. Additional third party software (e.g. statistical applications) can be used for this purpose.

Reports tend to be complex queries which will take time to be realized. As such it is provided in near real-time i.e. within minutes rather than seconds. However, for reports for clinical use this delay is not detrimental as the reports are usually created and used after a the end of a session. For example, the vital signs chart or the spreadsheet view of laboratory results is used mainly at the occasion of Progress review.

Complicated reports e.g. graphs and charts for managerial purposes can be run when the system is not busy (has less transactions) e.g. at the end of the day or at midnight. For more complex reports e.g. for purposes of research, it may be necessary to replicate the database and create a report database server or an analytical database.

Displaying Sequence of Events

Clinical care follows a sequence according to the workflow of clinical care processes. The data displayed need to anticipate information needs for carrying out procedures and demonstrate the sequence of events that has happened. Reports are used for this purpose.
Much of clinical data including symptoms, signs, diagnosis, test results, images, plans, decisions and actions taken vary with time. Such time dependent data are called time series data. There is a special way to manage such data. However, even in the commonly used Relational Database Management System (RDMS), data is collected in relation to events. The time (timestamp) is a mandatory attribute (column value) in a database table capturing results (findings) of a clinical process. Therefore data in a SQL database may be transformed into time series data through some customization and configuration. This is sufficient for cases where events occur at not very frequent intervals and dataset is not large, such as those managed in the outpatient setting or inpatient wards. For example, in the outpatient setting vital signs may be monitored once or at the most twice per session. In the day care and inpatient setting the monitoring are more frequent but do not usually exceed more than hourly.
It is in the intensive care setting that monitoring is more frequent and intense and involve more parameters. In this setting, it is better for the data to be captured in a time series database that is purpose built or a SQL database that has a time series data management capability (e.g. PostgreSQL, Oracle).

The management of cases in the Intensive Care Unit is discussed in another article (to be written)

Optimizing the the Use of the Computer Screen

The computer screen enables care providers as users of the system to interact with the CIS (applications, database and machines). Its use can be optimized to:

1. allow the user to traverse or navigate from one function to the next
2. to group information in a meaningful manner
   • anticipate the information necessary and display them in a just in time manner
   • provide means to use tools in intuitive manner by anticipating what the care provider intends to do at that phase or point of care

The CIS depends on the optimal use of the Graphical user interface to make it easy for care providers to access data

Design of the Graphical User Interface

The arrangement of items displayed on the computer screen need to vary according to instances determined by purposes, functions, patient types and user categories. Hence, user-interfaces for clinicians, support service providers and administrators and quite different in content. Even if this is so, what is displayed consists of two groups of items i.e.

• Data entry tools
• Results of queries of the database presented as views

• navigation from one functionality of the CIS (i.e. one clinical care process) to another or to another application
• display of existing (available) data
• data entry tools
• placing orders
• automation of tasks (printing, scanning)

Forms and views can be made accessible from the same screen. Otherwise a  toggle is provided to differentiate the two functionalities. The screen design should make it clear to care providers whether they are entering new data or reviewing previous results. Differences in the format (location on the screen or colour scheme) of the form as opposed to the results can prevent confusion.

A care provider has to manage a group of patients. He/she need to have information concerning the persons under his/her care at a glance. Subsequently, he/she will give full attention to a single case. For this reason two distinct user-system interface (views, screens) are made available i.e.

• All patients display
• Single patient display

Moving from One Care Process to the Next

The graphical user interface is designed to provide of means for the care provider to move from one care process to the next (through use of menus and navigators). This is possible if the CIS is driven by care plans. Moving from one process to the next depends on whether objectives (outcomes) have been met. Once an outcome is known and found to be satisfactory, the screen can be fashioned to change from the current state to to one that will facilitate the next step. By embedding Care plans, within the CIS, the needs of the clinician in delivering care for various patient types is anticipated. The GUI is fashioned to provide direction to the clinician on tasks to be performed using scenarios, occasions and events as triggers.
Data display (views, reports) should anticipate the data needs of the care provider and present sufficient and relevant data required to perform the particular task at the opportune moment.

DESIGN OF THE PATIENT INFORMATION DATABASE

A comprehensive and clear description of the structure, data models, data dictionary and meta-data of the database must be documented. This will be necessary for purposes of:

1. Understanding the database
2. Additions and improvements to the design
3. Facilitating data extraction
4. Subsequent data-migration to a new CIS system, when necessary

Database Management System (DBMS) for Patient Data

The data storage software should be:

1. such that all data belonging to a patient (considered as an entity) is put together and made available both at the time it is used (i.e. during a visit) and also as a historical record
2. in the form of structured data that can be retrieved, manipulated, computed and aggregated rather than just as a document

The Database Management System (DBMS) used to store patient data should ensure that the data possess the following characteristics:

1. normalized i.e. each data element is represented by one data field without duplication unless absolutely necessary
2. consistently depicts the chronology of events
3. the context surrounding the data collection (the event, location, person involved) is captured
4. accuracy and standardization in use of terminology
5. integrity (data is not lost or corrupted)
6. completeness
7. security, confidentiality and privacy
8. easy accessibility
9. constant availability
10. comprehensibility (easily understood)
11. interoperability with other systems (both semantic and technical)

The database should be based on a commonly available and well accepted DBMS e.g. Relational Database or Object Oriented Database or Hierarchical database using universally accepted standard Data Definition Language and Data Manipulation Language. The terminology, classifications and naming conventions should be standardized using reference tables. Consideration must also be given to semantic interoperability within the system and preferably with other systems through the use of standard nomenclature..
Since the EMR derives data from the CIS, it is a query the Patient Information Database using data extraction tools provided within the existing CIS or as separate applications software. A good alternative would be to create, a secondary slightly off-sync (near real time) analytical database for purposes of data extraction to create the EMR and other reports. There should be a facility to continuously update the EMR as an interim document at any time during the visit and before being fully constituted and arranged in chronological order during the visit finalized at the end of the visit. Once finalized, the EMR should be validated after which it should be a historical record which should not be altered, modified or manipulated in anyway.
The issue of derivation of EMR data from CIS is discussed in a later section.

Database Hardware for Patient Data

The main database with its server and storage system would be the primary source of data for operations (i.e. used for the patient care function). It contains data from the PMS, CIS and Clinical Support Systems. It is continuously updated whenever new data is added as the care process proceeds.
The database of patient data being an operations database must possess or contribute to the following characteristics or functions:

1. High availability
2. Confidentiality and privacy
3. Concurrency control (facilitate use by many users at the same time)
4. Business continuity (Up-time, Redundancy and Mirroring, Data back-up and Disaster recovery)
5. Data integrity (built in mechanisms to ensure data submitted is captured and subsequently not lost or corrupted)
6. Sufficient capacity to accommodate data produced at least for 5 years of use (up-gradable storage capacity)
7. Technical interoperability with the network, with application servers and analytical servers.
8. Record read and write events as a journal
9. Ability to roll back and restore

Depending on needs, data extraction should be in real-time i.e. from the operations database or a near real-time i.e. from an “off sync” analytical database which is a replicate of the database of patient data.
The EMR of each patient consisting of data derived from the main database would be stored in a separate data repository as documents with a defined content and structure. For most users it is mainly a read only document (in a word processor, PDF or any other easily readable format). As the EMR contains only pertinent data it also represents the mandatory clinical data that need to be retained and migrated if a new system is developed or acquired.

The Data Acquisition, Storage and Retrieval Cycle

The conceptual integration of the applications software and the hardware is depicted in the figure below.

INDEPENDENCE OF THE DATABASE VIS-A-VIS APPLICATIONS SOFTWARE

Since all patient data is stored in a database, an essential requirement is the ability to retrieve patient data from the database independently without relying on the specific CIS applications software. In other words, it should be possible to access and obtain meaningful data from the database by using standard data extraction software. The data dictionary of the database should be in standard data definition language and allow for independent queries for various purposes using standard data extraction language.

Function 5: CONSTRUCTION OF EMR

The EMR is a permanent record, extracted from the database, consisting of pertinent data regarding an individual patient arranged in a chronological order. The EMR is derived from the data that has been collected and stored in the Patient Information Database. It should be verified by care providers, after which it should not be altered, modified or manipulated in anyway. The issue of construction of EMR is discussed in a later section and in another article.
Since the EMR derives data from the CIS, it is a query the Patient Information Database using data extraction tools provided within the existing CIS or as separate applications software. A good alternative would be to create, a secondary slightly off-sync analytical database for purposes data extraction to create the EMR and other reports. There should be a facility to continuously update the EMR as an interim document at any time during the visit before being fully constituted and arranged in chronological order at the end of the visit. Once finalized, the whole record should be validated and compiled as the EMR.
There are major differences as regards data presentation and use in CIS as compared to EMR i.e.:

1. the CIS provides the means to manage data and use it for performance of clinical processes
2. the EMR is a permanent record of pertinent historical data arranged in chronological order (mainly for medico-legal purposes)

Because, the CIS is a system that facilitates work, the patient data need to be presented in real-time such that each view is adequate and relevant to the issue or task at hand. The data management tools are embedded and interspersed within the CIS.
To obtain the right information, the clinician is guided by graphical user interfaces or GUIs (icons, tabs, navigators) that is orderly and intuitive. The EMR if automatically generated and updated is still useful for clinicians as summarised data of events and results that happened in the recent or distant past.
Data is presented in groups or sections according to the needs or functions of various users. For convenience, it is useful to segregate the data into sections related to :

1. a particular care process,
2. use (e.g. monitoring, medication, surgical procedures)
3. source (laboratory, diagnostic imaging)

Secondary users i.e. managers, members of the legal profession, medical record officers, statisticians, epidemiologists, auditors, researchers and others would prefer to use the data compiled after a completed visit i.e. the Electronic Medical Record (EMR). The function, structure and content of the EMR are discussed in a separate section.

Management of Clinical Data in CIS and EMR

EMR as Chronology of Events

The means of entering and viewing data within the CIS during an active visit will be discussed later.

THE CIS IN ACTION

How the CIS facilitates the clinician in carrying out tasks is describe further below.

Data Flow between Components of Patient Care Information System and the EMR

• All patients display
• Single patient display

A toggle mechanism is the usual method used to change from one display to the other.

 Patient List and View of Urgent Tasks of All Patients

The all patients and all tasks view is display that facilitates the managerial function of the clinician. It is crested from data acquired by the Registration application. Since clinicians do not have access to the Registration application, the view is sent over to the CIS.
It contains a summary made up of pertinent information on cases assigned to the care provider in terms of:

• their identity, 
• their current location, and
• the case type.

The list ensures that all patients assigned to the clinician is attended to. It also gives an idea of his/her workload, therefore aids in time and resource management management. Detailed information regarding them is inappropriate in this view.
Other information includes messages from other care providers, referrals, reminders and tasks requiring urgent attention. As such, this view supports the function of the care provider as a manager of all cases under his/her care.

A mock up of a screen with patient list displayed is shown below:

Single Patient View

This view supports the role of care provider as a clinician. When carrying out clinical patient care, the clinician should open the record of only one patient at a time. It is best to ascertain the patient’s identity by:

1. comparing the patient with the photograph on the patient list,
2. comparing the ID with that on the appointment card or on the wrist-band and
3. confirm the particulars with the patient.

This avoids the mistake of working on the wrong patient. It ensures the care provider:

• look at the right patient’s data,
• enters data into the right record,
• place orders on the right case, and
• performs tasks on the right patient.

The display of the record of single patient is accessed via a link from the selected item on the patient list. Restricting the display to one patient enables the care provider to concentrate on the case without encumbrances of other issues. He/she should complete whatever is being done for that patient and sign off before proceeding to the next patient. Signing off will return the view back to the patient list.

Display of Menu, Navigators and Data

The display screen (GUI) serves two functions:

• Review of existing information
• Performance of tasks and entry of the resultant data

Distinction must be made between the two functions. One way is for the navigators for both functions to be shown together on one screen but grouped in a distinct manner. The other way is to display the two functions separately using a toggle mechanism to change from one display to the other. It is important for the menu and navigators to be intuitive i.e., follow the work processes. Screen and font size are limitations to be considered.

Review of Existing Information

It is good practice to review existing information before and during an encounter with the patient. Therefore, before new data is collected, a view of pertinent historical data (e.g. allergies data, current diagnosis, and relevant recently acquired data) needs to be presented. Other CIS data elements (orders, decision support information, incident reports, care plans, instructions etc.) need to be also presented in easily discernible sections.
Through the use of various graphic user interfaces (GUI, icons, menus, index, navigators, hyperlinks, and tabs), any of the applications or a particular functionality may be expanded by the user as and when it is needed (the windows approach). The structure and content of displays are purposely designed to support clinicians in performing their work.

Example of a display for a single patient immediately after reception/triage.

Example of the Display of Results and Access to  Applications after Initial Assessment, Monitoring  and Investigation

Clinicians would use the CIS application to perform most of their work including data collection, making a diagnosis, choosing care plans, placing orders and documenting results. There are occasions when order entry is the main task, hence a view just for order entry and viewing of task status would be very useful. Other items on the menu includes links to the scheduling application, referral letter format and messaging application.

Because of its complexity, a separate screen with menus and sub-menus is required.

CLINICAL DATA GATHERING TASKS

Clinical tasks generate data, irrespective of whether they are performed ad hoc or as part of the care plan. The data is captured and transmitted to the database where they are stored. When required data is collected and captured using pre-designed forms or charts. For most instances the data gathering process is associated  with a clinical work process. The following Clinical care processes generate data.

1. Initial Clinical data gathering (interviewing, eliciting symptoms and signs)
2. Formulating diagnosis
3. Planning care
4. Further data gathering (clinical tests, ordering investigations)
5. Monitoring
6. Treatment
7. Reporting of Incidents
8. Progress review
9. Assessment of Outcome
10. Case disposal

Recording the Context of Each Instance of Data Entry

To conform with medico-legal, quality control and other professional requirements, each instance of data entry should indicate the relation of the data to:

1. the date and time of data entry
2. the name of the task or event
3. the location where the task or event took place
4. the person performing the task or observed the event

These data should be, as far as possible, automatically populated based on names of the form used, username on log-on and current location as in the Patient Management System. As a rule, documentation is associated with a task. The data elements describe the task and the results generated by it. These vary with the type of task. The basic data for a typical task is shown in the table below.

The record of events and results generated by it should be written or captured in chronological order. It is necessary for the input devices and the database to have a synchronized system clock and each data entry and capture given a time stamp. There should be concurrency control so that the correct sequence is maintained.
Despite the above requirements, there are instances where data entry is delayed. It should be possible for the system to record the time of data entry as well as the time the event that generated the data actually happens.

For purposes of display some of the data must be shown but some may be hidden and recalled only when needed (e.g. by glossing the cursor over it)

Standardization of Nomenclature and Terminologies

For purposes of ease of comprehension by all involved and semantic interoperability across systems, there should be conformance to the use of nomenclature, classification and terminology for data elements in the CIS. An agreement need to be made by all clinicians on the use of available standard nomenclature systems such as SNOMED, LOIN, ICD10, Standard Drug lists etc. Data is entered by searching and selecting from standards lists/ reference tables e.g. for reason for visit, diagnosis, tests, drugs and procedures.
Standards lists of items peculiar to the hospital should also be prepared for names of care providers, clinical units, service locations, orders/tasks, formulary drugs, machines, instruments, consumables, allergies, outcomes, reason for discharge etc. These standard lists should be based on consensus.
Wherever possible answers and results for each data element should be predetermined and the possible choices are given in the form of check boxes, radio buttons, dropped-down lists. Hence the data is structured especially if standard nomenclature is used (e.g. Snomed CT). Allowance for free text, when necessary especially where the context calls for a description in the care provider’s own words. Exceptions and duplication of fields and values contained in forms should be made only in exceptional circumstances (e.g. use of different terminology/grading/scoring systems for the same result in different disciplines or disease conditions).
Therefore assessment forms, progress notes and procedure records can be customized for different specialties but these should adhere to the use of a common structure and standard nomenclature.

Data Acquisition Methods

The data collection process is part of care plans is mandated for every task performed. Ad hoc charting should be the exception rather than the rule. Data entry tools should be designed to be intuitive i.e. anticipate the collection of only relevant data that is generated when a task is performed. The data type can be a mixture of unstructured (text) and structured data. Structured data collection tools should have templates with headings sub-headings and data fields. When used ad hoc, data collection tools  are accessible through menus and sub-menus. 
There are several ways that data entry can be made i.e.:

1. Use of Data entry forms with predetermined structure and content (structured data)
2. Use of Data entry forms that allow users to document data in their own words (free text)
3. Direct charting into Charts
4. Direct Acquisition From Machines and Devices through machine-system interfaces
5. Read from bar-code labels using bar code readers (for identification data and instructions)
6. Direct capture of images from image producing machines interfaced to the network (X-rays, ultrasounds, ECG tracings, Cardiotocographs etc.)
7. Acquisition of scanned of images of hard copy documents (e.g. referral letters, printed results etc.)
8. Data converted from sound using voice recognition systems
9. Copy and pasting of existing data on display to a data entry form.

These results could be presented as:

1. numeric values (cardinal, ordinal)
2. structured words (alpha, alphanumeric)
3. free text (string)
4. images

When structured data is required the terminology and nomenclature of the data elements (fields) and data values should be derived from a universally accepted standard vocabulary e.g. SNOMED CT, MEDCIN™ etc. If non-standard nomenclature is used it should be capable of being mapped to standard nomenclature using alias tables supplied by the CIS vendor.

Standardization of Data Collection Tools

As mentioned earlier, within the hospital, clinical care processes are fairly standard; despite the vast array of specializations. Certain forms and views can be and should be shared across specialties to ensure uniformity and standardization. This approach will ensure completeness, ease of understanding and usability of the CIS.
Most clinical data collection tools will have the same structure and content with some parts being variable. These include:

1. Initial Data Gathering Forms (Clerking, Assessment, Eliciting symptoms and signs)
2. Progress notes
3. Care Plans
4. Procedure Record
5. Outcome documentation (severity grading, scoring etc.)
6. Summaries

For some purposes, standard forms should be used across all specialties and departments e.g.:

1. Certain mandatory or common assessments, e.g. Activities of Daily Living (ADL), ASA Score, GCS Score etc.
2. Drug History
3. Social history
4. Diagnosis
5. Allergies

Fundamental Structure of a Data Collection Form

Even if special forms are created to serve the specific needs of specialty disciplines, they need to conform to a common structure, appearance and share the same content (data fields and data values) when dealing with common areas. This approach will obviate the need for procuring or developing stand-alone clinical information systems for various specialties. The temptation to do so (e.g. for dental, cardiology and intensive care services) should be resisted. The special requirements does not usually relate to clinical processes and data but to additions of special functions such as continuous monitoring, capture and retrieval of images, drawing tools etc.

Drawing Tools

Traditionally, drawing has been used by clinicians to document plans and findings. Clinical documentation applications software should have functionalities that allow users to create, store and retrieve drawings. It is essential for the drawings to be converted into images in any standard format (JPEG, GIF, Metafile etc.). Images should be considered as a data element within the Patient Information Database. If images are to be stored in a separate server-storage system, there should be in-built mechanisms for ensuring that images are matched with the patients that they belong to. Several methods for capturing and storing drawings can be used viz:

1. Images or pictures supplied as part of forms, notations on (using the mouse)
2. Clinicians may draw free-hand on drawing tablets and images are captured directly from the device.
3. Clinicians draw by hand on paper and the drawing is scanned as images

Mechanisms for Capture of Digital Images as Part of Clinical Patient Data

Images captured as part of clinical processes be it for diagnosis or monitoring should be considered as clinical data. Where possible the CIS should capture directly these images from image producing machines. Examples are ECG tracings, Cardiotocographs, Digital photographs (e.g. in Dermatology, Plastic surgery), Retinal photographs, Results in graphic form and images drawn by clinicians can be scanned and captured, scanned images and etc.

The Patient Information database should cater for the storage and retrieval of images as part of patient data. Radiological images are an exception since they are already captured via RIS-PACS system.

Clinical Data Gathering through Interview and Examination

The Initial Clinical Data Gathering is termed as Clerking by doctors and assessment by nurses and other care providers. It refers to eliciting symptoms and signs of the patient through interview physical examination and simple clinical tests. in practice, doctors and other clinical care providers perform clerking or assessment on two types of patients:

1. Fresh case (at their first encounter at primary care setting or walk in patients)
2. Cases with previous encounters for the same problem within the same or different facility (follow up case, referred case)

The main difference is: for the first group there is no existing clinical data whereas for the second group data from the previous visits or encounters are available in some form.

The Interview (History Taking) of a Fresh Case

The interview allows the patient to describe the illness according to his/her own words. The description may not be orderly and may not indicate the relative importance of the symptoms. A good approach would be to write an outline of findings of the interview on paper, a drawing-pad or a temporary text box (sticky post). In the end, it is the care providers interpretation of what the patient is trying to say that will determine how care is to proceed.

Symptoms or complaints are complex in nature. Some characteristics can be applied for all symptoms but some characteristics are peculiar to that particular symptom.  In the data collection form, the pertinent details should be customized for each symptom. The medical profession has identified what features best describe a particular symptom. If structured data is to be captured, forms with the relevant data elements need to be built for each symptom. This may seem tedious but is within the capability of a computerized information technology.

For example, for pain details include location, onset, duration, intensity and periodicity. For a swelling it will include location, progression of size, presence of pain, loss of function and presence of systemic symptoms. The search mechanism is used when the selection is wide. For values peculiar to a symptom, selection can be made from a standard list through a drop down list, radio button or check box.

Minor symptoms may be volunteered by the patient or elicited by direct questioning through a review of systems. Those that are interpreted as part of the illness may be categorized as related / associated symptoms, while those not related are termed as other symptoms. The system should then put forward a selection of symptoms and the pertinent aspects of each symptom enabling a more detailed description. This approach ensures that clinical data is structured.

Data Collection Form for Symptoms / Health Complaints of Current Illness

Use of Chief complaints or Main Symptom(s) as the Trigger for Care Plans

The data gathered from the interview is used for purposes of:

1. Formulating an early diagnosis
2. Building a health profile of the patient

Often, the early diagnosis has a low level of accuracy and is expressed as a Symptom complex.

However, in some instances data acquired is sufficient to make a definitive diagnosis.

Through analysis and interpretation, the care provider would select the chief complaints or main symptoms. As each complaint is recorded in detail, they are displayed according to the level of priority or importance.  The list when considered together make up symptom-complexes, which can be used as a trigger for care plans

Display of List of Complaints/Symptoms

Eliciting Signs

Signs can only be elicited at a face to face encounter but some signs can be  obtained through remote cameras or devices attached to the patient connected to the network, as in telemedicine encounters.

As with symptoms, each sign has its own characteristics or features. Signs relate to an anatomical area or organ. It manifestation can affect the whole body or various physiological systems. manifestation. Some characteristics can be applied for all signs but some characteristics are peculiar to that particular sign or the particular area or organ involved.  In the data collection form, the pertinent details should be customized for each sign. The features that best describe a particular sign are known. In order to capture structured data forms with the relevant data elements need to be built for each sign at each area or organ. This is within the capability of a computerized information technology.

Eliciting Signs in a Fresh case

In a fresh case i.e. at the first encounter, the physical examination need to be performed in a systematic manner without any assumptions. It is aimed at discovering general findings and individual signs related to body regions and physiological systems. Signs do not present themselves but have to be sought through examination. However, closer attention needs to be paid to possibilities suggested by the previously obtained symptoms and history. Attention is paid to a defined anatomical site or organ. When a sign is discovered the documentation, its characteristics or features need to be described in sufficient detail. These characteristics are different for different signs and sites. Hence data collection forms need to address this complexity. It is also important to state if a sign is absent in a location that is examined. Also if an area is not examined this fact is also indicated.

Documentation of a Sign and its Characteristics

Eliciting Signs in a Progress Review

In a progress review or at follow up care, the main consideration is to determine if there is improvement or deterioration of the signs. This can be a value judgement (clinical opinion) or be based on derived data example calculating differences in:

• actual measurements (temperature, pressure, rates, sizes)
• grades of severity (such as degree of tenderness, extent, number of lesions)
• other characteristics demonstrating the natural history of illness (pathological and clinical evolution of the disease)

The data documentation form need to be designed to take into consideration the need to indicate these variations in findings.

RETRIEVAL AND DISPLAY OF CLINICAL DATA

A view is basically a query of the database. Views should have the capability of displaying data derived from the Patient Information Database (Patient Data Repository) which in turn consist of data collected at different occasions.
Clinical data originate from two main sources:

1. Data collected by clinicians in the course of performing tasks and from observations made
2. Data (Results of Investigations, Supplies) supplied by Clinical Support Systems (Laboratory, Imaging, Blood Bank and Pharmacy systems)

Only data that is already available can be displayed. The display should address two questions:

1. What processes has been done for this patient?
2. What results are available?

Case Summary

To present all available data in whatever way, would take a lot of space and would certainly occupy more than one page. Hence the use of a Case Summary is invaluable. It should be designed such that the patient care processes already performed is listed as headings and the results as structured text. Only pertinent data is included and often interpretations, conclusions and impressions rather than primary data are provided.

For most purposes data need to be viewed in chronological order. However, to make available the data for the entire  visit or episode would cause a strain on the data query function. Instead data for a defined period can be presented according to needs. Views should be intuitive, taking into account the patient and service category i.e. patient:

1. with outpatient visits only (day care being treated as outpatient)
2. with in-patient visit only
3. on follow up with both outpatient and in-patient visits within the same episode

Summaries can be accessed whenever required via GUIs on the user-system interface.

Displays (Reports and Views) for Various Purposes

For each display (view, report), recurring data that is collected repeated over time intervals need to be sequenced in chronological order.

1. Sectional display
2. Visit-Encounter display
3. Structured text
4. Charts and tables
5. The White board
6. Clinical support information to facilitate tasks of a care provider
7. Problem oriented mix of data
8. Visit Summary
9. Case summary

Displaying Reports of Events

For purposes of facilitating clinical operations, presenting data in strictly chronological order in the form of a log or diary (as in an EMR) may not be helpful. Instead, the data is grouped and rearranged in sections such as: assessment data, progress notes, laboratory results, radiological findings, procedures done and etc. However, for each section the chronological order is still maintained.
The means of entering and viewing data within the CIS during an active visit will be discussed later.

Reports of Clinical (EMR) Data

Structured Text

It is important for purposes of data manipulation for data to be captured and stored in a structured manner where the data fields and the possible values are defined.
Presentation of data in the same form as how they are collected is not well received by clinicians. For most people information provided as a narrative is more easily understood. Because it is in a format that is familiar, it takes less time to absorb and understand. Therefore it would be better to convert data field and values into structured text i.e. in the form of sentences mimicking documents. This should be facilitated by the use of pre-prepared sentences or phrases and fillers. Software that converts structured data into sentences (sentence builders) now available in the market can be used or the functionality is built in the CIS software. (comma separated values)

Transformation of Data Collected in Structured Data Format to Structured Text

By transforming structured data into text, it can be read and understood readily. Yet, the nomenclature, spelling and attached code etc. are retained. Hence the data remained structured and can be analyzed by special software.

In some instances, clinical care providers record notes in narrative or freetext form. These can be viewed as they were written.

The mechanisms for transforming structured data into structured text is used to create the Electronic Medical Record (discussed in a separate article).

Charts, Flow-Sheet and Tables (Reports)

Structured dynamic data (data that varies over time) should preferably be displayed as a collective view of sequential measurements in the form of charts, flow-sheet and tables. This enables care providers to determine trends and compare of current value with previous value(s). The creation of graphs is an essential requirement. Graphs should be presented automatically, where indicated, without the need for too much input of criteria or parameters.
Both inferring trends and associations are best left to the clinician but some element of Decision support can be in place. Examples include:

1. associations between two happenings or events (cause and effect) can be surmised if the events are in sequence and there is evidence from past experiences that such associations do occur
2. identify values of parameters exceeding certain limits (e.g. normal levels) or tendencies (e.g. rise or fall). When these happen, the value can be highlighted or a prompt given to the care provider

Results Presented as a Chart and Graph

 Image Viewer

To view images an image viewer application is usually required. The presence / availability of an image within a document, note or chart should be prominently indicated by a GUI which on activation should bring forth and display the image rapidly.

The White Board

Such information can be displayed as lists/tables (WHITE BOARD functionality) or provided ad hoc through a search mechanism. For in-patients, the “WHITE BOARD” can be designed in concordance with floor plans of wards. The tracking function should be capable of displaying the status of service provision as a work list (preferably on the same “WHITE BOARD”). The information consists of the performance status, results of encounter, tasks and reminders. It would be of added value for the “WHITE BOARD” to act as a graphic user interface (GUI) where selecting an item or icon may initiate a software functionality including the entry of data.

Example of Data Presented on White Board

Screen for Various Purposes, Functions, Patient types and Users categories

Data display / views should anticipate the data needs of the care provider and present sufficient and relevant data required to perform the particular task at the opportune moment. It is not sufficient to redisplay data exactly like the way they were collected.
For the sake of uniformity all screens/views need to follow a basic structure. Sets of useful information in various with different content and arrangement can then be provided as views to the clinician. Different screens can be designed according to the following criteria:

1. Patient types
2. Users categories (user access privilege)
3. Purposes
4. Functions

Patient Types

The clinician would need different sets of information which can be determined according to the care plan for that particular patient type. Patients can be categorised according to several criteria including:

1. New vs follow up or referral case
2. Acute vs chronic illness
3. Surgical / medical / psychiatric / traumatic
4. Purpose of visit
5. Stage or phase of care process

Purposes & Functions and User Categories

Different categories of care providers will need different data to provide effective and safe care, even though some information should be known by all involved.
Therefore whether it is at the point of data collection, progress review or giving treatment, a view of the most recent relevant and pertinent data should be provided.

View of Contributions of Other Care Providers

The doctor or nurse in- charge should be aware of the opinions, plans, treatment and outcome of the care being given by other members of team.

GUI for Display of Notes Documented by Members of the Car e Team (to be added)

There should be a facility to filter views by selecting and unselecting items to be viewed and also mechanisms to arrange the sequence of items according to alphabetical order, date and time, result type etc.

Views for Different Categories of Care Providers

Different categories of care providers especially members of the allied health profession would require different information regarding the patient. It is pertinent that their peculiar requirements be anticipated and special views be created for them.

Cases with Previous Visits at another Facility (External referrals)

Cases that had a prior encounter with a health care provider for the same disease episode at another health care facility are categorised as external referrals. There are some differences in approach with respect to both policies and procedure.
One policy to consider is in regards the validity of the data collected at these previous sites. The clinician may accept the existing data or re-collect the data. For data obtained subjectively or is performer dependent, it is up to the care provider to assess the credibility of the data. This includes signs discovered by the referring clinician. This choice may be subject to the policy laid out by the clinical department or the hospital.
The referring facility may make these available as written document or digital data on portable storage medium such as USB drive, CDROM, Flash card etc. It is prudent to convert written document into scanned images and digital data as a text document. These can be stored in a designated part of the Patient Information Database and made available as views.

Information from Previous Visits or Encounters within Same Health Care Facility (Internal Referrals)

For cases previously managed within the same health care facility, the use of a common database allows data collected during previous visits and encounters to be shared. This data may be provided as a view. In general, re-clerking or assessment is required for instances of:

1. Cases Referred from specialist or specialty unit to another
2. Cases transferred from one service delivery system to another (from outpatient service to inpatient service and vice versa
3. Cases that missed their follow up for an extended period of time such that their disease has entered another phase in the natural history of the disease.

Patients on regular follow up need not be re-clerked. Instead a progress review is sufficient.
As part of the decision support system, the clinician is prompted and facilitated to review information from previous visits and encounters. These include:

1.  The current working diagnosis
2. Prior Visits and encounters for the same disease episode
3. Previous results for the same disease episode
4. The Case Summary

View for Cases with Previous Visits or Encounters within Same Health Care Facility  (to be added)

The view should be uncluttered such that relevant information is displayed on a separate window on selecting a GUI (e.g. clicking on an icon).
Cases that had a prior encounter with a health care provider for the same disease episode at the same health care facility are categorised as internal referrals. There are some differences in approach with respect to both policies and procedure.
One policy to consider is the validity of the data collected at the referring unit or by the referring clinician. The clinician receiving the referral may accept the existing data or re-collect the data. For data obtained subjectively or is performer dependent, it is up to the care provider to assess the credibility of the data. This includes signs discovered by the referring clinician. This choice may be subject to the policy laid out by the clinical department or the hospital.

The clinician may accept the existing data or re-collect the data. In regards data obtained subjectively or is performer dependent, it is up to the care provider to assess the credibility of the data. This choice may be subject to the policy laid out by the clinical department or the hospital.
In general, if the case is referred to a specialty unit, the clinician may want to gather more detailed information in their specialty areas. If the clinician opts to re-collect the data or obtain more detailed information, then the method would be similar to that of a fresh case

Monitoring and Observations

Task Performance and Charting of Monitoring and Observations Parameters

Monitoring is an important component of the clinical care process. The data obtained provides feedback and dictates the direction of subsequent care. Therefore, it links the problem identification phase with the treatment phase.
The aspects that require continuous monitoring includes:

1. The patient’s health status
2. Progress of the illness including effect of treatment on the illness
3. Unwanted or side effects of therapy

Detection of change requires some form of measurement which can be subjective or objective. Relevant parameters are measured using a suitable method and the result is quantified as a value according to a unit of measure. For purposes of evaluation, the value need to be compared with certain limits (normal vs. abnormal, high vs. low, acceptable vs. unacceptable values)
The choice of the parameters and the appropriate methods of measurement are based on the relevant criteria for the case type and clinical situation.
These measurements include:

1. Regular review or observation of symptoms and signs
2. Repeated measurement and charting of physiological parameters either continuously or at regular intervals
3. Serial measurement of biochemical parameters
4. Repeated of Microbiological and Hematological tests
5. Follow-up Imaging studies
6. Reassessment using diagnostic studies such as endoscopy etc

The data for monitoring can be from all sources including purposeful entry by care providers, direct interface to monitoring devices, laboratory results and results of other tests. Direct interface with measuring devices is preferred over transcription and matching of results to a patient can be aided with the use of bar-coded patient tag.
Observation of anticipated symptoms and signs is expected of all care providers. Measurement and charting of physiological parameters are usually performed by nurses. These are usually ordered as part of the care plan and are repeated in a cyclical manner throughout the case management period. The user shall be able to determine the frequency of measurement depending on how fast changes are likely to occur.
A good charting and display system should have the following functionalities:

1. Direct charting; where data can be entered directly onto charts whether at regular intervals or on an ad hoc or opportunistic basis without the need for intermediary forms
2. Use of machine-system interface to transfer result values directly from measuring devices to the monitoring application software
3. Use of hand held computers with wireless connection to enter results

Display of Observations and Monitoring Data

The display of monitoring data should have the following capabilities:

1. Indicate the baseline
2. Show all serial measurements made
3. Immediately as they are entered, the data values are displayed in the form of a table (or flow sheet) in chronological order allowing for comparison of current value with previous value(s) and the creation of graphs.
4. Analyse and interpret the changes based on normal or expected values
5. Comments to be made by especially value judgment by care providers on whether there is improvement, deterioration or absence of change

Direct Charting

In paper-based records users enter and view data on a chart. In a computerized system data is entered into a form before being viewed in a chart is a method. Direct charting functionality simulates what users do on paper. By clicking on a small icon on the art a small form is opened and result can be entered. On refreshing the result is displayed in the cell.

This method of data entry is useful in instances where numeric data is to be entered (manually or directly from an instrument) such as for vital signs or just to indicate that a task is done e.g. serving medication. The form should allow for name of performer and time to be entered besides the result.

Direct Charting Method

Progress Review Chart

Care providers assess patients repeatedly in a regular and ad hoc manner. The interval between reviews depends on the severity and the known natural history of the illness. The purpose is mainly to ensure continuity of care. The items reviewed include:

1. Progress of the illness naturally or as result of treatment
2. The health status of the patients (physiological, biochemical and psycho-social)
3. Effects of treatment especially side effects

Review of the Patient’s Health Status

In caring for a patient attention is not paid to addressing the illness alone but to all aspects of the patient’s health including the nutritional status, physical ability and socio-psychological well-being. The patient’s health status is measured by routine monitoring of certain parameters. A general impression is then made. An example is the Activity of Daily Living Score.

Review of Progress of the Illness

 The illness or disease may get better in accordance with the natural history of the disease or as the result of treatment. This may be reflected as improvement in:

1. Reduction of symptoms and signs,
2. Return to normal of physiological, biochemical, morphologic parameters
3. Psycho-social well being
4. Recovery of function of the part involved
5. Recovery of overall function

Progress is determined from variation from the baseline either at the start of the illness or the expected levels for a healthy normal individual. As such, the patient may improve in certain aspects but not in others. The parameters to be used depend on the type of illness, its severity grade and the known disruptions caused by it.
Decision support systems may be used to determine progress where the criteria are straightforward. However in many instances, the conclusion needs to be customized to the particular patient’s disease variation.
Overall progress may be assessed and documented at

1. pre-determined intervals during the visit
2. on discharge
3. at a follow up visit
4. before termination of a care episode

The possible conclusions include:

1. cured
2. recovering
3. controlled
4. improved
5. status unchanged
6. deteriorated, worsened
7. in remission, inactive
8. relapse, flare, acute exacerbation or reactivation

The terms used will be different for different disease conditions based on convention or consensus among clinicians.
View and Documentation of Progress Review (to be added)

Diagnosis Documentation, Display and Use

Diagnosis is an essential data element used extensively by primary as well as secondary users for a wide variety of purposes; from clinical decision making to costing. For this reason there is a great need for standardization of terminology and nomenclature when diagnosis is documented. In clinical practice, diagnosis plays a pivotal role. Determining diagnosis is an important decision making step.

Importance of Diagnosis Data

Diagnosis as an Attribute

Diagnosis can be defined as the conclusion regarding a person’s health derived from the analysis and interpretation of various clinical data expressed as any of the following:

1. Deviation from normal status
2. Confirmation of normal status

The term disease encompasses an illness, disease, health problem, injury or disability. The mechanism for documenting diagnosis should be incorporated into clerking forms, progress notes, radiology reports, endoscopic reports, procedure records and anatomical pathology reports.
The disease itself is further defined by inherent accompanying features and characteristics such as:

1. Onset and duration of illness (whether acute, sub-acute or chronic)
2. Anatomical site involved (for diseases which may affect different sites)
3. Morphology and Aetiology (cause) including pre-morbid factors
4. Sub-categories based on age, aetiological agents or other factors
5. Stage and Severity of illness,
6. Presence of various complications of the illness

A patient may have one or more active (current) illness. From a data management perspective, each is provided with one data field. The value is the name of a disease, illness or heath problem selected from a list derived from universally accepted standard nomenclature lists.
Each one of these problems has certain characteristics or qualifiers which include:

1. Active vs. Inactive Status
2. Accuracy or confidence level (Provisional or Definitive)
3. elative importance
4. Chronology

An inactive illness has ceased to exist and therefore does not impact on the on-going care of the patient. It may have some historical interest and is usually recorded in the past history.

Diagnosis as Used by Various Health Care Professionals

The term diagnosis stands for a number of concepts used by various health care professionals for different purposes within the patient care process. The terms used includes:

1. Reason for Visit
2. Nursing Diagnosis
3. Disability Diagnosis
4. Post-investigative diagnosis (imaging, biochemical, microbiological, histo-pathological etc.)
5. Clinical Diagnosis
6. Cause of Death

From the database perspective, each patient is an entity and all of the above is a set of attributes. The possible value of each can be selected from a peculiar list of health problems.

Reason for Visit

The ‘Reason for visit’ is the reason a person seeks a health care service. From the time of first contact until the patient is properly assessed by a clinical care provider, the “reason for visit” acts as the diagnosis. Despite this, it should have a separate data field. It is determined at the time of Visit Registration and is incorporated in appropriate sections of CIS e.g. the Scheduling application software, Visit Registration and Patient lists.

The “reason for visit” data should act as a pointer at the early phase of care as a guide to triaging, streamlining work flow, matching patient with services they need and allocation of resources.

What is documented as the  reason for visit and the decisions made on it depends on the type of visit as listed below:

1. First visit
   • Walk in visit
   • Referral
   • Transfer
2. Follow up visit
   • Clinic follow up of an outpatient
   • Clinic follow up of a previous inpatient
   • Inpatient re-admission

Reason for First Visit

For the first visit for a new health problem, the reason may take the form of symptoms volunteered by the patient. There are two approaches to documenting the reason for visit i.e.:

• to document the reason in the patient’s own words (in freetext format)
• to interpret the reason given and select a value from from one or more standard Reference Tables made up of symptoms, nursing diagnosis or disease name.

The first approach is applicable when the data is entered by receptionists or registration clerks without a clinical background. The second approach is applicable when the reason determined by or in consultation with is a health care worker e.g a nurse-receptionist or a triage officer.

Reason for Visit in Referred Case

If the patient is referred or transferred from another health care provider or facility, the diagnosis may be made already and written in the referral letter.

Reason for Visit in Planned Follow up Cases

For planned follow up visits within the same facility, the reason for follow up and the final diagnosis documented in the EMR during the previous visit, should be the reason for visit. However the visit can be unplanned, for example if the patient is seeking services for a complication of treatment or an unexpected recurrence.

Reason for Visit

Nursing Diagnosis

The nursing process includes assessment, diagnosis, care planning, implementation and re-assessment. These activities are considered as nursing activities that are separate from the tasks performed by other members of the clinical team. The Nursing Diagnosis is based on symptoms or deviation from normal health identified by the process of Nursing Assessment. It is used as a trigger for the Nursing Care Plan.
It is best therefore, that Nursing diagnosis has its own data fields. The data values are selected from a special list of Nursing Diagnoses.
Nursing Diagnosis

Disability, Handicap and Impairment

The presence of disabilities, handicaps and impairments whether at the commencement of care or subsequently whether as a result of the disease or its treatment need to be recorded. This is usually determined and recorded by therapists involved in rehabilitation as part of the rehabilitative assessment and outcome review, but may also be determined and documented by doctors and nurses.

Disability, Handicap and Impairment

Clinical Diagnosis

The clinical diagnosis refers to the disease, illness, injury or health derangement affecting the patient and is usually made by doctors; be it clinicians or those that perform diagnostic investigations. Once made, the diagnosis determines the choice of appropriate investigations and treatments. This use is of primary importance and should not be overshadowed by other uses. The role of diagnosis in clinical patient care is based on the clinical work flow shown earlier.

Use of Qualifiers

A disease affecting a patient usually has characteristics peculiar to that individual patient. While certain characteristics of the illness such as acuity (acute, sub-acute and chronic) and organ/system involved are already part of the name of the illness, other characteristics that further clarify or enhance the diagnosis need to be documented in additional data fields termed as qualifiers or modifiers.
These include:

1. Anatomical site and side
2. Clinical instance (the context when the diagnosis is made)
3. New or recurrence (exacerbation, relapse)
4. Levels of severity
5. Levels of accuracy
6. Sub-categories such as morphology, aetiology and variants
7. Causes Priority or relative importance
8. Priority/Currency/Sequence

Documenting Clinical Diagnosis

The best approach to capture the name of the illness/disease/health problem together with all the relevant qualifiers in one form. Once captured the information available is used to create views or displays according to needs.

Clinical Diagnosis Documentation Form

The form for the data entry for diagnosis should be designed to encompass the following characteristics:

1. Comprehensiveness
2. Appropriate nomenclature
3. Accuracy level

A Comprehensive diagnosis requires the identification of the following:

• Primary present illness
• Concurrent illness
• Pre-existing illness
• Disabilities, handicaps and deformities

At a visit the patient may be affected by more than one present illness. Hence there is one primary present illness. There may other concurrent illnesses (obvious or concealed). These have to listed. Both the primary present illness and the concurrent illness need to have the accuracy level determined.
The differential diagnosis is a list of possible alternatives to the primary present illness. Since it is only probable its accuracy level need not be stated. The list is an aid to arriving at the proper diagnosis.
The patient may already have preexisting illnesses which have already been previously diagnosed or became obvious during the current visit. Those that have been properly diagnosed should have an accuracy level of definite but those that need further investigation should be considered as provisional.

The documentation of all these diagnosis components need not be done at one sitting but must be completed for the purpose of proving holistic care.

Display of Diagnosis

The diagnosis can be displayed in two main ways:

• in a separate data field where the diagnosis and all of the qualifiers are displayed as structured text
• listed in a table (by convention called the Problem List. The different types of qualifiers are applicable only to certain diseases.

Depending on needs all or only some of the qualifiers can be displayed. Since a patient may be affected by more than one illness, there can be more than one diagnosis. The qualifiers can also be added to the diagnosis field to indicate the primary illness and the other secondary illnesses (based on the priority/currency/sequence qualifier). There are instances both during care of the patient and for statistical purposes for only one diagnosis to be displayed or used. Usually this is the primary illness.

Designating Priority, Currency and Sequence of Various Active Illnesses

The care of the patient during a visit should be directed towards all the diseases affecting the patient. These are termed as the ‘active illness’. It is necessary to categorize these illnesses based into current illness and pre-existing illness. Current illness(es) is an illness that happens recently for which the patient seeks treatment.  Usually there is only one illness (the primary illness) but quite often the patient is affected by another illness (termed as the concurrent illness). The primary illness is usually the more serious illness and given priority but not always necessarily so. Pre-existing illnesses are those in terms of sequence happened earlier. They are already known to the patient or exists in his/her previous medical record. The illnesses may have been untreated or being treated (adequately or otherwise).   Hence the diseases are grouped as designated below:

1. Current Illness
   • Primary Illness
   • Concurrent Illness
     • Concurrent Illnes 1
     • Concurrent Illness n
2. Pre-existing Illness
   • Pre-existing Illness 1
   • Pre-existing Illness 2
   • Pre-existing Illness n

From a data management perspective, each of these diseases are different attributes and should be assigned separate data fields.

Display of All Active Diseases According to Priority / Currency /Sequence

Modifier for Clinical Instance

The clinician documents and updates the latest diagnosis at different instances during the period of care coinciding with various clinical care processes. These instances are as listed below:

1. Initial Diagnosis
2. Post Investigative Diagnosis
3. Working Diagnosis
4. Presumptive Diagnosis
5. Final Diagnosis

Instances of Making a Diagnosis during Different Phases of Care

Initial Diagnosis

The initial diagnosis is arrived at after the initial interview, physical examination and simple tests. It has a low level of accuracy in cases where clinical findings alone are sufficient to make a fairly accurate diagnosis. It can be expressed as a Symptom complex, clinical syndromes, Disease class or Disease entity

Post-investigative Diagnosis

Conceptually, Post-investigative diagnosis is the conclusion based on interpretation of the findings of various diagnostic procedures, investigations and examinations. In effect each diagnosis is a data element which is documented by a care provider providing clinical support services (Radiologists, Microbiologists, Chemical pathologists, Anatomical Pathologists, Haematologists) or the operator of the diagnostic procedure (Endoscopists, Surgeons), as part of his/her report. The possible values should be a standard list of possible diagnoses specific for that diagnostic procedure, examination or tests. It should be possible for data values from this data element to be incorporated into the clinical diagnosis.

Working Diagnosis

The working diagnosis is made every time the clinician reviews the patient and is based on data currently available to the clinician. Therefore, post-investigative diagnoses (based on the results of imaging, biochemical, immunological, microbiological, Haematological cytological, Histopathological, Endoscopic, Laparoscopic and Postoperative investigations) should be incorporated into the working diagnoses. Therefore a mechanism should be made available for this to happen automatically or manually (e.g. by copy and pasting).

The working diagnosis is documented as part of the clinical task of Progress review. It has varying degrees of diagnostic accuracy depending on the amount and accuracy of data available.
It is also the diagnosis on which the Care Plan of the patient is based.

Presumptive Diagnosis

A Presumptive diagnosis a diagnosis that is provisional but is documented as if the pathology has been confirmed when actually it is only assumed e.g. squamous cell carcinoma of skin based on clinical appearance alone. It appears to indicate a greater accuracy than the data available to support it. It is used when the clinician feels that the diagnoses can be assumed with a high degree of probability and when the specific treatment plan need initiated even though the diagnosis has not conformed with the diagnostic criteria.

Final Diagnosis

It refers to the diagnosis that is known and documented at discharge from a visit or permanent termination of care. The final diagnosis is not necessarily the most accurate.

Accuracy Level Qualifier

During the course of patient care, diagnosis of varying accuracy is made and altered repeatedly until the highest level of accuracy is achieved. Each instance of making a diagnosis is a cognitive process. It has to be documented as any other process i.e. the person, date and time and context need to be documented.

The level of accuracy changes as more data is accumulated. Depending on the data available, the basis for diagnosis can be categorized as clinical or pathological diagnosis with the latter considered as more accurate.

When diagnosis is documented, a qualifier for accuracy of diagnosis is attached. For practical purposes the accuracy level is best categorized as either Provisional or Definitive. The provisional diagnosis is made based on clinical findings and simple tests. The definitive diagnosis are based on any finding that is considered as “diagnostic” such as results of laboratory tests (biochemical, immunological and microbiological  and imaging and anatomic pathology) and diagnostic imaging  examinations. Sometimes, a definitive diagnosis can be made on clinical presentations alone.
It is to be expected that a diagnosis becomes increasingly more accurate as care progresses. At the beginning, the patient’s symptom complex or syndrome may be documented as the diagnosis. At the end of a care episode the application allows the diagnosis to be stated as a specific disease. Therefore the the accuracy level is related to the phase or instances of care :

1. Provisional diagnosis
   • for instances such as the interim, working and presumptive diagnosis
2. Definitive diagnosis
   • for instances such as post-investigation diagnosis, post-operative diagnosis, histopathological diagnosis, post- mortem diagnosis, final diagnosis)

Display of All Current Diseases Affecting the Patient and the Accuracy Level

Severity Level Qualifier

Severity is an important criterion for determining the care pathway and therefore care plans. The management of a disease like Bronchial Asthma for example, is very different when the disease is mild as compared to when it is moderate or severe. Severity is determined by various criteria that include the variant of the illness, status of the patient at beginning of visit and any subsequent deterioration. This in turn would indicate the occurrence of complications. It is therefore important to document the complications of illness. The stage of an illness at presentation is one way of expressing severity.

Data Display for Diagnosis with Qualifier for Severity and Accuracy

The earlier the categorization of severity is made, the more likely a better outcome would be achieved. Computerization provides the opportunity for giving quantitative values to each criterion thus enabling the use of mathematical formula for determining severity.
From a quality management perspective the outcome of a patient’s illness is dependent on its severity. It is therefore pertinent for level severity to be documented.
The standardization of measurement and categorization of severity is a difficult issue. Each disease has its own categories which are based on clinical, physiological, psychological and pathological criteria. A lot of effort has been put in by health care professionals but only in a few areas has consensus been published. It is best for clinicians in each hospital to come to an agreement on the severity levels and for software designers to build the applications and the database.
A mechanism needs to be put in place to link each diagnosis with its own severity level. It would be preferable (whenever possible) for the decision support system to detect the values of each criterion, calculate them according to the agreed formula and to ascertain the severity level automatically.

Qualifier for Side and Site

This is a qualifier for anatomic location. A disease can be systemic (involves the whole patient) or may be confined to one or a few locations (sites) and for organs that has are in pairs only one side (right or left). Sites may refer to a particular organ or part of that organ (the upper, middle or lower part). To a clinician the precise location of the disease is of utmost importance. However, nomenclature lists of diseases may or may not specify the site and side. For disease names where the site or side is not spelt out, the use qualifiers for site and site are essential for the clinician.

Qualifier for Morphology

This diagnostic qualifier is used mainly for pathological diagnosis based on microscopic examination of tissues (histopathological, cytological and haematological examinations). Many diseases can be further specified by their morphologic characteristics i.e. microscopic appearance of the tissue, preponderance of certain cells and staining characteristics. This is applicable to tumours (both benign and malignant) and to haematological disorders (diseases involving the blood cells). However once it is made, it may be incorporated into the clinical diagnosis.
Each disease has its own range of morphologic types which can be specified by choosing one from a reference list for morphology.

Qualifier for Aetiology and Cause

Infectious diseases are caused by micro-organisms. Some diseases are caused by a specific organism and therefore the name of the organism or its family is already conveyed in the nomenclature. Examples include Staphylococcal pneumoniae, Gonorrhoea and Hepatitis A. However for Sepsis, Arthritis or Conjunctivitis the name of the causative micro-organism has to be incorporated in the diagnosis through the use of a modifier for aetiology.
Other diseases happen because of other causative factors. These include:

1. Trauma including accidents and assaults
2. Physical agents
3. Chemical agents
4. Poisoning
5. Contact with Animals and Plants

To express the cause, lists of causes need to be made available. In fact for these type of diseases, the recording of cause is most appropriately done at the time of taking the history. It shoud then be incorporated into the diagnosis automatically.

For the clinician, it is important to express the cause to degree of detail sufficient for the understanding of the disease process or its management. The clinician should not be expected to documents facts that are beyond their ability to ascertain. Some epidemiological data is best determined through research methods or information from other sources. Examples include whether the cause of cancer is related to smoking or the accident is between a wheel-chair and a tricycle.

Qualifier for New or Recurrence

The same disease may have the tendency to relapse even though it has been declared to be inactive. Others may remain at a sub-clinical status and flare up or exacerbate in response to triggering factors.
A new disease is one that is occurs for the first time. However, a repeat occurrence of an illness is not necessarily a recurrence. Many common diseases are cured but occur again as a new episode e.g. common cold, acute gastroenteritis and abscesses.

Using Standard Terminology and Nomenclature for Diagnosis Data

Because of the large number of diseases, symptom complexes, syndromes and variations of each disease, the clinical diagnosis should be a primary value derived from a standard list of diagnosis from a reference table mapped against universally accepted nomenclature lists,
Where necessary the CIS should display the primary value and the modifiers as a single composite string in a single data-field (see section on Documentation of Current Illness).
Once documented, the clinical diagnosis should appear automatically as part of the view in appropriate sections of CIS such as work lists, surgical operation lists, case summaries, discharge summaries and cause of death certification

Decision Support for Formulating a Diagnosis Using Diagnostic Criteria

A diagnosis is made by considering certain variables including signs, symptoms, clinical test results, investigation findings (laboratory, imaging, and endoscopy), monitoring parameters, clinical progress and response to treatment. Through research and experience the medical profession has identified sets of variables i.e. the criteria that predict a diagnosis. This knowledge can be presented to care providers to assist them in making a diagnosis. In certain instances, especially when a scoring system is used, these predictions have a high level of accuracy. For this purpose there must be a facility to assign numerical values to each criterion, compute the score using the relevant formula and present it in a calculated data field. A comparison is made with the expected scores to determine the likelihood of the diagnosis. However a rough guide can be just as useful to the clinician.

Recording Past Illness as Part of History

All diseases that have been resolved or has become inactive should be considered as Past Illnesses.
This feature should be made available in the section for documenting Past History in the clerking or assessment form. It should be assumed that pre-existing illnesses and past illnesses are included in the Past History.
Diagnosis data taken when querying the patient about his/her “Past history” should be incorporated into the Problem List if the degree of certainty is high.

Recording past illness as part of history

Display of Diagnosis Data

1. Reason for Visit
2. Nursing Diagnosis
3. Disability Diagnosis
4. Clinical Diagnosis
5. Cause of Death

Display of Clinical Diagnosis

The clinician documents and updates the latest diagnosis at different instances following the performance of various clinical care processes and as listed below:

1. Initial Diagnosis
2. Working Diagnosis
3. Presumptive Diagnosis
4. Post-investigative (radiological, biochemical, immunological, cytological, microbiological, histo-pathological etc.)
5. Postoperative Diagnosis
6. Final diagnosis

These titles are used as labels representing the same data filed (e.g. Diagnosis of Primary Illness). For purposes of display, diagnosis may be presented as

1. Data field containing structured text
2. Problem List

Display of Diagnosis as a Data Field with Composite Values

The CIS should display the diagnosis as an attribute with the attending modifiers, as a single composite string in a single concatenated data-field. When entering data in forms Primary Illness, Concurrent Illness and Pre-existing Illness should be displayed in their own data fields. However in views, the CIS should display each of those diagnoses as an attribute with the attending modifiers, as a single composite string in a single concatenated data-field, whenever possible or necessary.

Diagnosis Displayed as Composite field of Structured Text

Display of Diagnosis as a Problem-List

Presenting all diagnoses as a list of problems is a very useful method of both in the CIS and in the EMR. This list indicates all the diagnosis made regarding diseases or illnesses that has affected the patient. The diagnosis / problems are listed in chronological order as rows with modifiers in the columns. Modifiers for this purpose should include the activity status (active vs. inactive), importance (primary vs. concurrent), currency (current vs. pre-existing), accuracy level (provisional vs. definitive) and validity
The diagnosis documented at any time during the clinical work process should be inserted into the problem list by using the same approach.

Diseases Affecting a Patient within a Care Visit/Episode Viewed As A Problem List

The problem list should enable all diseases affecting a patient within a care visit / episode to be documented and viewed instead of creating a problem list for a particular encounter
The Problem List should also be applicable across visits and episodes as a part of a Lifetime Health Summary. It should be designed to be a permanent and dynamic all-inclusive list of health problems ever experienced by the patient in a chronological order. It should allow for new occurrences to be added as active disease and resolved problems to be denoted as inactive. Entries with the accuracy level of provisional are temporary, to be replaced by a diagnosis that is definitive. Invalid entries, such as diagnosis proven to be wrong, should be removed from the list.

Review of Status of Various Diagnosis

As part of the clinical process of  Progress review, all the diagnosis made by the clinician need to be presented. He/she reviews each of the diagnosis made and indicate their activity and validity status by updating the Problem List. For purposes of care, only active and valid diagnosis need to be presented to the care provider. However for the purposes of the Lifetime Health Record all diagnosis made need to be presented including those indicated as inactive and invalid.

Active vs. Inactive

Across care episodes, the disease may resolve spontaneously or is cured. When performing a Progress review, it is important for the clinician to indicate that these diseases have become inactive and therefore cease to be a problem under consideration. In other words, the disease episode has ended. It should also allow for change of status from “active” to “inactive” once the disease resolves.
An active illness still affects the patient, requires attention and continuity care (follow-up). The Problem list allows for new occurrences to be added as active disease and resolved problems to be denoted as inactive.

Valid vs Invalid Status

During a care episode, care providers changes the diagnosis from postulates made earlier to one that is different altogether. The problem list should allow the clinician to indicate the diagnoses that is confirmed or its likelihood is still being entertained as ‘valid’. When a diagnosis is discarded because it is  mistakenly entered or found to be incorrect, it is indicated as “invalid”. For example a patient may be initially diagnosed as Anxiety Neurosis but the diagnosis is discarded after investigations confirm that the diagnosis is actually Thyrotoxicosis.

Different views of the Problem List

There should be different views of the Problem List in the CIS application including:

1. All entries, sequenced according to date of entry of diagnosis data
2. Valid entries only
3. Active and current diseases only

There should be a way to distinguish between Current and Past problems. All active problems should be considered as a current problem.

Problem List Showing all Diagnosis Made at a Certain Date and Time

DOCUMENTING DEATH

From a clinical perspective, death is an event and should be recorded as such. It means capturing data regarding

1. the time of occurrence,
2. the location,
3. the persons who witnessed the event and
4. what actually happened prior to the event that has not been recorded earlier
5. attempts made to avert the event (resuscitation)
6. the physiological dysfunction that caused cessation of life
7. the effect of the illness or complication that directly lead to death

Many factors can lead to death. They form a sequence along the path that can occur in the natural history of a disease.
The care provider needs to record the manner of death such as hypoxia, circulatory collapse (due to various reasons), brain dysfunction, respiratory failure and cardiac failure. However these are by no means the cause of death to be included in the death certificate.
While the declaration of death part of the EMR, the cause of death certificate itself is not

The Cause of Death Certificate

The medical certificate of cause of death (death certificate), as recommended by WHO, is used mainly by health authorities for purposes of disease prevention. However it is also sought by other secondary users including medical record officers and researchers, for purposes beneficial to them. Clinicians or the hospital’s clinical governance may use the data in clinical audit especially the Mortality and Morbidity review.
A different official certificate named as the Death Certificate is used for purposes of law enforcement by law enforcers, lawyers, and insurers. The form and content of this is defined by the law of the country concerned.
From the standpoint of statistics and epidemiology the most important data to capture is the underlying cause of death which is defined as “the disease or injury that initiated the morbid events leading directly to death.”
The form to be used to submit cause of death is as shown below:

WHO Recommended Certificate of Cause of Death

Populating the Cause of Death Certificate Automatically

As espoused by WHO, the certificate shown above is designed to facilitate the selection of only one value to be used for “primary tabulation” of the underlying cause of death. All other information are meant to aid the coder or reporter select this value. Part I of the form is for the train of events leading directly to death and the underlying disease. These events can be in two or three tiers. Hence a) and b) can be a complication of the illness, b) or c) or d) can be the underlying illness. Part II is for conditions unrelated to the illness in Part I but in some way also contributes to the death.
With the use of a computerized CIS, the cause of death is a conclusion based on the analysis of the illnesses and other factors affecting the patient accumulated in the Patient Information Database. The medical practitioner should only finalise his/her conclusion after all relevant data has been extracted and presented. The upper most line of Part I (a) of the certificate is usually for indicating the effect (complication) of the diseases or health problems that directly caused the death. Part I (b) is designated for the antecedent or secondary cause of death which include effect (complication) of the diseases and also complications of therapy or the performance of investigations, whether surgical, medical or physical. The underlying cause of death is the disease recorded on the lowest used line of Part I (b or c or d) of the certificate. It should be derived from the most definitive diagnosis made before death and is selected from among the many morbid conditions recorded in the Diagnosis data fields or Progress Notes in the Patient Information Database / EMR. To populate Part I (a, b, c or d), all the diagnosis made and documented during the course of care of the patient need to be listed. The value for a, b, c or d should be selected from this list by the person reporting the death. The diagnosis data should be extracted from what is already captured in the various data fields for diagnosis,  complications of illness,  complications of intervention as well as incidents in the patient information database.

Data Elements from Where the Cause of Death is Derived

DOCUMENTING ALLERGIES

The CIS should provide the facility to document and display data regarding allergies using same data field to cater for the following instances:

1. Documenting history of allergy
2. Documenting occurrence of an allergy
3. Displaying allergy data in patient profile
4. Displaying allergy data in Case summaries
5. Displaying allergy data as Decision support data
6. Use of Allergy data in for contraindications notification in Pharmacy System Decision support functionality.

The documentation of allergies should take into consideration three groups of triggers of allergy:

1. Drugs and chemicals
2. Food
3. Physical elements

It is necessary to assign the data elements to three different data fields.
Allergies to drugs and chemicals is documented in a specific data field using structured data values read from a reference table containing the same values used for reminders when prescribing drugs and administering contrast agents etc.
Allergies to food and physical agents may use free-text values.