The Tuberculosis Patient Management Project convened internal and external stakeholders, from CDC, the National TB Controllers Association, other national public health organizations, and state and local tuberculosis (TB) programs, in a series of Joint Analysis and Design (JAD) sessions to define and document the data elements and functional requirements for the Patient Management project, which meets the core needs of the stakeholders. The result of this effort is a collection of artifacts describing the business processes (use case model) and supplementary (technical and architecture) requirements based on input provided by state and local stakeholders. These documents can be used to design a system and develop custom software, or alternatively as the evaluation framework for selection of a compatible off-the-shelf product. These use cases were used to develop specific requirements which are used in the Decision Model Tool.

What's a Use Case?

In order to know what application will best meet your needs, it is necessary to first specify the requirements for the application. One commonly accepted way to document these requirements is the Use Case approach. Use cases are used during requirements analysis to identify, clarify, and organize requirements. A use case is made up of a set of possible sequences of interactions between the application and users in a particular environment and related to a particular goal. Specifically, a use case is a single task, performed by the end user of a system that has some useful outcome. The use case should contain all system activities that are of significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal; the use case and goal are sometimes considered to be synonymous. A use case is written in a way that both non-technical and technical audiences can understand. The use case focuses on what things the users have to do to solve the problem. Inside the use case we define the purpose of the activity, the actors involved (end users, systems, etc.), the actions and responses, and the end result.

Each use case can be thought of as answering a question. For example, "How do I get money out of the ATM?" or "How do I add a new person to the Patient Management software system?" In these scenarios, there is a primary actor (the ATM customer; the registration clerk) who has a goal (withdraw money out of his/her bank account; enter a new person into the system). There are a variety of situations that could occur during these activities - the use case collects them into one place. It breaks down your goal into sub-goals, plus the interactions between various actors as they try to reach that goal, or fail to reach it, and the system responses to the user's actions. Scenarios and use cases go until goal success or abandonment.

The following table compares the ATM to the Add Person Record examples mentioned above side-by-side to provide a visual comparison and to aid with your understanding of a use case.

ATM Example	Add Person Record Example
Goal: to withdraw cash from the ATM machine	Goal: to add a new person record to the Master Person Index (MPI)
Pre-condition: the customer has already successfully logged onto the ATM machine (using a valid bank card and PIN combination).	Pre-conditions: the registration clerk has successfully signed onto the application and the new person to be added doesn't already exist.
Step 1 - The customer chooses cash withdraw option from the menu of possible transaction types.	Step 1 - User selects register option from the menu of possible transaction types.
Step 2 - The customer chooses a type of account to withdraw from (e.g., checking) from a menu of possible accounts, and then chooses a dollar amount from a menu of possible amounts.	Step 2 - System displays the register screen and the clerk enters basic patient information in the register screen.
Step 3 - The system verifies that it has sufficient money on hand to satisfy the request. If not, it reports a failure to the session, which initiates the Failed Transaction Extension to report the problem.	Step 3 - The clerk enters the reason for adding the person to the MPI.
Step 4 - If there is sufficient cash, it sends the customer's card number, PIN, chosen account and amount to the bank, which either approves or disapproves the transaction.	Step 4 - If the person resides outside the health department's jurisdiction, then the Notify Appropriate Health Department extension is initiated.
Step 5 - If the transaction is approved, the machine dispenses the correct amount of cash and issues a receipt (skip to step 7).	Step 5 - The clerk selects the save option.
Step 6 - If the transaction is disapproved due to an incorrect PIN, the Incorrect PIN extension is executed. All other disapprovals are reported to the session, which initiates the Failed Transaction Extension.	Step 6 - The system saves the new person registration in the MPI.
Step 7 - The bank is notified whether or not an approved transaction was completed in its entirety by the ATM machine; if it is completed then the bank completes debiting the customer's account for the amount. The Use Case ends.

Use Case Example - Add a person record

The following is an example of a Use Case specification. It shows the details behind the use case: "Add a person record" illustrated above. It contains the main sections that would be documented in the use case including the main section of the use case showing the main flow and possible alternate flow(s) for the use case.

