FUNCTIONS OF CLINICAL INFORMATION SYSTEM (CIS)
The Clinical Information System (CIS) is that part of the Hospital Information System (HIS) which facilitates direct patient care i.e. activities where care providers:
- interact face to face with patients
- perform procedures that affect them physically, physiologically or psychologically
Care givers providing direct care are called ‘clinicians’, a term that refers not only to doctors and nurses but also includes Dietitians, Therapists, Clinical psychologists, Clinical pharmacists, Clinical Microbiologists, Interventional Radiologists, Endoscopists, Optometrists, Audiologists 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 processes performed by care providers in providing clinical services to a patient. They consist of:
- Physical Examination
- Formulation of Diagnosis
- Monitoring, Review and Evaluation
- Case Disposal
Within patient care institutions, clinical care processes are fairly standard, despite the vast array of clinical specializations. While different specialties serve different patient types, the basic tasks and data needs are the same. The entire clinical processes may be completed during a visit or may be stretched across several visits. Often, all or part of these steps is iterative (cyclical), being repeated as progress is reviewed, usually 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:
Generic Clinical Care Work Flow for a New Patient
The subject of Clinical Care Processes is discussed in detail in another article.The Clinical Information system is designed to facilitate all these processes. An effective CIS promotes the integration of work flow, and standardization of procedures. The use of common terminology is essential so as to enable effective communications. There is no need for different systems to be built for each clinical specialty or service setting. Instead peculiar requirements stemming from differences in tasks, data elements and other needs are met by addition of data elements or modification of the means of data entry/data display and 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:
- Data collection (gathering, capture, input, entry)
- Data storage (accumulate and make available)
- Data extraction (retrieval, output)
- Data transmission (submission, retrieval)
- Data presentation (display, view)
- 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. These data management steps are illustrated in the flow chart below:
Clinical Care Processes as Data Management Activities
For the purposes of clarifying the scope, the system that facilitates the above functions is termed as Clinical Information System (CIS). 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 to be recorded. These data are accumulated in the pool of data regarding the patient, termed as the Patient Information Database, from where it can be retrieved when needed.
FUNCTIONS AND COMPONENTS OF CIS
The CIS is the major part of a comprehensive system that facilitates the entire patient care activity (the Patient Care Information System). The other 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) 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. The exception is when they provide care directly to patients (e.g. clinical microbiologist, clinical pharmacist, interventional radiologist), in which instance these events and results relating to the care of the patient are documented in the CIS.
The Clinical Information System (CIS) are tightly linked to the Clinical Support applications through the following mechanisms:
- Provision of the means of communications between the two groups of care providers via the Order Entry system
- Transfer of results from the clinical support applications to the database of patient data (the Result Reporting mechanism)
- Provision of relevant summarized clinical information to clinical support personnel to assist them perform their work
An important function of CIS is to help create the Medical record. In a computerized system, the ‘Electronic‘ Medical Record (EMR) is similar in content and structure as the record captured on paper. It is still a record of pertinent data regarding an individual patient arranged in a chronological order. However, the way the EMR is created is quite different. Because data is captured in a database and usually in a structured form, the pertinent data making up the EMR is extracted from the database and rendered into a format that satisfies medico-legal and professional requirements.
The functions and components of the system to facilitate direct patient care are as depicted below:
Functions of CIS
All the above functions are provided as modules within a fully integrated system.
OVERALL CHARACTERISTICS OF CIS
The CIS is a set of applications that facilitates every aspect of direct patient care or clinical care. The CIS should not be considered as a system of documentation to generate the EMR (despite opinions to the contrary). The CIS facilitates clinical operations (work) including the planning of care, implementation of care, quality control and the capture, storage plus distribution of clinical data.
Functional Components of the Clinical Information System
COMPONENTS OF OF CIS
The CIS contains application modules (however named) that enable the following:
- Planning of care (use of Care Plans)
- Provision of Clinical Decision Support
- Clinical Data Documentation (Data entry)
- Quality Control
- Data Storage
- Data Retrieval and Display
PLANNING OF CARE
A well designed CIS enables patient care operations achieve the following objectives.
- Encourage activities to be performed in a planned rather than ad hoc manner
- Create uniformity and standardization of procedures and processes
- Ensure appropriateness, comprehensiveness and timeliness of care
INCORPORATION OF CARE PLANS
The realization of care objectives is achieved through the incorporation of Care Plans as an application for planning, implementation and evaluation of care. Care plans 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 mechanisms used to create care plans need to be based on a sound approach and valid evidence. For this reason, a good CIS vendor usually provides the following:
- Tools for building or customizing Reference Care Plans according to the needs of the health care facility
- A ‘starter pack’ of ready-made care plans for common conditions
The health care facility should 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. The tools provide the means to:
- Arrange, sequence and schedule sets of tasks according to work flows or care pathways
- Put together various orders to create care sets that will initiate the above tasks
- Fashion and furnish guides on how a task is to be performed
- Design documentation forms or charts for the capture of data generated by the planned tasks
It is also expected that modifications of care plans already provided and those newly developed will be endorsed by the clinical governance body of the hospital.
CONTENT OF CARE PLANS
The content of a Care Plan is designed to cover all aspects of the management of a particular health problem. Therefore, 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 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:
- a symptom (as in Nursing Diagnoses) or Symptom complex or Reason for visit
- a syndrome (e.g. Intestinal obstruction, Obstructive jaundice or Bradyarrythmia)
- a diagnostic related group (DRG)
- a specific disease
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). Care plans are also made available for specific treatment programmes e.g. specific procedure and treatment regimen. Modules are also created for various severity levels and patient profiles.
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:
- Administrative tasks (Admission, Referrals, Transfer & Discharge, visit registration, follow up appointment, referral and discontinuation of visits.)
- Generation, gathering and collection of data about the patient’s illness and the effect on his/her health. Data collection tasks e.g. Clerking or Assessment using a specific clerking form and Progress reviews guided by various note types.
- Analysis and interpretation of data to determine the diagnosis and needs of patients
- Investigation tasks, Diagnostic tests
- Treatment using various modalities including therapeutic procedures, medication to be supplied or administered, blood product supply & transfusion, Nutrition provision , Counseling, Rehabilitation and other therapeutic tasks
- Monitoring plus Review of the progress of the illness, status of the patient’s health and effects of treatment (including assessment of outcome)
- Review of diagnosis and management
- Patient education
- 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. 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.
Breakdown of Care Plans into Task Lists
Variations of the care plans are created for each diagnosis by taking into consideration the following possibilities and eventualities:
- stage and severity of the illness
- complication of illness
- 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:
- Division of care into periods (phases)
- The chosen diagnostic or therapeutic modality
- 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 patient care duration (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:
- Inception of care administratively (Admission, Referrals, Transfer)
- Initial assessment and derivation of diagnosis
- Resuscitation (if necessary)
- Definitive Treatment
- Evaluation and Modification of treatment
- Continuity of Care
- 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 FACTORS
The basic Care Plan is designed for 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 incidents
Variance in outcome is detected through monitoring, progress review and evaluation. 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.
EXECUTION OF CARE PLANS
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:
- Use of plans as reference (guide)
- Customization of the reference plan into executable operations plan
- Documentation of the data generated by the tasks performed
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. Next, mechanisms are provided to create and execute a customized plan 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 it in a separate table. This occurs (as is the practice with nursing care plans) despite a good understanding of the clinical care processes (Nursing Process).
However, the status of planning, its execution and outcomes can be displayed separately as a view by deriving the information from the database.
The plan is a statement of intent and objectives. It is executed through orders. The outcome achieved should not be written in a separate table but included in the progress review and evaluation. There is an element of quality control whereby two criteria are evaluated:
- Have the plan been followed?
- Have the objectives/desired outcome been met?
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 the patient care processes. 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 tool for execution of care plans is the Order Entry application.
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 use check lists.
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).
TRIGGERS OF CARE PLANS
The patient care workflow begins with visit registration (check in), followed by various clinical care processes and ends with end of visit (discharge, check out). There is a major difference between the workflow of new compared to follow-up patients. Generally, the care of new patients starts with data gathering to determine the diagnosis and 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.
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:
- New Case: To obtain care for a new health care problem (symptom, symptom complex, syndrome)
- Referral: to continue care provided earlier at another unit/institution
- Elective Follow up or Readmission: to continue the remainder of care previously planned
- 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.
Care Plan 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 content of this initial care plan is data collection tasks from which it is hoped that a clearer diagnosis is obtained. From there, the plan containing various processes or tasks for the more specific disease condition or health problem is chosen and initiated.
Care Plan Triggers for a Follow-up Case
The plan at a follow up visit may be predetermined at the time of discharge from the previous visit or decided after an initial review at the beginning of the current visit. For the latter, a nurse may assess the patient’s progress and decide whether the patient can proceed to the next phase of care. Otherwise, the doctor can assess the outcome and decide if a change of plan is necessary.
CONSTRUCTING ACTUAL CARE PLAN USING 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:
- Current orders (meant to be performed immediately)
- Recurrent orders (meant to be repeated at certain intervals)
- Future orders (meant to be activated at a proposed date or time)
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 for an order to be executed later to be made earlier. It can be triggered by an event (e.g. discharge, follow up, admission) or a defined date and time.
Design and Execution of Care Plans
CARE PLAN FOR ACUTE ILLNESS
In acute illness, the phases of care include:
- Triage & initial diagnosis,
- Further data gathering (monitoring, investigations)
- Definitive diagnosis
- Definitive treatment
- 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 from 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 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 for Acute Coronary Disease
Example: Care Plan for Patient with Symptom Complex of Acute Chest Pain
Example of Order Set for Initial Phase
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.
CARE PLAN TRIGGERS FOR CHRONIC ILLNESS
In the context of the care of chronic illness, the phases include:
- Phase of diagnosis or problem identification and elaboration
- Phase of initiation and stabilization of therapy
- Phase of maintenance of therapy aimed at optimal control
- Phase of detection and amelioration of complications.
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 plan remain relatively unchanged but certain parameters are reviewed to detect emergence of complications of the illness and treatment. Plans for such eventuality would be available.
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. Care plans play an important role in clinical decision support. These roles relate to the provision of:
- Instructions and advice to the care provider
- Knowledge at the point of care.
Each of these is discussed further below.
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.
Clinical decision support is envisaged not as a single system or application but as built-in functions within all the patient care application components especially the CIS. It is applied through several approaches i.e.:
- Guide to the data to be gathered and captured
- Guide to making a diagnosis
- Provision and matching of care plans for various categories of patients at different phases of care (discussed earlier)
- Computer analysis and interpretation of results (normal, abnormal, scoring, stratification, grading, staging, comparison with standards for quality control)
- 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
- Provision of views of essential patient data according to needs at various instances of care (encounters) in the form of summarized just-in time and up-to-date data; especially for clinical support providers
- Selection, arrangement and presentation of the patient’s own data previously acquired or generated to help care providers make decisions
- 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 facility)
- 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.).
Providing Direction through Care Plans
The whole CIS is designed such that the clinician is guided by care plans right from the first encounter based on 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.
Mandating Data Collection and Providing Appropriate Tools (Forms & Charts)
The type of data 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). 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. 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 evolution 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.
Providing Reminders and Alerts
Mechanisms are made available to provide reminders for instances such as:
- failure to complete a care plan or non-conformance to it
- failure to act on an incident
Alerts may be given for instances like:
- the result obtained is abnormal or the trend is disturbing
- the desired outcome is not achieved
- presence of allergies may contraindicate a certain treatment or caution is advised
- an untoward event has occurred probably as a result of treatment (allergy, peculiar symptom or sign, side effects)
- an underlying disease may affect choice of treatment
The Decision Support System provides advice/suggestion/direction to the care provider regarding:
- Derivation of Conclusions (re: diagnosis, staging, prognosis)
- Further actions to be taken in the clinical care process such as alternative care plans
- Choice of modalities or methods to be used for:
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 how to perform the following:
- Perform a clinical procedure
- Submit Incident reports when an event occurs
- Submit data for registries and audits
- Submit mandatory reports to authorities e.g. notification of infectious disease
- Provide patient education
DIAGNOSIS DECISION SUPPORT
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
Risk Stratification, Severity Grading & Staging
Having made the diagnosis the clinician needs to clarify further:
- which variant or grade of the illness is affecting the patient
- which stage of the natural history of the illness has been reached
- what complications has accompanied the disease
- 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.
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.
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).
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 include evidence based guidelines and basic medical knowledge such as anatomy, physiology, pharmacokinetics, staging systems, body mass index, surface area, nutritional requirements etc. The Decision Support System can provide knowledge at the point of care regarding the following:
- 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
- Choice of various modalities for investigation, monitoring and treatment
- Appropriate investigations for a clinical problem
- Various aspects of treatment (surgery, anaesthesia, invasive procedure, chemotherapy, radiotherapy)
- Management of complications of a treatment regime (e.g. total parenteral nutrition, ventilatory support)
- Indications/contraindications and pre-requisites for use of a modality, drug or procedure
Chart Showing Where Information May Be Provided to the Clinician by the CIS
ORDERS & TASK EXECUTION
Care providers perform their work by performing various tasks or processes. The term ‘order’ refer to requests, instructions, or intentions to perform tasks. Through them, a care provider makes known his/her plans and needs to other care providers, inviting them to be involved in the care of the patient. Once made, orders become tasks to be performed. The tasks are listed and addressed one by one by the person responsible to perform them. 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
Each task can be given a charge which can be billed once the task is performed.
MANAGEMENT OF PATIENT DATA
Clinical care-providers use and share information regarding a single patient as well as groups of patients when performing their work. The CIS provides the means for care providers to manage data.
DATA MANAGEMENT FUNCTIONS IN CIS
The CIS manages the entire operations data of a single patient as well as groups of patients. It provides the following mechanisms:
- Collect and capture all data generated by patient care activities and events
- Submit data for storage in the Database of Patient Information
- Retrieve and present data as views and displays containing appropriate data arranged in a manner such that various tasks can be performed effectively, efficiently and safely
- Capture for subsequent compilation all relevant data of a single patient that constitutes the EMR
Data Management Steps
Direct care providers enter data that they obtain or generate via data entry tools provided in the CIS. Clinical data of the patient can be imported or supplied by other health care organizations (data from elsewhere). Care providers can retrieve data supplied by clinical support services from the Patient Information Database. Access to information contained in CIS is provided to all users on a need to know basis and is operationalized through access control based on privileges. Clinical providers can enter data and view data limited to their role. Non-clinical personnel may be given “read-only” privileges.
The EMR is then derived from the data that has been collected and stored in the Patient Information Database.
Content of Clinical Patient Data
Clinical patient data are those generated as a result of clinical activities and recorded either by the clinical care providers or through machine-system interfaces. Sets of useful information in various combinations and configurations are configured and provided as views to the clinician to facilitate him/her in various clinical tasks. These could be:
- a description of the patient
- a description of the patient’s health problem(s)
- results of procedures or tests
- any set of data that facilitates decision making
- information that assists task performance
In a computerized environment, the term documentation is inappropriate. Documentation refers only to a specific method of data entry where forms are used. The more accurate term is data acquisition. It includes the processes of data collection, gathering, entry, capture and storage. Data acquisition needs not be seen as a distinctly separate activity but rather an integral part of clinical care processes. It is an essential part of any procedure, process or task being performed. A plan is expressed as orders which are converted into tasks. Each task mandates the capture appropriate data by completing data entry forms, charts or other means.
Data Acquisition Workflow
This is true even when direct charting into result tables is used. It is assumed that each entry is made after a task is performed. Thinking and making a decision is also considered as a task. These tasks are usually planned but occasionally unexpected events or incidents would occur. The description of such events is entered ad hoc.
This subject is discussed further in the appropriate sections.
Database of Patient Information or Patient Data Repository
Data regarding the patient that are generated by administrative and clinical activities are gathered and stored in a database. Additional data is derived from other systems which include:
- Patient Management System (identification, demographic and communications data)
- Data from elsewhere (referral notes, visit summaries, results from other institutions)
- Results produced by clinical support systems (laboratory test results, imaging reports, data/supplies by Pharmacy and Dietary unit)
The use of a database enables care providers to share data and communicate with each other without the need for face to face interaction thus facilitating continuity of patient care.
In a computerized environment, the Medical Record is no longer the main source of information of clinical data for use during the process of care (unlike when paper records were used). Instead it is a permanent historical record of events and all activities of patient care where the content and structure is determined by medico-legal and professional requirements.
Having been stored in the database, the data can be extracted, rearranged and presented to the user as views or displays in the form of text, 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.
The Data Acquisition, Storage and Retrieval Cycle
The database enables relevant sets of useful information to be extracted and made available in the format that will help users carry out both clinical and business activities. The data can also be aggregated for secondary use such as clinical audits, creation of registries, utilization reviews, epidemiology and health care planning. These are usually shown as tables, charts or graphs.
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 derivation of EMR data from CIS 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.:
- the CIS provides the means to manage data and use it for performance of clinical processes
- 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 :
- a particular care process,
- use (e.g. monitoring, medication, surgical procedures)
- 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.
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.
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:
- Understanding the database
- Additions and improvements to the design
- Facilitating data extraction
- Subsequent data-migration to a new CIS system, when necessary
Database Management System (DBMS) for Patient Data
The data storage software should be:
- 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
- in the form of structured data that can be 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:normalized i.e. each data element is represented by one data field without duplication unless absolutely necessary
- consistently depicts the chronology of events
- the context surrounding the data collection (the event, location, person involved) is captured
- accuracy and standardization in use of terminology
- integrity (not lost or corrupted)
- security, confidentiality and privacy
- easy accessibility
- constant availability
- comprehendibility (easily understood)
- 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 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 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:
- High availability
- Confidentiality and privacy
- Concurrency control (facilitate use by many users at the same time)
- Business continuity (Up-time, Redundancy and Mirroring, Data back-up and Disaster recovery)
- Data integrity (built in mechanisms to ensure data submitted is captured and subsequently not lost or corrupted)
- Sufficient capacity to accommodate data produced at least for 5 years of use (upgradable storage capacity)
- Technical interoperability with the network, with application servers and analytical servers.
- Record read and write events as a journal
- 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 conceptual integration of the applications software and the hardware is depicted in the figure below.
Data Flow between Components of Patient Care Information System and the EMR
DATA ACQUISITION AND DISPLAY IN CIS
The CIS facilitates the use patient data through three main mechanisms:
- Provision of data entry tools (usually either forms, charts or automatic transfer of results from machines / instruments)
- A database management system (DBMS) to store the data
- Presentation of results of queries of the database as views or displays
In practice, care providers usually views whatever existing data that is available before proceeding to data collection. Even for a new case, some data is already available e.g. demographic data collected at reception and referral letters.
Data Entry Tools vs. Views
Mechanisms for data entry and for viewing data need to be differentiated in CIS. A documentation form or chart, when in use, provides the means to enter data values into data fields. Even though the same form used for data collection can be retrieved, a more useful approach is to create views that are extracts from the database of data relevant for the purpose at hand. (e.g. for purposes of modification). The only occasion for retrieving the form is for purposes of correction or modification.
Care providers acquire and capture data generated by various tasks in the course of their work. Data may be static (do not change with time) or dynamic (varies with time). For static data, values are captured once and used whenever necessary by the same or different care providers. As such it should not be necessary to re-enter static data but the data must be presented to the care provider as part of the view of previously stored data. The Patient Information Database must be strictly normalized i.e. duplication of data fields for the same data element should be avoided. For dynamic data, what is acquired by one care provider must be available or communicated to the whole team.
Data accumulated in the database can be analysed and interpreted before being displayed as a view. Hence, many difficult calculations and derivations previously done by care providers can be performed by computer programs. 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 percentage of expected value for a patient of the same age or size. Indeed more complex computations can be done.
Design of Human-Computer Interface
Users interact with the computer system at any instance through a screen which can vary with different 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
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 view
- Single patient view
Patient List and Urgent Tasks View of All Patients
The all patients and all tasks view is a summary meant to give some pertinent information on cases assigned to the care provider in terms of who they are, where they are and the case type. Detailed information regarding them is inappropriate in this view. Other information includes messages from other care providers, referrals, reminders and tasks requiring urgent attention. This view supports the function of the care provider as a manager of all cases under his/her care.
Integrated User-System Interface (Views) of All Tasks Scheduled for a Clinician at a Particular Time
Single Patient View
The single patient view is meant to enable the care provider to concentrate on the case without encumbrances of other issues. It ensures the he/she views the right patient’s data and enters data into the right record. He/she should complete whatever is being done for that patient and sign off before proceeding to the next patient. This view supports the role of care provider as a clinician.
Review of Existing Results
It is good practice to review existing results before or 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 identifiable 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 views are purposely designed to support clinicians in performing their work (as opposed to queries for statistical purposes).
Views of Results and Access to Applications Immediately After Reception/Triage
Views 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.
- Initial Clinical data gathering (interviewing, eliciting symptoms and signs)
- Formulating diagnosis
- Planning care
- Further data gathering (clinical tests, ordering investigations)
- Reporting of Incidents
- Progress review
- Assessment of Outcome
- 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:
- the date and time of data entry
- the name of the task or event
- the location where the task or event took place
- 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.
Context of Data Entry in Relation to a Typical Task
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 on 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 shoukd 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.:
- Use of Data entry forms with predetermined structure and content (structured data)
- Use of Data entry forms that allow users to document data in their own words (free text)
- Direct charting into Charts
- Direct Acquisition From Machines and Devices through machine-system interfaces
- Read from bar-code labels using bar code readers (for identification data and instructions)
- Direct capture of images from image producing machines interfaced to the network (X-rays, ultrasounds, ECG tracings, Cardiotocographs etc.)
- Acquisition of scanned of images of hard copy documents (e.g. referral letters, printed results etc.)
- Data converted from sound using voice recognition systems
- Copy and pasting of existing data on display to a data entry form.
These results could be presented as:
- numeric values (cardinal, ordinal)
- structured words (alpha, alphanumeric)
- free text (string)
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, comprehendibility and usability of the CIS.
Most clinical data collection tools will have the same structure and content with some parts being variable. These include:
- Initial Data Gathering Forms (Clerking, Assessment, Eliciting symptoms and signs)
- Progress notes
- Care Plans
- Procedure Record
- Outcome documentation (severity grading, scoring etc.)
For some purposes, standard forms should be used across all specialties and departments e.g.:
- Certain mandatory or common assessments, e.g. Activities of Daily Living (ADL), ASA Score, GCS Score etc.
- Drug History
- Social history
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 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 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.
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:
- Images or pictures pre-supplied as part of forms, notations on (using the mouse)
- Clinicians may draw free-hand on drawing tablets and images are captured directly from the device.
- 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:
- Fresh case (at their first encounter at primary care setting or walk in patients)
- 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 as a Trigger for Care Plans
The data gathered from the interview is used for purposes of:
- Formulating an early diagnosis
- 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
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:
- Data collected by clinicians in the course of performing tasks and from observations made
- 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:
- What processes has been done for this patient?
- What results are available?
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:
- with outpatient visits only (day care being treated as outpatient)
- with in-patient visit only
- 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.
Content and Arrangement of Views
For each view, multiple recurring data need to be sequenced in chronological order.
- Sectional view
- Visit-Encounter view
- Structured text
- Charts and tables
- The White board
- Clinical support information to facilitate tasks of a care provider
- Problem oriented mix of data
- Case history (Visit/Encounter Summary)
- Case summary
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.
View of Clinical (EMR) Data
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.
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
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:
- 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
- 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
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:
- Patient types
- Users categories (user access privilege)
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:
- New vs follow up or referral case
- Acute vs chronic illness
- Surgical / medical / psychiatric / traumatic
- Purpose of visit
- 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:
- Cases Referred from specialist or specialty unit to another
- Cases transferred from one service delivery system to another (from outpatient service to inpatient service and vice versa
- 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:
- The current working diagnosis
- Prior Visits and encounters for the same disease episode
- Previous results for the same disease episode
- 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:
- The patient’s health status
- Progress of the illness including effect of treatment on the illness
- 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:
- Regular review or observation of symptoms and signs
- Repeated measurement and charting of physiological parameters either continuously or at regular intervals
- Serial measurement of biochemical parameters
- Repeated of Microbiological and Hematological tests
- Follow-up Imaging studies
- 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:
- 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
- Use of machine-system interface to transfer result values directly from measuring devices to the monitoring application software
- 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:
- Indicate the baseline
- Show all serial measurements made
- 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.
- Analyse and interpret the changes based on normal or expected values
- Comments to be made by especially value judgment by care providers on whether there is improvement, deterioration or absence of change
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:
- Progress of the illness naturally or as result of treatment
- The health status of the patients (physiological, biochemical and psycho-social)
- 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:
- Reduction of symptoms and signs,
- Return to normal of physiological, biochemical, morphologic parameters
- Psycho-social well being
- Recovery of function of the part involved
- 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 customised to the particular patient’s disease variation.
Overall progress may be assessed and documented at
- pre-determined intervals during the visit
- on discharge
- at a follow up visit
- before termination of a care episode
The possible conclusions include:
- status unchanged
- deteriorated, worsened
- in remission, inactive
- 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:
- Deviation from normal status
- 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:
- Onset and duration of illness (whether acute, sub-acute or chronic)
- Anatomical site involved (for diseases which may affect different sites)
- Morphology and Aetiology (cause) including pre-morbid factors
- Sub-categories based on age, aetiological agents or other factors
- Stage and Severity of illness,
- 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:
- Active vs. Inactive Status
- Accuracy or confidence level (Provisional or Definitive)
- elative importance
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:
- Reason for Visit
- Nursing Diagnosis
- Disability Diagnosis
- Post-investigative diagnosis (imaging, biochemical, microbiological, histo-pathological etc.)
- Clinical Diagnosis
- 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:
- First visit
- Walk in visit
- 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
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.
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
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.
- Anatomical site and side
- Clinical instance (the context when the diagnosis is made)
- New or recurrence (exacerbation, relapse)
- Levels of severity
- Levels of accuracy
- Sub-categories such as morphology, aetiology and variants
- Causes Priority or relative importance
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
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:
- Current Illness
- Primary Illness
- Concurrent Illness
- Concurrent Illnes 1
- Concurrent Illness n
- 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:
- Initial Diagnosis
- Post Investigative Diagnosis
- Working Diagnosis
- Presumptive Diagnosis
- Final Diagnosis
Instances of Making a Diagnosis during Different Phases of Care
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
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.
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.
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.
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 :
- Provisional diagnosis
- for instances such as the interim, working and presumptive diagnosis
- 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:
- Trauma including accidents and assaults
- Physical agents
- Chemical agents
- 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
- Reason for Visit
- Nursing Diagnosis
- Disability Diagnosis
- Clinical Diagnosis
- 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:
- Initial Diagnosis
- Working Diagnosis
- Presumptive Diagnosis
- Post-investigative (radiological, biochemical, immunological, cytological, microbiological, histo-pathological etc.)
- Postoperative Diagnosis
- 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
- Data field containing structured text
- 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:
- All entries, sequenced according to date of entry of diagnosis data
- Valid entries only
- 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
From a clinical perspective, death is an event and should be recorded as such. It means capturing data regarding
- the time of occurrence,
- the location,
- the persons who witnessed the event and
- what actually happened prior to the event that has not been recorded earlier
- attempts made to avert the event (resuscitation)
- the physiological dysfunction that caused cessation of life
- 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
The CIS should provide the facility to document and display data regarding allergies using same data field to cater for the following instances:
- Documenting history of allergy
- Documenting occurrence of an allergy
- Displaying allergy data in patient profile
- Displaying allergy data in Case summaries
- Displaying allergy data as Decision support data
- 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:
- Drugs and chemicals
- 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.