Purpose: This business use case will allow a user to add a "person record" to the Master Person Index (MPI).

Background: The person can identified to the health department from various sources including self-referral, a referral from a medical provider, a contact investigation, targeted testing, etc. The person may need treatment, be part of a targeted testing, be part of a contact investigation, etc. Actors: (People or systems that will interact)

• Health Care Worker (HCW)
• Health Department Staff
• Software System

• The user must have proper security rights to enter a patient in the system.
• System is available and operable
• The user is notified that a person requires TB services and the person satisfies jurisdiction criteria for assessment and/or treatment.
• The person requires TB assessment and/or treatment needs to be added into the MPI.
• The person with special needs is provided assistance that may include translation services, transportation, etc.

• The MPI search does not retrieve a person record that matches the search criteria and the person must added to the MPI.

1. User selects register option
2. System displays register screen
   • 3.1: User enters basic patient information in the register screen. Basic information may include last name, first name, sex, date of birth, address, and if a translator is needed.
3. User enters the reason for adding the person to the MPI which may have the following values: suspect case, confirmed case, contact investigation, targeted testing, etc.
4. User selects the save option
5. System saves registration in the MPI
6. End Use Case

• The original health department sends a notification (via secure e-mail, phone call, fax, or mail) to the appropriate health department. From Step 3.1:
  • User enters associated system identifiers
  • System links patient with other system identifiers as described in UC.110.MPI Search
  • Use case resumes at step 5
  • Use case ends

Additional Links

back to Top

Core Functional Requirements (Business Processes)

Business processes for the application, which are represented as business use cases, have been organized into the following four groups:

Enrollment and Registration Use Cases
Care Management Cycle Use Cases
Contact Tracing Use Cases
Management and Global Use Cases

Before any electronic PM process can be performed, tracked, or recorded, the patient must exist on the system. The Master Person Index (MPI) is queried to locate the patientís electronic records. The query may include a combination of last name, first name, date of birth, social security number (SSN), or medical record number. After the patientís record is located, that record is updated (e.g., demographic, billing), consents recorded, appointments booked, etc.  If the patientís record is not located, the patient is "Registered" in the MPI and other values are added (e.g., demographic, billing). Business use cases are defined below.

MPI Search - allows a user to search and locate the record of a person in the MPI so that the correct person is identified before performing enrollment, assessment, contact investigation, monitoring, and treatment processes.

Register - allows a user to add a "person record" to the MPI.  The person can be identified to the health department from various sources including self-referral, referral from a medical provider, contact investigation, or targeted testing. The person may need treatment, be part of a targeted testing, or be part of a contact investigation.

Demographics - allows a user to record demographic information in the system. Demographics are person-centric information used to identify, analyze, and categorize. Demographic information usually does not change and can include last name, first name, middle name, sex, date of birth, place of birth, race, ethnicity, language, SSN, medical record number, state drivers license number, Medicaid number, Medicare number, state case number, county case number, bi-national card number, family identification number, etc. Demographic information that may change can include home address, work address, census track, insurance, geographic information services (GIS), or special care comments.

Consent - allows a user to provide evidence that "consents" have been requested and that the patient has given or refused consent. A patient is asked to consent to protocols and procedures that may include permission to receive medical treatment, release medical information, release  information based on Health Insurance Portability and Accountability Act (HIPAA) regulations, comply with TB quarantine policies, submit to HIV testing, submit to other testing or fulfill other actions necessary for a successful treatment outcome.

Billing - allows a user to gather billing information so that appropriate TB-related services can be billed and reimbursed. Depending on jurisdictional regulations, all or part of TB services may not be entirely un-billable to any agency, insurance company, or other third-party.

Schedule Appointment - allows a user to schedule an appointment for a patient to be seen for a variety of clinical functions. After a clinical order is issued (e.g., to gather a sputum, dispense medication, arrange a home visit, take a chest x-ray, perform clinical assessment, schedule Directly Observed Therapy [DOT]), an appointment is scheduled to define a date, time, location, and resource to have the order carried out. The appointment scheduling functions include rescheduling missed appointments, scheduling recurring appointments, and generating alerts, appointment rosters, or reminder notices/mailers. [Note: Orders are entered to record the instructions of the physician to perform assessments, treatments, and/or monitoring activities. An appointment is scheduled to provide a place, time, date, and resource to have the order performed.]

Transfer Record - allows a user to transfer a clientís records from one local health department to another within the same state jurisdiction.

back to Enrollment and Registration Use Cases

Care Management Cycle Use Cases: Evaluate, Treat, and Monitor.

In general, the patient care life-cycle includes (1) a patient assessment based on available information, (2) initiating the treatment regimen, and (3) monitoring response to treatment. Response to treatment may trigger a reassessment and re-definition of the treatment plan.

After the patientís electronic record is located in the MPI, the process of electronically gathering clinical information begins. Although existing medical records may have been requested during Enrollment, the clinical assessment processes begin with a Clinical Evaluation. This evaluation may include the review of any available patient clinical information including medical records, additional history and physical findings, observation of patient symptoms, non-medical record clinical information provided by the referring provider, medication records, etc. A risk assessment is initiated to gather social factors, housing arrangements, or other medical conditions. Other "assessment" information also may be gathered and used to define the treatment plan. Based on the information available, the patient is classified and prioritized.

If indicated, a treatment plan is defined (based on a predetermined treatment protocol, standing order, etc.) and treatment begins. Protocols are pre-authorized physician orders for lab orders, x-ray orders, medications, DOT schedules, follow-up visits, etc.  The assessment and treatment plan may be modified based on additional criteria (e.g., clinical factors, social risk factors). 

Assessments and treatment plan reviews can be triggered as time passes, risk factors change, treatment plans are completed, the results of tests are evaluated, and/or critical clinical indicators trigger a review. The treatment plan is performed until the next assessment is triggered.

Collect History - allows the user to collect and record historical information for a patient or for the patientís immediate family. The process of collecting history can include identifying sources for patient history, asking for history from sources using a patient-signed "Release of Medical History" request (if needed), receiving history from sources, recording history in the system, and generating a "Prior History" report.  The history may be provided during a patient interview or from provider-supplied medical records. The clinical assessment data may include medication history, medical records, laboratory results, pending orders, previous TB treatment history, medication allergies, medication resistance, TB treatment compliance records and other information used by the clinician to define a care plan.

Risk Assessment - allows the user to perform a risk assessment of a patient based on some of the following issues: medical, socio-economic, transmission/exposure, treatment barriers, etc. Specific factors evaluated include risk factors for TB exposure and/or infection (correctional facility resident, long-term care resident, injected drug use, non-injected drug use, alcohol use, occupation, previous TB diagnosis, foreign birth, immigrant status), and risk factors for progression from latent TB infection to active TB (e.g., HIV status, diabetes, chronic renal failure). Other risk factors include allergies, adverse reactions to medications, and drug susceptibilities.

Resolve Barriers - allows a user to document the resolution of a barrier that could prevent patient treatment. "Enablers" linked to patient need are used to resolve treatment barriers. These enablers may include vouchers, food, housing, taxi fare, food coupons (provided at check-out), bus tokens (provided at check-out), home vouchers, food bank, etc. An outreach worker may be assigned to encourage compliance with DOT.

Track Enablers - allows a user to "track" and replenish the "Enablers" provided to patients. Enablers may include vouchers, food, housing, taxi fare, food coupons (provided at check-out), bus tokens (provided at check-out), home vouchers, food bank, updating community resource lists for coordinating services, etc.

Legal Action - allows a user to gather documentation and initiate legal proceedings for a patient who does not adhere to treatment regimens and/or quarantine protocols.

Close Case - allows a user to close a TB case based on protocol.

Classify - allows a user to gather information about a person and to classify that person based on results of the assessment, treatment and/or monitoring processes. As additional information (e.g., smear results, culture results, chest x-ray results, risk behaviors) is gathered for the person, classifications can be changed. Classifications/reclassifications are assigned based on a combination of assessment, medical presumptive, definitive diagnosis, etc.

A patient can be classified based on a variety of criteria, such as local jurisdiction standards, state jurisdiction standards, CDC reporting standards, diagnostic standards. An example of American Thoracic Society diagnostic standards classifications include:

Class 0 - No tuberculosis exposure, not infected
Class 1 - Tuberculosis exposure, no evidence of infection
Class 2 - Latent tuberculosis infection, no disease
Class 3 - Tuberculosis, clinically active
Class 4 - Tuberculosis: not clinically active
Class 5 - Tuberculosis suspect (diagnosis pending)

Define Care Plan - allows a user to associate "Services and Tasks" with a "start date" to construct a "Care Plan" based on the individual patientís needs. The Services and Tasks are future actions to perform (sometimes based on protocol or standing-order) including assessment, treatment, and/or monitoring activities. Examples of actions include monitoring adherence, home visits, clinic visits, follow-up visits, chest x-ray, skin test, specimen, document response to treatment. A "Care Plan" usually includes the protocols for orders, results, clinical interventions, medications, and evaluations required to achieve a successful outcome for patient treatment. Care plans can be defined by manually selecting each "service and task" or by selecting a template of pre-defined "services and tasks."

Assign Care Team - allows a user to assign resources (e.g., single person or some combination of health care workers) to "care" for the patient. Team members may include case workers, nurses, social workers, physicians, disease investigation specialists, or field staff. Jurisdictions use a variety of "titles" for members of the "care team." Typically, a user is assigned primary responsibility of coordinating care for the patient with a larger "care team" providing support and resources.

Write Orders - allows the user to "write" assessment, treatment, and/or monitoring orders (actions) for patient care. Those orders may include laboratory tests (e.g., smear, culture, liver function, susceptibilities), x-ray studies, medications, counseling, follow-up schedules, and DOT. Orders can be written, verbal, or otherwise communicated. The user "writing" the order (providing the directive) is identified by statute and is usually the physician or a health care worker under a physicianís direction. Some jurisdictions have developed "pre-written" orders called protocols or "standing orders." A protocol is written when a standard care plan can be appropriately "reused" to treat other patients with substantially similar clinical profiles. These protocols are the pre-written orders (directives) from an authorized health care provider (the physician) and define a standard care plan. When the clinical profile of the patient needing treatment matches the clinical profile used to define the protocol, that protocol is pre-authorized to be used as the care plan.

Dispense Meds - allows a user to view medication history and medication orders, dispense medication, and record medication dispensed in the patient record. This use case also includes the process of decrementing medication inventory and creating a restocking request.

Orders & Tests - allows the user to record (or enter) "orders" into the system based on the directives and instructions of a physician or other appropriate health care provider. The physician is responsible for defining and authorizing "orders" included in the patientís "care plan." The physician can authorize the orders before, during, or after the order is executed. The "care plan" can be defined with protocols (physician pre-approved "standing orders") or can be specifically tailored. Orders can include laboratory tests (e.g., smear, culture, liver function, susceptibilities), x-ray studies, medications, counseling, follow-up schedules, and DOT. These physician-approved directives and orders are recorded in the system to become the "care plan."  After the "care plan" is recorded in the system, the health care worker is provided with a listing of orders and a suggested execution timetable. When the order is due to be executed, the health care worker will activate the order and execute the physicianís instructions.

Collect Specimen/Source - allows a user to collect a specimen for a lab test.

Evaluate Results - allows a user to record and evaluate test results. Jurisdictions may have standard treatment protocols or "standing orders" defining the frequency that tests are to be performed. Some tests are "ordered" to be repeated 3 to 5 times each week (sputum smears and cultures). Other tests can be scheduled monthly (e.g., chest x-ray, susceptibilities). Ordered tests can include mycobacteriology (e.g., smear, culture), medication susceptibility, chemistry (e.g., liver function tests), x-rays studies (typically chest x-ray), and toxicology (adverse effects of medication). When a test has been performed and completed, a "result" is provided. Sample result information can include the following: sputum smear is positive for TB, sputum culture has 4+ colonies, chest x-ray is abnormal and cavitary indicative of TB, liver function test is elevated. The evaluation of the test result (positive or negative) may trigger a change to the care plan (e.g., if a susceptibility test indicates that the patient is resistant to an antibiotic, the health care worker evaluates the result and determines that the medication should be replaced with other medications).

Manage Care - allows a user to record the completion status of care plan tasks.  Care plan tasks include protocols and standing orders to be executed to treat the patient, resulting in a successful outcome (patient cured of TB). Tasks are the activities required for a successful outcome and can include medication administration, education, DOT, specimen collection, follow-up visits, home visits, clinical assessments, risk assessments, and completion of chest x-ray. The completion status assigned can include "missed appointment," "not completed," "medication administration observed," "lab test ordered," and "positive lab results."

back to Care Management Cycle Use Cases

Contact Tracing Use Cases

A "potential contact" is a person who has been in close physical proximity to a TB patient. Contact Investigation (or Contact Tracing) includes those activities designed to identify, prioritize, locate, and examine potential contacts. Based on the evaluation, the staff will determine which individuals have had sufficient exposure to be considered contacts and thereby warrant testing, evaluation, and/or treatment. Each TB patient may have been in contact with hundreds of persons. If the results of the TB assessment indicate that the contact should be treated for TB, a treatment plan is defined and treatment begins (see the Assessment, Treatment, and Monitor processes above).

Interview for Source - allows a user to identify an M. tuberculosis transmission index/source case. The purpose of this use case is to answer the question, "Who did the infected patient get TB from?" A list of "sources of exposure" is created that may include social settings, work environment, family surroundings, and places frequented.

Identify Potentially Exposed Contacts - allows a user to identify "potentially exposed contact" persons to associate with each "source of exposure."  The purpose of this use case is to answer the question, "Who did the infected patient (or source) expose to TB?" Detailed information is gathered for each potentially exposed contact that may have been infected by the patient.

Prioritize Potentially Exposed Contacts - allows a user to prioritize the list of "potentially exposed contacts." Priority is assigned based on TB patient characteristics, nature of exposure, contact person's characteristics, infection risk factors, social assessment, and environmental assessment.

Locate Potentially Exposed Contact - allows a user to locate a potentially exposed contact.

Evaluate/Monitor the Potentially Exposed Contact - allows a user to evaluate the "potentially exposed contact."  The evaluation of the "potentially exposed contact" can include a TB skin test, chest x-ray, mycobacterial lab tests, review of medical history, risk factor assessment, blood work (e.g., liver function tests), and social assessment.

Identify Links Relationships - describes the processes used to link TB patients with epidemiologic information, DNA genotyping information, or both.

back to Contact Tracing Use Cases

Management and Global Use Cases.

System use cases include processes not directly associated with any patient-related functions, including security, user maintenance, template maintenance, performance reporting, quality reviews, scheduled reports, data backup, general reports, and merging duplicate patient records. Based on high-probability of exposure, regulation, or clinical indication, entire populations can be targeted for TB testing.  Examples of populations targeted for TB testing include health care, school, and food service workers. Persons who are included in a population are identified and evaluated with a TB Skin Test (TST). Additional testing may be performed. If the results of the Targeted Testing (TT) assessment indicate that a population member should be treated for Latent TB Infection (LTBI), a treatment plan is defined and treatment begins (see the Care Management Cycle use cases above).

Create Care Note - allows a user to add "Care Notes" commentary to the patient record.  These Care Notes can include explanations, observations, interpretations, clarifications, narratives, "Progress Notes," "Nurseís Notes," remarks used for legal action, or impressions. The ability to add commentary may be desirable or required in any module of the PM system. Care Notes may include commentary to describe the patientís improvement (or deterioration) and prognosis.

Merge-Purge -allows a user to merge duplicate person records and designate a primary person record in the MPI. A person record is selected to be the primary record that the duplicate records are merged into. When the records are merged, the non-demographic information from the duplicate recorded is copied and pasted to the primary person record. The duplicate record is flagged as a duplicate so that when the duplicate Medical Record Number is used to search the MPI, the search points from the duplicate record to the primary person record. The duplicate person record is not deleted or purged but retained for history. When Electronic Lab Results are returned to the duplicate person record, those results are automatically linked to the primary person record. The MPI search will retrieve merged person records along with the primary person.

Duplicate records are created when the demographic information required to locate the person in the MPI is not available. Searching the MPI usually includes looking for person records based on last name, first name, sex, date of birth, or SSN. Other values can be used to enhance a search of the MPI. When the demographic information is insufficient, the user enrolling/registering the person will add a new person record. Duplicate person records are also created because of name changes (marriage, divorce, adoption) and change to SSN (e.g., identity theft).

Generate Report - allows a user (with proper security rights) to generate, view, print, and export reports. Some reports may have the ability to be configured while others do not.

Create Template - allows a user to create a care plan template. This template may include the orders, tests, and other clinical directives with suggested execution intervals. For example, a template might include an order to perform a sputum smear and culture lab test every other day for 3 weeks. When a template is used to define a care plan, the user will select the patient, a template and a start date to create a care plan. Templates are used to create reusable care plans based on protocols or "standing orders."

QA Staff Performance - allows a user to conduct quality-of-care activities for staff performance.

QA Treatment - allows a user to conduct quality-of-care checks for TB treatment.

Targeted Testing - allows a user to record and track populations selected for TT. Test populations can be tracked at the aggregate level by recording the location, number of TST administered and the results after the TST is read.  If required by the Public Health Department, abbreviated demographic information can be collected on each person subject to the TT.  This abbreviated demographic information (along with the reading of the TST) is entered into the system and aggregate-level totals are generated by counting the population subject to the TT.

back to Management and Global Use Cases

Technical and Architectural Requirements

This section includes the non-functional requirements for the applications, sometimes known as supplementary requirements or technical and architectural requirements. These formed the basis for the first-tier assessment where applications were rated purely on technical merit and not on functionality.

Technical and architectural requirements have been organized into the following groups:

• Basic Technical Requirements
• Architectural Requirements
• Management Requirements

Basic Technical Requirements.

Basic technical requirements, briefly described below, include usability, installation and upgrade, and security as well as other criteria such as supportability. Please refer to the Decision Model Tool for more information.

Usability - defines the various criteria that make an application easy to use and usable, including user-friendliness, simplicity and intuitiveness, expert consultantsí availability, customizable notification mechanisms, customizable screens, menus and lists. Other criteria include quality of the documentation, including technical documentation, as well as user manuals and self-help.

Installation and Upgrade - defines the various criteria that make an application easy to install and upgrade, including ease of installation (installation steps and customization steps) and availability of consulting expertise for making changes and enhancements.

Security - defines the various criteria that make an application secure, including access control and data security.

Architectural Requirements.

Architectural requirements include operating systems supported (e.g., Unix^®, Microsoft Windows^®), web-enabled, database supported, etc. These also define whether the application is scalable and can be used in either large or small jurisdictions. Please refer to the Decision Model Tool for more information.

Management Requirements.

Management requirements, briefly described below, include product maturity, vendor viability, cost, and training. Please refer to the Decision Model Tool for more information.

Product maturity - defines the various criteria used to evaluate how mature a product is, including vendor commitment to the product (e.g., length of time the product has been available commercially, is this their main business or a side business?), versions (e.g., has more than one version been in use so bugs have been worked out?), availability of users group or a forum (e.g., are users groups or forum available for gathering data, information, and answers to questions?), and availability of site licensing.

Vendor viability - defines the various criteria to evaluate vendor viability, including vendor maturity (e.g., how long, in years, have they been in business?), technical support (e.g., availability of technical support expertise, responsiveness in answering questions and dealing with technical issues and problems), warranty (e.g., kind of written warranty provided, do they stand behind their product?), evaluation copy (e.g., is the vendor willing to provide evaluation copies and support during the evaluation period?), U.S. representation (e.g., do they have offices in the United States, and if so how many and where are they located?).

Cost - defines the various criteria to evaluate the overall cost of the application, including product costs, support and maintenance costs, and training costs.

Training - defines the various criteria to evaluate the availability and quality of training, including learning curve, availability of user training, recommended user training, availability of administration training, and recommended administration training.

back to Technical and Architectural Requirements