Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Local Health Department Surveillance Business Process Workflows and by yzc11728

VIEWS: 6 PAGES: 46

									Local Health Department Surveillance
  Business Process Workflows and
           Requirements
               for the
            Kansas EDSS
                   October 2006




     Kansas Association of Local Health Departments
            300 SW 8th Avenue, Third Floor
                Topeka, Kansas 66603
                     (785) 271-8391
                    www.kalhd.org
                                     TABLE OF CONTENTS



Project Description .............................................................................................1
Local Health Department Needs Summary.......................................................2
Appendix A: Disease Investigation Workflow ..................................................1
Appendix B: KALHD Input to EDSS Requirements..........................................1
Appendix C: KALHD/EDSS Requirements Table Cross Reference to
LHD/OM/CRA .......................................................................................................1




KALHD-LHD Input to EDSS                                 ii
Project Description

The selection of a new Electronic Disease Surveillance System (EDSS) for
Kansas initiated a project to analyze and document local public health
department disease surveillance workflows. This project used a collaborative
business process analysis to identify requirements for the EDSS that will support
the work of local health departments. Staff members from local health
departments and KDHE convened to identify local requirements for the new
EDSS system. This work resulted in a documented set of requirements for Local
Health department surveillance needs that will be presented during the EDSS
Joint Application Development (JAD) sessions.

To understand the preparations that local health departments undertook to
provide input into the JAD sessions with KDHE’s EDSS vendor, it’s helpful to
understand information technology background in local health departments.

A Local Technology Utilization Plan (LTUP) was adopted by the Kansas
Association of Local Health Departments (KALHD) Board of Directors in July
2006. It represents the local component of a Public Health IT strategic plan that
addresses information technology system design with the following statement:

        Priority #4
        The Public Health Informatics Stakeholders Team (PHIST) should ensure
        that the public health systems implemented in Kansas are driven by a
        priority to align the technology with the work of local health departments,
        by ensuring that work flow analysis is an initial activity of any Kansas
        public health Information Technology project.

Another important factor for consideration of EDSS design priorities is the grant
deliverables associated with the funding of the EDSS project. The Kansas work
plan for the second year of the Pandemic Influenza Grant identified $240,000 to
be directed towards the development of the new surveillance system. These
funds are to address the investigation and containment of an outbreak (e.g.,
pandemic influenza) or public health emergency in compliance with PHIN
Preparedness Functional Area Outbreak Management. Outbreak management
(OM) and Countermeasure Response Administration (CRA) requirements were
also included for consideration in this project. Some of the CRA requirements for
administration of mass prophylaxis may be met within the Kansas Immunization
Registry.


Below is a summary of local health department needs/requests for Kansas’ new
EDSS system:




KALHD-LHD Input to EDSS                   1
Local Health Department Needs Summary


    1. We request tight integration of local business practices with EDSS. The
       value of an information system is directly linked with how well the system
       aligns with business practices. To that end, the following steps have been
       taken:
           a. Standardization of Local Disease Investigation Protocols
              In 2004, KALHD implemented a project to standardize the protocols
              for local disease investigation. After developing common business
              practices, regional trainings were offered for local public health
              workforce on how to implement the investigation protocols. We
              request that the EDSS development take advantage of this
              standardization of local disease investigation practices and align
              the supporting information system with the local disease
              investigation protocols.
           b. A generic workflow that summarizes the local disease investigation
              protocols has been reviewed through a workshop conducted to
              gather local input for the EDSS development team.               This
              information is being provided as an attachment to this document.
           c. We extend the offer to work with the project team throughout the
              development of the EDSS system to ensure that the final system
              design fully integrates with standardized local disease investigation
              protocols.

    2. We request that the system development priorities be closely coordinated
       with the federal funding guidance. We call particular attention to the PHIN
       Functionality Standards for Outbreak Management and Countermeasure
       Response Administration.
           a. This coming year, $240,000 of the Kansas Pandemic Influenza
              grant is directed towards the Communications Target Capability
              Critical Task #3.
                          “Have or have access to interoperable information
                          systems to capture and manage data associated
                          with the investigation and containment of an
                          outbreak (e.g., pandemic influenza) or public
                          health emergency in compliance with PHIN
                          Preparedness     Functional    Area     Outbreak
                          Management.”
            b. The grant guidance for PHEP contains Item 6d. Target Capability:
               Isolation & Quarantine. Critical Task #8 of that item states:
                       “Have or have access to information systems to
                       collect, manage, and coordinate information
                       about isolation and quarantine, compliant with
                       PHIN      Preparedness        Functional      Area
                       Countermeasure and Response Administration.”


KALHD-LHD Input to EDSS                      2
            c. The attached document “KALHD Input to EDSS Requirements
               Table” provides a matrix of OM and CRA Functional requirements
               and the items contained in the initial proposal. We understand the
               CRA requirements related to Mass Prophylaxis will be handled
               through the Kansas Immunization Registry. The Q & I component
               of the CRA Functional Requirements is to be developed within the
               EDSS design.

    3. We request that EDSS have an HL7 interface to link with local clinic
       management systems. In Kansas there are two such systems, QS and
       KIPHS.     Both systems are currently being linked to the Kansas
       Immunization Registry through a two-way HL7 PHIN compliant interface.
       We note Section 2.5.2 of the OM Functional Requirements:
          “Systems supporting OM must be able to accept data from other
          partner systems supporting OM.”

         Many outbreaks start out as single cases with the first encounter entered
        into the clinic management system. Having a two-way interface between
        the clinic management system and EDSS will help to avoid dual entry at
        the local level.

    4. We request that privacy and confidentiality be addressed in the initial
       stages of the development of the project bringing stakeholders to the table
       to work through these important issues through a collaborative process.

    5. We request that performance management measures be incorporated into
       the design of the project. Some of these performance measures have
       already been specified by CDC.
           a. The measures noted in the funding guidance include:
                 Measures:
                    • Percent of HRSA participating hospitals that transmit
                        clinical and/or hospital utilization data in near real-time to
                        a PHIN-compliant early-event detection information
                        system
                    • Time to have a knowledgeable public health professional
                        respond 24/7 to a call about an event that may be of
                        urgent public health consequence
                    • Time to initiate an epidemiologic investigation of an event
                        that may be of urgent public health consequence
           b. This next year KALHD is working with NACCHO as a pilot site for
              the operational definition of local public health department. We will
              be looking at performance metrics associated with these standards
              and request that these metrics be considered in the design of the
              system output.

The Appendices attached provide specific and detailed workflow analyses and
requirements for disease surveillance in local health departments.

KALHD-LHD Input to EDSS                   3
Appendix A: Disease Investigation Workflow

Introduction:
On October 3, 2006 the Kansas Association of Local Health Departments
sponsored a workgroup meeting to discuss the needs of local health departments
in relation to the new Disease Surveillance System (DSS) being purchased by
the State of Kansas. A “generic” workflow for disease investigations was used to
help explore the work tasks and DSS support needs that will be used by local
investigators. This document contains the revised workflow based upon the
findings of the workgroup.

Workflow Discussion:
A short task description followed by the input, process and output associated with
each task in the workflow is presented. In addition, since many of the individual
tasks may be associated with an outbreak – or the management of an outbreak –
these tasks are identified as such and an additional description of the outbreak
task is presented. Finally, the requirements identified by KDHE in the original
RFP are overlaid upon the workflow.

Workflow Description:
Each task within the workflow has been identified with a corresponding number
or letter that is used to link the text description with its section of the workflow;
tasks identified with a letter are tasks that may be used more than one time in the
workflow. Tasks that are colored grey have the potential to be supported by an
electronic system. It should also be noted that same tasks are grouped together
as their functionalities are interrelated, these task groupings are indicated by a
dashed line.

NOTE: A cross-reference table between the workflow tasks and the KDHE EDSS
Functional Requirements document is attached at the end of the workflow
discussion.




KALHD-LHD Input to EDSS             Appendix A                                  A-1
KALHD-LHD Input to EDSS   Appendix A   A-2
(1) Open Case and Assign Investigator
Task Description: Once the minimum data set associated with a case has been
entered by either local and/or state epidemiologists the report becomes a work
order awaiting assignment to an investigator.
Input: Notification from KDHE via phone, fax, email, DSS (daily login required).
Process: Routine investigation assignment will occur within the DSS from the
investigation assignment screen. Since each health department has their own
unique business practice’s the system should allow assignment to occur using
three different methods, they are:
        a. Investigator “self” assigns work
        b. Supervisor assigns work
        c. Both the inspector and supervisor assign work.
A series of standard reports that documents all stages of the work assignment
and investigation status will need to be constructed into the system to assist with
management oversight, assure balanced caseload and assure the completion of
all investigations in a timely manner.
Output: Open case record with an assigned investigator
Outbreak Management Functions: The ability to notify an investigator that a
case may be associated (linked) with an outbreak should be considered.

(2) Assigned Investigator Reviews Case Record / (2a) Preliminary
Investigation
Task Description: Once a work order has been assigned to a specific
investigator it is then moved to the investigators own work space. The workspace
contains a line listing of all work assigned it its status. Specific functionality
associated with this workspace includes:
       a. A display of all appointments and tasks associated1 with each
           investigation that needs to be completed within user-selected time
           frames.
       b. A display of all appointments and tasks associated with each
           investigation that needs to be completed within user-selected time
           frames.2
Investigator reviews case record noting disease, lab results and/or other relevant
information associated with the case record. Additional information may be
required to assure a complete record. The case record and specific data
associated with the report is disease specific.
Input: The minimum data associated with the case record includes:
       a. The date the report was received.
       b. The disease or reportable condition.
       c. Case name and contact information.
1
  The tasks associated with each investigation are found in the disease investigation protocols.
The use of a “checklist” or at a minimum a pop-up window to display the tasks should be
considered. The task list is disease specific.
2
  The system must have an appointment / tickler file capacity. While the specific functionality
associated with this component is discussed in a later task, the user must have access to it at any
point in the system.



KALHD-LHD Input to EDSS                   Appendix A                                         A-3
        d. The investigation priority associated with the report.
                1. The system must recognize investigations that are priority in
                    nature and alert the user to this condition.
        e. Investigator assigned to work order.
        f. Investigation status (e.g., open, pending, etc.).
Process: Depending upon the completeness of the initial report and the disease
in question additional data may be necessary before proceeding with the
investigation. The intent of this task is to gather enough information to determine
if the data support the “case definition” of the disease.
Output: All of the information in the input plus disease specific information
gathered during the preliminary investigation.
Outbreak Management Functions: Disease’s that are transmissible may be
outbreak related. As such, the minimum data set collected for each disease must
be defined AND the system must support the creation of additional data should
the need arise.

(3) Continue with Investigation? [Decision Point]
Task Description: The intent of task 2 and 2a is to determine if the report
warrants further investigation. Decisions about the need for an investigation
should be based upon laboratory results, CDC’s case definition and other
disease specific criteria. Reports that do not warrant investigation should be
closed and reported as not a case.
Input: Data from task 2 and 2a.
Process: Based upon the preliminary investigation a reported case may or may
not be a reportable disease of interest to Public Health. As such, the workflow
branches here but both move to the same task of updating a case record.
Output: Either a Yes or No response at the decision point leads the investigator
to an Update Case Record task. If yes, the investigator updates the case record
and proceeds with the investigation. If no, the investigator also updates the case
record but the investigator must state why the data did not support an
investigation and subsequently closes the investigation.
Outbreak Management Functions: No special functionality is associated with
this task.

(A) Update Case Record
Task Description: To keep the case record current the investigator should
update the record during the course of the investigation. The record should be
disease specific.
Input: Any additional and/or updated data associated with the investigation.
Process: After the preliminary investigation (or at any other time during the
investigation) the user must have the ability to edit / add / delete all data in the
record. An audit trail of all changes must be maintained so these changes can be
tracked should the need arise. The case record should be disease specific, that
is to say only data necessary to support the disease being investigated should be
displayed.
Output: Updated investigation record



KALHD-LHD Input to EDSS             Appendix A                                 A-4
Outbreak Management Functions: If the case is connected to a known
outbreak this record must be available to others (i.e., other counties) that may
also be investigating the outbreak.

(4) Need to Interview Case? [Decision Point]
Task Description: Certain disease have a requirement to interview the case to
help determine the source of infection and/or to help identify contacts to the case
person
Input: Data from the preliminary investigation and guidance for the Disease
Investigation Guidelines.
Process: No formal process has been identified.
Output: Decision of Yes or No.
Outbreak Management Functions: No special functionality is associated with
this task.

(B) Contact Investigation? [Decision Point]
Task Description: Certain diseases have a requirement to identify contacts to
the case person. Reasons vary but may include the need for prophylaxis and
quarantine.
Input: Disease specific guidelines and data from the investigation
Process: N/A
Output: Decision of Yes or No
Outbreak Management Functions: No special functionality is associated with
this task.

(C) Complete Investigation per Protocols
Task Description: Each investigation has specific tasks and/or public health
activities that must be completed prior to completing an investigation. These
tasks and/or public health activities are outline in the Disease Specific Protocols.
Input: N/A
Process: N/A
Output: N/A
Outbreak Management Functions: No special functionality is associated with
this task.
Note: It should be noted that the Investigation Guidelines may serve as the
foundation for each of the disease specific investigation “templates” within the
DSS. For example, the Guidelines provide information about the need to identify
contact and what the investigator should do for special situations (e.g.,
outbreaks)
(5) Schedule Appointment / Tickler / Reminders
Task Description: Input: The system should support an investigators
scheduling of tasks and/or appointment with cases/contact associated with an
investigation.
Process: The DSS must have a fully functional appointment scheduling and task
creation capacity. It is from these lists that tickler files can be created to assure
the work associated with each investigation is completed. It may be desirable to



KALHD-LHD Input to EDSS             Appendix A                                  A-5
prompt the user to make certain types of appointments associated with specific
diseases; this could occur using system prompts. This portion of the DSS must
support the following functionality:
       a. Support scheduling by hour, day, week or any other type the user
          desires that must be completed before a case may be closed.
       b. Support non-scheduled tasks that must be completed before an
          investigation may be closed.
       c. Have the ability to view all appointments and tasks by individual
          investigator for management oversight activities.
Output: Appointment / Tickler / Reminders for individual investigators.
Outbreak Management Functions: The ability to track cases, contacts and
other tasks associated with an outbreak is a vital component of any outbreak
management system. In addition, it may be necessary to track both isolation (for
cases) and quarantine (for contacts) activities. As such, the DSS must have a
robust Appointment / Tickler / Reminders system.

(6) Contact Case? [Decision Point]
Task Description: It may be difficult to contact the case due to a variety of
reasons and this decision point can be used to help the investigator
Input: Data from scheduling system
Process: N/A
Output: Decision of Yes, or No
Outbreak Management Functions: No special functionality is associated with
this task.

(D) Meet Move or Gone Elsewhere (MOGE) Requirements? [Decision Point]
Task Description: It may be difficult to contact the case due to a variety of
reasons occasionally it becomes impossible. The requirements to MOGE a case
will vary by disease.
Input: Data from scheduling system
Process: N/A
Output: Decision of Yes, or No
Outbreak Management Functions: It will be necessary to track the number and
circumstances associated with the MOGE of a case / contacts /delivery of
services certain outbreak situation. This functionality will be discussed in the
(8)Case/Contact Register Listing task

 (7) Biologic Sample Needed? [Decision Point] / (7a) Obtain or Assure
Sample is Sent to Lab
Task Description: Certain diseases have a requirement that a biologic sample
be sent to a laboratory; these samples may be sent to a private or to the state
laboratory. However, certain diseases do have a specific requirement that
requires the biologic sample to be sent to the state laboratory. Depending upon
the circumstances and/or disease the health department may obtain and send
the actual sample or simply have an assurance role in making sure that the
medical provider sends the biologic sample to the proper laboratory.



KALHD-LHD Input to EDSS           Appendix A                                A-6
Input: No specific input for the decision point. Data from the Case Record may
be used to label samples.3
Process: The DSS must have a functional method to track laboratory samples
and their results. An alternative method may be to link this to the current system
developed for PHClinic users and the sending and tracking of samples submitted
by local health departments to the state laboratory. All state laboratory results
must be able to be linked back to the original case record preferably without any
additional input from the investigator.
Output: Decision of Yes or No. If Yes, the local investigator must obtain a
biologic sample and/or assure one is sent to the state laboratory. Data to track
this should be sent to task (5) Schedule / Tickler / Reminders to help the
investigator keep track on the tasks associated with each investigation.
Laboratory results should be automatically linked back to the case record.
Outbreak Management Functions: During outbreaks there may be a need to
send samples to the state laboratory.
Note: Linking the DSS to a clinic management system will help the end user by
reducing the duplication of data entry (not entering the same information into
multiple systems) and also help the laboratory by having and/or expecting an
electronic order of laboratory samples prior to their arrival. These functional
requirements are currently available in PHClinic and are in use by a variety of
local health departments throughout Kansas.

(8) Case / Contact Register Listing:
Task Description: The Case / Contact listing of all contacts helps assure that
each is properly assessed and accounted before closing an investigation.
Input: Data from the case record and contact information collected by the
investigator during the course of the investigation.
Process: It is possible that during the course of an investigation a contact may
become a new case and as such the status of a contact must be able to change
from contact to a new case and trigger a new investigation. The system must
support one-to-many contacts with an investigation and if a contact status
changes to a new case the new case must still be able to be associated with the
original investigation.
Output: Line and detailed listing of all contacts associated with the case
Outbreak Management Functions: With selected enhancements, the case /
contact register listing may be able to be used to support the outbreak
management activities associated with quarantine and/or isolation. If there is a
desire by KAHLD to use this portion of the DSS to manage quarantine and
isolation the system must have the capacity to track lab samples, an appointment
system and a way to assure that services have been delivered.

(9) Treatment or Prophylaxis Needed? [Decision Point]:



3
 The ability to label samples implies that the DSS must have the ability to produce labels for use
by the local investigator.


KALHD-LHD Input to EDSS                   Appendix A                                         A-7
Task Description: Certain diseases require either treatment (usually provided by
a medical provider) or prophylaxis for contacts. The prophylaxis treatments are
usually time sensitive.
Input: Case/Contact Listing and Disease Protocol Information
Process: N/A
Output: Decision of Yes or No
Outbreak Management Functions: No special functionality is associated with
this task.

 (10) Services Delivered ? [Decision Point]:
Task Description: Many diseases of public health significance have a delivery of
services associated with the investigation (i.e., antibiotics, etc.). Assuring that the
services are delivered in a timely manner and recording the delivery of the
services are an important component of the investigation.
Input: Case/Contact Listing and Disease Protocol Information
Process: N/A
Output: Decision of Yes or No
Outbreak Management Functions: No special functionality is associated with
this task.
Note: The DSS can record the delivery of these services but does not support
the delivery of those services. What this means to the local health departments is
that there will be a duplicate data entry unless the DSS can be linked to clinic
management systems. In addition, the support of the delivery of services may
have an important role in an outbreak situation due to the potential numbers of
cases and/or contacts that may need services.

(11) Case Closed and File:
Task Description:
Input: Case/Contact Listing, Disease Protocol Information, Case Record
Process: Upon completion of an investigation, the case will need to be reviewed
for completeness based upon the standard investigation protocols. This review is
based upon a standard checklist that is specific for each disease. The system
should require the user to document completion or state the reason for non-
completion before the case can be closed. In addition, a hard copy of the
investigation should be able to be printed out for local records.
Output: Case Closed. In addition, all of the data that is specific to a jurisdiction
or a multi-jurisdiction regions should be readily available for export back to a
system of their choice for data analysis (i.e., SAS, EpiInfo, Excel, etc.)
Outbreak Management Functions: No special functionality is associated with
this task.

Local Public Health Departments and a DSS Interface:
An analysis of the workflow identified three distinct areas where an interface
between a local health department’s clinic management system and the DSS
may be beneficial, they are: 1) Task 10, Services Delivered, 2) Task 7, Biologic




KALHD-LHD Input to EDSS              Appendix A                                   A-8
Sample Needed and 3) Task 5, Schedule Appointment / Ticklers / Reminders.
Each of these potential interfaces will be discussed separately.

Task 10, Services Delivered : Since almost all of the activities associated with
assuring that a case and/or their contacts has received the necessary services
occurs at the local level, it is logical to assume that many of them will use their
clinic management system to help track the delivery of these services. For
example, if a case of Hepatitis A is reported and the investigation reveals that
there are a number of contacts that would benefit from the receipt of immune
globulin (IG) for post-exposure prophylaxis the local health department would be
involved in the delivery of these services. As such, the actual delivery and
recording of these services would occur within their clinic management system.
An interface that would supply case and contact demographics information from
the DSS and return data to the DSS from the clinic management system
documenting the delivery of the services would reduce a significant amount of
duplicate data entry.

Task 7, Biologic Sample Needed : The second identified task that may benefit
from an interface is the activities associated with a biologic sample. As previously
stated in the workflow and depending upon the specific disease being
investigated, there may be a need to assure and/or collect a biologic sample and
send it to the state laboratory. Currently, the state laboratory has the ability to
accept a laboratory orders and track samples from many of the local health
departments through the use of an existing electronic interface between their
clinic management system and the state lab. By capitalizing on this existing
interface and developing an additional interface between the DSS and the clinic
management system, laboratory samples could be electronically reported from
the state lab to the local health department and back to the DSS system which
would help assure the proper laboratory results are linked to the proper records.

Task 5, Schedule Appointment / Ticklers / Reminders: The final interface
between the local clinic management system and the DSS is a byproduct of the
above interfaces. In order to accurately track biologic samples and to assure that
the proper delivery of services has occurred it is a valid assumption to believe
that the Schedule Appointment / Ticklers / Reminders portion of the DSS should
interface with the local clinic management system. Since the documentation
associated with the DSS does not mention an Appointment Scheduling system it
is best to assume that one does not exist at this time; however, as evidenced by
the workflow the DSS could benefit from such a system. If and/or when this
addition is developed for the DSS, an interface between the two systems should
be seriously considered. There is the possibility of developing a “work around”
that would allow local health departments to use their existing clinic management
system’s scheduling capability to assure that important tasks associated with an
investigation is complete. This “work around” would still require an interface that
would supply case and contact demographics information from the DSS to the
clinic management system; this data would then be used within the scheduling



KALHD-LHD Input to EDSS             Appendix A                                 A-9
portion of the clinic management system to track the specific functional activities
associated with the investigation. Additional development and/or enhancements
to the clinic support system may be necessary to support both provider and task
specific scheduling.

The development of an interface between a local health department’s clinic
management system and the DSS has many advantages. The possibility of an
interface should be addressed during the upcoming JAD sessions.

WORKFLOW TASK CROSS REFERENCE TO KDHE EDSS Functional
Requirements Table:

Workflow Task ID/Description                     KDHE EDSS Reference(s)

1& A    Basic Data Entry                         1-14;16-18;21-23
1       Open Case                                24-26
1       Assignment & Monitoring                  61-62
A       Laboratory Reports                       15, 19-22; 26; 32-49
5       Schedule/Reminders                       80, 85-88
8&C     Case contact tracking                    27-31
C       Case investigation                       50-58;60;63-79; 81-84;98-99
                                                 101-123
11  Case Closing/status/outcome                  59-78; 89-97; 100
GLOBAL: External Public Health Reporting         123-138




KALHD-LHD Input to EDSS             Appendix A                                 A-
10
Appendix B: KALHD Input to EDSS Requirements

INTRODUCTION:

In the EDSS KALHD requirements definition workshop held on October 3, 2006 the
basic workflow was discussed and the KDHE EDSS RFP functional requirements were
reviewed in relation to the needs of the Local Health Departments. A number of
additional requirements not contained in the RFP were discussed and noted. To
document these suggested additions and/or clarifications, a copy of the RFP Appendix
B was modified to add a column for Functional Requirements Additions and/or
clarifications discussed during the session. Also included in this column are references
to PHIN Countermeasure & Response Administration (CRA) requirements and PHIN
Outbreak Management (OM) Functional requirements. These are combined to insure
key components of interest to LHDs are covered in the document.

CDC has split the PHIN Preparedness functional requirements into six areas:
             a) EED = Early Event Detection (Syndromic Surveillance -- the KDHE
                RFP flowchart begins with the receipt of disease event reports or Lab
                Event Reports which in some instances are outputs from an early
                detection activity)
             b) OM = Outbreak Management (includes a section on “health-related
                and environmental data sources” that relates to EED [Section 2.2]
                that has been added to the KALHD requirements column)
             c) CRA = Countermeasure/Response Administration (includes section on
                quarantine and isolation that has been referenced in the CRA column)
             d) PCA = Partner Communications and Alerting (HAN)
             e) CLS = Connecting Laboratory Systems (Electronic Laboratory
                Reporting---LHDs should be able to receive and process electronic
                laboratory reports into their clinic systems, utilizing the same logic as
                that used to process the reports at KDHE. This is not a part of the
                EDSS Requirements Table)
             f) CFC = Cross Functional Components (Per information at the
                September PHIN conference these have been folded into the other
                areas rather than being stated separately).

Thus in addition to the requirements discussed in the workshop an additional
subsequent “gap analysis” has focused on the Outbreak Management and
Countermeasure/Response Administration Functional Requirements. The relevant
sections in these documents span the EDSS KDHE Electronic Disease Surveillance
System: High-Level Disease Event Scenario (Use Case) tasks from receipt of Disease
Event Reports (#1) and Lab Event Reports (#2) to support of case creation and
management (#7). Both of these requirements specifications reference event and case
content which are covered in greater detail in the KDHE RFP Appendix B EDSS
Requirements document. In essence, both of these specifications are “extensions” of
the material covered in the EDSS table.

Where the EDSS table uses the term “Population Surveillance/Intervention Plan” to
describe groupings of cases with common characteristics, Outbreak Management uses
the term “health event” which has a broader connotation than the EDSS Appendix B use
KALHD-LHD Input to EDSS            Appendix B                                  B-1
of the terms “Disease Event Reports” and “Lab Event Report”. The CRA functional
specifications use the term “campaigns”. In all three instances it appears that multiple
cases (along with their associated lab tests, investigation activities, treatment(s)
recommended and administered, and other management activities) are grouped
together based on a set of common characteristics where a single response plan is
used. Quarantine and isolation may be used as response plan countermeasures and
the persons quarantined or isolated represent specific cases or contacts as defined in
the EDSS Appendix B where these actions can be specified as a part of the case plan
and associated with individual case records. As a result, the CDC OM and CRA
functional specification references in this KALHD requirements document are used to
further define the corresponding EDSS requirement definition. In most cases additional
text has also been added to the EDSS Requirement Description column wherever an
OM or CRA reference occurs. The reader can find the associated OM or CRA functional
requirements at http://www.cdc.gov/phin.

Although 138 requirements were noted on the RFP, for more efficient use, we have
eliminated all requirements EXCEPT those that required additional needs or
clarification, based on workshop and subsequent addition of CRA and OM PHIN
requirements.

Reporting is covered in the KDHE RFP functional requirements starting with “Analysis,
Visualization & Report Development” (lines 117 through 123) and “External Public
Health Reporting” (lines 124 through 138). The first section deals mainly with ad hoc
reporting via database extracts and formatting capabilities, scheduling tools, and the
library of reports, letters and forms (although no specific reports were discussed). Public
health reporting primarily focuses on the ability to create and use Supplemental Forms
for reporting to CDC (via XML in most cases in a secure transport mechanism) as well
as to other agencies. Several specific reporting capabilities were articulated by the local
health department representatives:
        a) Ability to off load/extract data sets from the EDSS operational database to an
            analytical tool ( for example, an Access database or Excel spreadsheet) for
            analysis
        b) Ability to download a LHD’s complete set of records to a local jurisdiction for
            analysis
        c) Creation of a standard set of canned reports to be developed via a joint
            project to define specific contents
        d) Ability to pull information in a useful and identifying manner for line listings
            and epi curves
        e) Ability to create observed versus projected disease specific case patterns

There is considerable overlap amongst the PHIN preparedness functional areas
associated with the KDHE RFP functional requirements. In essence the EDSS
requirements cut across the PHIN Early Event Detection (EED), Outbreak Management
(OM) and Countermeasure/Response Administration (CRA) specifications. In areas
were we have identified clearly overlapping or complementary functional requirements
we have included the associated OM and CRA functional requirement statements. We
did not include any of EED functional requirements specifications because in the
overlapping areas the EED functional requirements are less specific than those stated
in the EDSS functional requirements or parallel portions of the OM and CRA functional

KALHD-LHD Input to EDSS             Appendix B                                  B-2
requirements. In certain areas we may have “over referenced” OM and CRA functional
requirements but over referencing was preferred to understating the scope of a
particular functional requirement contained in the EDSS table. At the end of the table we
have included additional OM and CRA references we believe are relevant to the EDSS
scope.




KALHD-LHD Input to EDSS            Appendix B                                 B-3
                                                         REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                               Requirement
  Line #       Requirement      Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type           Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                             Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                             Health Reporting
                               DC-1          The system SHALL provide the capability for creation of    There should be the ability to customize Web pages for each specific disease
           1 Functional:
                                             customizable Web pages by disease programs.                (versus disease “programs”), and the contents should include “stripped down”
             Data Collection
                                                                                                        versions of the Kansas Disease Investigation Protocols.
                                                                                                        CRA - The CRA functional requirements for system architecture calls for
                                                                                                        supporting automated data collection at remote sites in disconnected mode and
                                                                                                        subsequently synchronized with the network
                                                                                                        Systems supporting(Counter response administration) CRA should ideally
                                                                                                        support multiple, quickly deployable options to support automated data collection
                                                                                                        at remote sites. (2.1.3)

                                                                                                        Systems supporting CRA should be able to electronically record and store data
                                                                                                        using remote devices that may be uploaded to an aggregating system. (2.1.4)

                                                                                                        Systems supporting CRA should have the flexibility to collect protocol specific
                                                                                                        information when specific protocol for a campaign or a drug requires that
                                                                                                        additional information be collected. (2.1.1.2)
                                                                                                        Systems supporting CRA should be capable of using configurable, domain-
                                                                                                        specific vocabulary. (2.1.5)
                                                                                                        OM - Systems designed to support OM must offer configuration flexibility so that
                                                                                                        new data fields, entities, entity types and relationship types may be added to
                                                                                                        capture information unique to each particular health event. (2.1.1)
                                                                                                        Systems supporting OM should support multiple deployment options (e.g., client
                                                                                                        server, disconnected, and potentially web based). (2.1.3)
                                                                                                        Systems supporting OM should be able to electronically record and store data
                                                                                                        from remote devices that may be uploaded to an aggregating system. (2.1.4)
                                                                                                        Systems supporting OM should be capable of using configurable, domain-
                                                                                                        specific vocabulary. (2.1.5)

               FUNCTIONAL:     DC-2          The system SHALL provide the capability for creating and   LHDs may enter the basis information if the first event information comes to the
           2
               DATA                          using a standard template when creating disease specific   health department. The initial information may be incomplete (i.e. an infectious
               COLLECTION                    program Web pages and will contain the following           disease nurse at a hospital sees something strange and calls the LHD to
                                             minimum data fields:                                       discuss) and may not include many of the required fields specified in DC-3.
                                             • Full Name (First, Middle, Last, Maiden) for non-HIV      Therefore:
                                               reporting                                                a)   must be able to create a “partial” record and code it as “pending”
                                             • Unnamed Test Code (e.g., birth date year, first name

KALHD-LHD Input to EDSS                      Appendix B                                                  B-4
                                                         REQUIREMENT DESCRIPTION                                        KALHD Functional Requirements Additions/Clarifications
                             Requirement
   Line #      Requirement    Reference    Functional Requirements identified in the RFP associated          Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/             requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public             Outbreak Management and Early Event Detection
                                           Health Reporting
                                             initial, birth date month, last name initial, birth date day)   b)   Sources other than physicians may make the initial “report” or contact with
                                           • Residence Address (street, apt, city, state, Zip Code)               the LHD. Therefore it would be helpful to have an initial source code along
                                           • County of residence (table driven value)                             with the reporting source name, organization, etc
                                           • Disease (table driven value)
                                                                                                             c)   Must have notes capability to record the initial contact information on the
                                           • Date of Onset (mmddyyyy)
                                                                                                                  situation under discussion
                                           • Date of Birth (mmddyyyy)
                                           • Age at time of event                                            d)   Multiple person records may arise out of the initial contact (disease event
                                           • Gender (table driven value)                                          report) and each should be linked to the initial contact data set
                                           • Race (table driven value)
                                           • Ethnicity (table driven value)                                  e)   Must be able to only enter a pre-defined reduced data set for large outbreaks
                                           • Reporting Source (Physician’s Name, Organization,               CRA - Systems supporting CRA must support structured data entry for common
                                             Title, Address (street, apt, city, state, zip), Phone           forms and fields to ensure data integrity, validity, and standardization. A
                                           • Person/Agency completing report: Name, Organization,            standardized data structure ensures that data mapping of common elements will
                                             Title, Address (street, apt, city, state, zip), Phone           only be necessary one time, rather than for each campaign. (2.1.2)
                                             Number
                                           • Reporting source’s internal tracking number for reported        OM - Systems supporting outbreak management (OM) must support structured
                                             event.                                                          data entry for common forms and fields to ensure data integrity, validity, and
                                                                                                             standardization. A standardized data structure ensures that data mapping of
                                                                                                             common elements will only be necessary one time, rather than for each event.
                                                                                                             (2.1.2)

                             DC-2                                                                            CRA: Basic information about all organizations that participate in a CRA
Continued
                                                                                                             campaign must be captured and stored in a local instance of a public health
from
                                                                                                             directory. (2.3.1)
previous row
                                                                                                             CRA: Every organization must have a global identifier unique across all CDC
                                                                                                             partner jurisdictions. (2.3.1.1)

                                                                                                             CRA: All organizations with roles in CRA campaigns must be entered into a local
                                                                                                             instance of a public health directory. (2.3.1.2) – (2.3.1.2.a, 2.3.1.2.b

                                                                                                             CRA: In addition to the organization information stored in a local instance of a
                                                                                                             public health directory, the functional roles of the organization within a campaign
                                                                                                             (e.g., administering facility, take response location, pharmaceutical distribution
                                                                                                             center, isolation or quarantine location, referring organization) and any referring
                                                                                                             organization categories within a campaign (e.g., healthcare response team,
                                                                                                             public health response team) are required. (2.3.2)

                                                                                                             CRA: Every recorded countermeasure administration, patient follow up, take
                                                                                                             response reading, isolation or quarantine, or other type of patient encounter must

KALHD-LHD Input to EDSS                    Appendix B                                                         B-5
                                                         REQUIREMENT DESCRIPTION                                       KALHD Functional Requirements Additions/Clarifications
                             Requirement
  Line #       Requirement    Reference    Functional Requirements identified in the RFP associated          Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/             requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public             Outbreak Management and Early Event Detection
                                           Health Reporting
                                                                                                             be linked to the participating organization to promote tracing of possible safety
                                                                                                             and efficacy issues related to the organization where the encounter occurred.
                                                                                                             See section 2.6.3 Current Countermeasure Administration Data. (2.3.3)

                                                                                                             CRA: Information about all individuals with roles in support of CRA campaigns
                                                                                                             must be captured. (2.3.4)-(2.3.4.1, 2.3.4.2, 2.3.4.2a, 2.3.4.2.b)

                                                                                                             CRA: The organization must be able to trace the electronic records of staff
                                                                                                             members to the actual people they represent. (2.3.5)

               FUNCTIONAL:   DC-3          The system SHALL provide the capability to specify                Clarification: Will the system allow for unique sets of required fields for each
           3
               DATA                        required fields for a given entry on a given Web page.            specific disease, or disease program ?
               COLLECTION                  The rule will identify the field, the acceptable values for the   Create standard table for provider information rather than entering each time.
                                           field (table-driven fields), whether it is required, and the      User would select appropriate provider from table. Would also enable reporting
                                           error message to prompt the user if the required field is not     by provider as to case activity.
                                           entered or does not have the correct value. The minimum
                                           required fields for an event report included but is not           CRA - Systems supporting CRA must have flexibility to specify countermeasure
                                           limited to:                                                       data elements as required or optional based on characteristics of the campaign
                                           • Disease (table driven value)                                    under which the countermeasure is being delivered. (2.1.1.1)
                                           • Patient’s Name (Last, First) for the non-HIV “Record
                                                                                                             OM– To be included in minimum required fields:
                                             Event Report” entry screen
                                           • Unnamed Test Code in the HIV “Record Event Report”              When a health event is investigated, it must be assigned an event identifier (i.e.,
                                             entry screen                                                    Event ID) that is unique within the jurisdiction. (2.2.2.1)
                                           • Date of Birth
                                           • Age at the time of the event                                    Data describing the health event should be captured, including the reason for the
                                           • Gender (table driven value)                                     investigation, the category of event (e.g. environmental, infectious), the date the
                                           • Reporting Physician’s Name or Reporting Lab’s                   event began, the suspected agent (if known) or investigation focus, the
                                             Organization.                                                   geographic area impacted by the event, as well as the event status (e.g., open,
                                           • Person/Agency completing event report’s Name,                   closed). (2.2.2.2)
                                             Organization, Title, Address (street, apt, city, state, zip),   Systems supporting OM should have the ability to record the case definition for a
                                             Phone Number                                                    health event. (2.2.2.3)
                                                                                                             Systems supporting OM should have the ability to capture changes to the case
                                                                                                             definition that occur as the health event evolves. (2.2.2.4)

                                                                                                             -

               FUNCTIONAL:   DC-4          The system SHALL provide the capability to save                   For a “pending” report (See DC-2) the user should be able to see all entries they
           4
               DATA                        incomplete or incorrect reports. The record will be               have made whether or not they are incorrect rather than having the system null
               COLLECTION                  assigned a status of "Incomplete". When required fields           them out since this record is their documentation of the initial contact which will

KALHD-LHD Input to EDSS                    Appendix B                                                            B-6
                                                         REQUIREMENT DESCRIPTION                                    KALHD Functional Requirements Additions/Clarifications
                              Requirement
  Line #        Requirement    Reference    Functional Requirements identified in the RFP associated       Included data gathered at the October 3rd meeting and reviews of PHIN
                   Type         Number      with data collection, ELR, Case Management, Analysis/          requirements documents for Countermeasure/Response Administration,
                                            Visualization, Report Development and External Public          Outbreak Management and Early Event Detection
                                            Health Reporting
                                            are incorrectly entered the user will be provided the          require some level of follow up from the LHD.
                                            opportunity to save as an incomplete record, in such cases
                                            the incorrect entries will be nulled out (Blanked out).
                FUNCTIONAL:   DC-6          The system SHALL provide the capability to automatically       From a given case record a LHD user should be able to trigger the creation of an
           6
                DATA                        compare a person in a newly entered or imported disease        extract record containing the patient demographic record for creation of a patient
                COLLECTION                  report to existing people in CPR for the de-duplication        record in the given LHD’s clinic management system (the receiving and creation
                                            process.                                                       of the record in the clinic management system would not be a part of EDSS).
                                                                                                           However, the process should be similar to that used in the Immunization Registry
                                                                                                           to exchange patient information via the PID HL7 message segment with local
                                                                                                           health departments that enables them to create new patient records in their clinic
                                                                                                           management system. Likewise, if the case is created via a patient’s visit to a
                                                                                                           LHD clinic, then the client demographics should be able to be uploaded to EDSS
                                                                                                           rather than re-entered.
                FUNCTIONAL:   DC-11         The system SHALL provide the capability to update CIS          When the disease event report or lab event report causes a new person record to
           11
                DATA                        with a new person record with a unique identifier when a       be created the LHD to which it is assigned must have the ability to determine that
                COLLECTION                  definite non-match is found.                                   the name is an “alias” for a named individual they already know and therefore the
                                                                                                           ability to change the name accordingly.
                FUNCTIONAL:   DC-12         The system SHALL provide the capability to record other        Clarification: By “user” defined fields do you mean the KDHE system
           12
                DATA                        person identifiers (social security number, Medicaid/          administrator or an individual LHD?
                COLLECTION                  Medicare number, administrative unit local identification      OM - Case data about an entity should include a case identifier. (2.2.4.2.a)
                                            numbers, etc). This may be accomplished as user defined
                                            fields.
                FUNCTIONAL:   DC-13         The system SHALL provide the capability for assignment         In this case the LHD should have the final decision authority on the match
           13
                DATA                        of human review by an authorized user for cases or lab         determination.
                COLLECTION                  reports that have been entered electronically or directly by   For all situations where disease event reports or lab event reports have been
                                            non-public health personnel that are determined to be          assigned to a given case, the LHD must be able to review these assignments for
                                            approximate matches or in circumstances when there is          any case assigned to their jurisdiction.
                                            any other data error to be checked for correction and/or
                                            appending to a case.
                FUNCTIONAL:   DC-16         The system SHALL provide the capability to incorporate a       A LHD should be able to review all situations where the system has determined
           16
                DATA                        disease report de-duplication algorithm which may include      that there are duplicated disease reports and the de-duplication process has
                COLLECTION                  Soundex, number/letter transposition, edit-distance and        eliminated one or more reports AND be able to add the reports to the case if they
                                            other tools to compare disease reports and weigh               are determined not to be duplicates.
                                            matches.
                FUNCTIONAL:   DC-18         The system SHALL provide the capability by authorized
           18
                DATA                        users to select one or more approximate disease report
                COLLECTION                  matches to merge with the newly entered or electronically
                                            received disease report or allow the user to cause the

KALHD-LHD Input to EDSS                     Appendix B                                                     B-7
                                                         REQUIREMENT DESCRIPTION                                   KALHD Functional Requirements Additions/Clarifications
                              Requirement
  Line #        Requirement    Reference    Functional Requirements identified in the RFP associated     Included data gathered at the October 3rd meeting and reviews of PHIN
                   Type         Number      with data collection, ELR, Case Management, Analysis/        requirements documents for Countermeasure/Response Administration,
                                            Visualization, Report Development and External Public        Outbreak Management and Early Event Detection
                                            Health Reporting
                                            system to create a new disease report.
                FUNCTIONAL:   DC-25         The system SHALL provide the capability to configure the      In the case of multi jurisdiction coverage (regions) the reports should be sent to
           25
                DATA                        system to automatically assign a disease report to the       the regional coordinator and each county/doctor. The distribution list for a given
                COLLECTION                  appropriate program and administrative unit using an         region should be created and maintained within the system by the regional
                                            algorithm based on the patient’s address and disease or      coordinator.
                                            condition.                                                   LHDs must be able to define “specialized” regions for specific purposes, and
                                                                                                         these regions may contain border counties in other states.
                                                                                                         Functions associated with the current PHIX or replacement alerting/notification
                                                                                                         system (CM-37, CM-38, etc.) must include both regional and community alerting
                                                                                                         and notification.
                FUNCTIONAL:   DC-26         The system SHALL provide the capability to configure the     A significant number of lab reports will not contain the patient’s address.
           26
                DATA                        system to automatically assign a lab report to the           However, if a case is created based on an initial report from a physician or other
                COLLECTION                  appropriate program and administrative unit using an         source to the LHD (or region) and a copy of the lab report also goes directly to
                                            algorithm based on the patient's address and disease or      the LHD, then the LHD can make the assignment of jurisdiction unit and
                                            condition.                                                   associate the lab report to the correct disease report/case. Therefore the LHD
                                                                                                         should have the capability to make the assignments.
                FUNCTIONAL:   DC-27         The system SHALL provide the capability for creating and     Because of the repetitive infections of a specific person in communicable disease
           27
                DATA                        using a standard template when creating Case Contact         (often called frequent flyers) the system may contain multiple case records for
                COLLECTION                  Tracking reports (Web pages) specific by program and will    the same individual over time. Thus when the individual is identified as a contact
                                            contain the following minimum data fields:                   to another case, the individual may already be in the Customer Information
                                            • Full Name (First, Middle, Last, Maiden)                    System (CIS). As a result, when a LHD investigator identifies one or more
                                            • Residence Address (street, apt, city, state, Zip Code)     contacts for a case they are currently working on, the user must have the ability
                                            • County of residence (table driven value)                   to query the CIS, identify the individual’s record and then automatically create the
                                            • Disease (table driven value)                               contact association with the case being investigated rather than setting up the
                                            • Date of Onset (month, day, year)                           contact as a new entry in the system. The user should then be able to update
                                            • Date of Birth (mmddyy)                                     the contact data set entry with current information (address and contact
                                            • Age at time of event                                       information in particular).
                                            • Gender (table driven value)                                If the contact is new it would be added via this functional requirement and should
                                            • Race (table driven value)                                  be added to the CIS master file.
                                            • Ethnicity (table driven value)                             Need drop-down definition for a valid contact given the disease involved.
                                            • Reporting Source (Physician’s Name, Organization,          Need disease specific rule set available for the conditions under which a contact
                                              Title, Address (street, apt, city, state, zip), Phone      record can be closed. (parallel to a set of MOGE rules used to close an
                                            • Person/Agency completing report: Name, Organization,       immunization record at a given health department)
                                              Title, Address (street, apt, city, state, zip), Phone
                                            • Reporting source’s internal tracking number for reported   OM - Case data about the entity should include: a case identifier (i.e., Case ID)
                                              event.                                                     that is unique within the jurisdiction being reported, the suspected agent, case
                                                                                                         diagnosis, health status (e.g., no symptoms, acute illness), case status (e.g.,
                                                                                                         confirmed, probable, suspect), investigation dates, clinical history, symptom
                                                                                                         onset date and time, epidemiological links to other cases, and priority (e.g., high,
                                                                                                         medium, low). (2.2.4.2.a)

KALHD-LHD Input to EDSS                     Appendix B                                                   B-8
                                                        REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                              Requirement
  Line #        Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                   Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                            Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                            Health Reporting

                                                                                                       Exposure investigation data to be captured must include information related to
                                                                                                       exposure levels, type of exposure (e.g., intimate, social, household, common
                                                                                                       conveyance), place of exposure, length of time the entity was exposed,
                                                                                                       frequency of exposure, and the entity’s proximity to the source of exposure.
                                                                                                       (2.2.4.3.a)
                                                                                                       Detailed data must be collected about the source of exposure as well as the
                                                                                                       exposed entity to support contact exposure tracing. Exposure data related to
                                                                                                       both the potential source and the potential spread include the entity’s type,
                                                                                                       Subject ID, Contact ID, contact’s name and address, exposure dates and times,
                                                                                                       health status, and priority code. (2.2.4.3.b)
                                                                                                       Epidemiological (epi) data must be collected to assist in the case investigation of
                                                                                                       events. Standard epi data to be collected includes: onset date and time of
                                                                                                       symptoms, type of symptoms, risk factors, medical history data, laboratory data,
                                                                                                       procedure data, and questionnaire responses. (2.2.4.2.c)
                                                                                                       Epi data must be collected to assist in the exposure investigation of health
                                                                                                       events. Standard epi data to be collected for exposure investigation parallels the
                                                                                                       data to be collected for case investigation and includes: onset date and time of
                                                                                                       symptoms, type of symptoms, risk factors, laboratory data, procedure data, and
                                                                                                       questionnaire responses. (2.2.4.3.c)
                FUNCTIONAL:   DC-28         The system SHALL provide the capability to record from     The query described in DC-27 should be executed from original patient’s case
           28
                DATA                        zero to many Case Contact reports per stored case in the   record display and be able to easily repeat the process for each contact.
                COLLECTION                  system from within the original patient’s case.            OM - Systems supporting OM must allow for dynamic, event-specific case
                                                                                                       investigation data to be captured and for event-specific data that describes
                                                                                                       contact between two subjects. (2.2.4.2.d, 2.2.4.3.d)
                                                                                                       In the context of a case, all entities exposed to a case must be recorded and
                                                                                                       linked to the case. (2.2.4.2.e)
                                                                                                       Demographic information should be collected about the investigator, including
                                                                                                       their name, address, and contact information, so that the investigator may be
                                                                                                       contacted to answer questions or to provide additional information. (2.2.4.2.f)
                                                                                                       Both the jurisdiction investigating the event and the jurisdiction reporting the
                                                                                                       cases and associated investigations must be captured. For example, if a person
                                                                                                       becomes ill during travel in one jurisdiction but is the resident of another, the
                                                                                                       illness will be reported by the state (jurisdiction) of residence and investigated by
                                                                                                       the jurisdiction visited. (2.2.4.2.g)
                                                                                                       Systems supporting OM should have the ability to classify entities associated
                                                                                                       with the investigation as investigation controls. For example, controls share

KALHD-LHD Input to EDSS                     Appendix B                                                 B-9
                                                         REQUIREMENT DESCRIPTION                                   KALHD Functional Requirements Additions/Clarifications
                              Requirement
  Line #        Requirement    Reference    Functional Requirements identified in the RFP associated     Included data gathered at the October 3rd meeting and reviews of PHIN
                   Type         Number      with data collection, ELR, Case Management, Analysis/        requirements documents for Countermeasure/Response Administration,
                                            Visualization, Report Development and External Public        Outbreak Management and Early Event Detection
                                            Health Reporting
                                                                                                         demographic characteristics with the subject of the case, but are not infected with
                                                                                                         the agent that is the focus of the investigation. (2.2.4.2.h)


                FUNCTIONAL:   DC-30         The system SHALL provide the capability to record a Case     Must have the ability to track “unknown” contact records and make sure they are
           30
                DATA                        Contact without a name when the Contact’s name is not        either identified or closed due to being unable to identify and/or locate them.
                COLLECTION                  known.
                FUNCTIONAL:   DC-31         The system SHALL provide the capability to use Case          From within the original patient’s case (See DC-28) the user should be able to
           31
                DATA                        Contact report information for creating a new case while     see for any original patient’s case contact all of that contact’s CASES as well as
                COLLECTION                  still maintaining the association of the Contact to the      all other patient cases where the contact is also named as a CONTACT, as well
                                            original report/case.                                        as to create a new case for the contact (DC-31--see previous column in this row).
                                                                                                         NOTE: This should provide the necessary mapping in order to create a “social”
                                                                                                         network of all cases and contacts associated with an outbreak.
                                                                                                         Contact data set should be able to include specific location/event/environmental
                                                                                                         factors such as catered dinners, family reunions, daycare, same flight, etc. in
                                                                                                         addition to personal contacts such as family members, etc.
                                                                                                         OM - Each investigation subject may be associated with exposure contacts,
                                                                                                         including unambiguous links to contacts in other jurisdictions. (2.3.3.1)
                                                                                                         Contacts of exposed entities (e.g., people, animals, places) may be traced,
                                                                                                         investigated, and monitored. (2.3.3.2)
                                                                                                         Systems supporting OM should be able to create new contacts from existing
                                                                                                         case records, and should also identify the contact type. (2.3.3.3)
                                                                                                         Systems supporting OM must support contact exposure tracing by allowing one
                                                                                                         contact to be linked to multiple cases, and allowing multiple contacts to be linked
                                                                                                         to a single case. (2.3.3.4)
                                                                                                         Systems supporting OM should be able to produce contact work lists for each
                                                                                                         investigator to use, and should allow sorting by priority or geography. (2.3.3.5)
                              CM-2          The system SHALL provide the capability for each disease
           51 Functional:                                                                                          Clarification: Patient Profiles are simply an extension of the case
              Case Mgmt.                    program to create a unique Patient Profile to add user-                record as defined in DC-2?
                                            defined categories, capturing demographic data (not event
                                            or disease specific data). Patient Profile categories (and             User-defined fields
                                            fields) including but not limited to:                        OM - Systems supporting OM must have the capability to capture demographic
                                            • Personal (name, gender, date of birth, alias, race,        data about persons involved in an OM investigation, including: Subject ID, name,
                                               ethnicity, etc.)                                          address, date of birth, gender, phone number, race, ethnicity, and country of
                                            • Addresses (residence, mailing, travel, etc.) –             citizenship. (OM - 2.2.1.1)
                                               must maintain history of address changes
                                            • Family Relationships (multiple entries)                    Systems supporting OM must have the capability to capture information about
KALHD-LHD Input to EDSS                     Appendix B                                                   B-10
                                                        REQUIREMENT DESCRIPTION                                    KALHD Functional Requirements Additions/Clarifications
                             Requirement
  Line #       Requirement    Reference    Functional Requirements identified in the RFP associated      Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/         requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public         Outbreak Management and Early Event Detection
                                           Health Reporting
                                           • Employment – must maintain history of employment            organizations/ locations involved in an OM investigation/ animals involved in an
                                             changes                                                     OM investigation./ any object involved in an OM investigation/any conveyance
                                           • Hobbies (multiple entries)                                  involved in an OM investigation/ any public or private gathering of people/ any
                                           • Religious Affiliations (multiple entries)                   living things other than persons or animals that are involved in an OM
                                           • Allergies – must maintain history of allergies              investigation/ an entity’s travel history to support investigations of entities
                                           • Antibiotic and Medication Lists (history and current)       infected, exposed or potentially exposed. (OM -, 2.2.1.2, 2.2.1.3, 2.2.1.4, 2.2,1,5,
                                           • Legal Status                                                2.2.1.6, 2.2.1.7, 2.2.1.8, 2.2.1.9)
                                           • Medical Insurance
                                           • Other user-defined fields (may be table-driven values)
                             CM-22         The system SHALL provide the capability to define
           71 Functional:                                                                                          Clarification: How does this differ from DC-2? It appears to have
              Case Mgmt.                   required data fields for event reports including but not                the same basic data set.
                                           limited to:
                                           • Disease
                                           • Patient’s Name (Last, First) for the non-HIV event report
                                           • Unnamed Test Code in the HIV event report
                                           • Date of Birth
                                           • Full Name (First, Middle, Last, Maiden)
                                           • Residence Address (street, apt, city, state, Zip Code)
                                           • County of residence (table driven value)
                                           • Date of Onset (month, day, year)
                                           • Age at time of event
                                           • Gender (table driven value)
                                           • Race (table driven value)
                                           • Ethnicity (table driven value)
                                           • Reporting Source (Physician’s Name, Organization,
                                             Title, Address (street, apt, city, state, zip), Phone
                                           • Person/Agency completing report’s Name, Organization,
                                             Title, Address (street, apt, city, state, zip), Phone
                                           • Reporting source’s internal tracking number for reported
                                             event.
                             CM-26         The system SHALL provide the capability to custom build
           75 Functional:                                                                                          Clarification: By user defined does this mean by the KDHE system
              Case Mgmt.                   case management categories with the ability to add an                   administrator? That is, once the data set to be used in Kansas has
                                           unlimited number of user-defined fields for each Case                   been determined, will it be universally applied across the state? If
                                           Category entry and the capability to be updated by table-               so, will the LHD have input into the content; both the case
                                           driven values. Possible case management categories                      management categories and the data elements in each category?
                                           include but are not limited to:
                                           • Clinical (e.g., allergy, pregnant)
                                           • Behavioral (e.g., IV drug use, risk behaviors)
                                           • Environmental (e.g., hiking, camping, etc.)

KALHD-LHD Input to EDSS                    Appendix B                                                    B-11
                                                        REQUIREMENT DESCRIPTION                                      KALHD Functional Requirements Additions/Clarifications
                             Requirement
  Line #       Requirement    Reference    Functional Requirements identified in the RFP associated        Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/           requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public           Outbreak Management and Early Event Detection
                                           Health Reporting
                                           • Hereditary (e.g., family history)
                                           • Historical (e.g., previous incidence of disease)
                                           • Travel History (where, when, mode of transportation,
                                             flight numbers)
                                           • Gathering attended during incubation period (where,
                                             when, other attendees)
                                           • Case contacts during incubation period (family, friends)
                                           • Symptoms exhibited in the incubation period
                                           • Clinical Visits History
                                           • Treatment History
                                           • Examination History
                                           • Animal Contacts
                                           • Antibiotic and Medication History
                                           • Onset Date and Location (location name, street, apt#,
                                             city, state, zip, location type, Geomap Code, Census
                                             Tract Code, FIPS Map Code)
                                           • Vaccination History
                                           • Case Activity Log History
                                           • Final Case Outcome (table driven)
                             CM-27         The system SHALL provide the capability to display              OM - Systems supporting OM: Electronic questionnaires must be developed and
           76 Functional:
                                           questions and step-by-step instructions to assist the           validated. They will be designed by investigators to collect common data
              Case Mgmt.
                                           Investigator in populating the user-defined fields within       elements (e.g., patient demographics, test results, exposure contacts), agent-
                                           each custom defined Case Category.                              specific data elements (e.g., specific laboratory test), and other customized data
                                                                                                           elements. (2.3.1.1)

                                                                                                           Systems supporting OM should provide ability to control configuration and
                                                                                                           revision to investigation-specific questionnaires. (2.3.1.2)
                                                                                                           Systems supporting OM must provide the ability to publish investigation-specific
                                                                                                           questionnaires and implementation guides. (2.3.1.3)
                                                                                                           Case investigation should be supported by reusable questionnaire libraries that
                                                                                                           use common terminology (where available) to maximize the efficiency of data
                                                                                                           exchange. (2.3.1.4)



                             CM-31         The system SHALL provide the capability to generate form
           80 Functional:                                                                                  Form letters should be able to be downloaded into a word processing program, at
              Case Mgmt.                   letters based on KDHE and LHD standard letter and fax           the LHD, for additional editing and/or customization
                                           templates to support contacting the patient or other parties.
                                           Form/Fax letters should automatically insert or indicate:
KALHD-LHD Input to EDSS                    Appendix B                                                      B-12
                                                       REQUIREMENT DESCRIPTION                                 KALHD Functional Requirements Additions/Clarifications
                             Requirement
  Line #       Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                           Health Reporting
                                           • The user’s Name, Title, and Division/Program
                                           • The user’s contact information
                                           • Missing demographic information (if any)
                                           • Missing clinical information
                             CM-32         The system SHALL provide the capability to create and      OM - Systems supporting OM should provide a manual or automatic means of
           81 Functional:
                                           update a Person Case Management Plan.                      updating the status of case records as the case definition changes. (2.3.1.5)
              Case Mgmt.
                                                                                                      Systems supporting OM should track the changes made to the status of case
                                                                                                      records as a result of changes in the case definition. (2.3.1.6)


                             CM-33         The system SHALL provide the capability to create a Case
           82 Functional:                                                                             Case management template information should be downloadable, to the LHD for
              Case Mgmt.                   Management Plan template for each disease including but    additional editing and/or customization
                                           not limited to the following details:
                                           • Plan goals
                                           • Action items, duration, and assignments
                                           • Health indicators to consider
                                           • Questions to assist the health care provider in
                                             surveillance/intervention activities
                                           • Questions to assist the Epidemiologist Investigator in
                                             surveillance/intervention planning
                                           • Other user-defined fields (can be table-driven values)
                             CM-34         The system SHALL provide the capability to use a Case
           83 Functional:                                                                             Case management template information should be downloadable, to the LHD for
              Case Mgmt.                   Management Plan template to create a custom plan for the   additional editing and/or customization
                                           case.
                             CM-35         The system SHALL provide the capability for authorized
           84 Functional:                                                                             Must also be able to document when, what and who for each action item. The
              Case Mgmt.                   roles to modify and update the case plan’s details:        action items should include whether the action was performed by the agency’s
                                           • Plan title (text)                                        investigator or referred to someone else. The date the action was completed
                                           • Plan start date                                          should also be recorded in order to support LHD administrative performance
                                           • Plan due date                                            reporting needs..
                                           • Plan description
                                           • Goal Category (table-driven)
                                           • Goal details (memo box)
                                           • Goal creation date
                                           • Goal due date
                                           • Action Item Title (text)
                                           • Action Item details (memo box)
                                           • Action Item creation date
                                           • Action Item due date
KALHD-LHD Input to EDSS                    Appendix B                                                 B-13
                                                        REQUIREMENT DESCRIPTION                                     KALHD Functional Requirements Additions/Clarifications
                             Requirement
  Line #       Requirement    Reference    Functional Requirements identified in the RFP associated       Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/          requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public          Outbreak Management and Early Event Detection
                                           Health Reporting
                                           • Assigned to Individual
                                           • Health indicator title (text)
                                           • Health indicator details (memo box)
                                           • Health indicator date
                                           • Other user-defined fields (can be table-driven values)
                             CM-39         The system SHALL provide the capability to specify a
           88 Functional:                                                                                 Need full reminder/tickler support for all case management and contact
              Case Mgmt.                   calendar reminder to identify a Case Management activity.      investigation activities (these are two separate activity sets even though a
                                           The reminder notification should identify the following        contact may turn into a case)
                                           minimum Case Management activity details:
                                           • Date/Time due
                                           • Person to contact
                                           • Case Management Activity Title
                                           • Case Management Activity Description.
                             CM-40         The system SHALL provide the capability to allow an
           89 Functional:                                                                                 LHDs should have the ability to close a case through a pre-defined procedure
              Case Mgmt.                   Investigator role to update the case status based on the       which would include a disease specific “completion checklist. This should include
                                           following table driven values:                                 MOGE rules for situations where the case investigator cannot find the patient. A
                                           • Close Pending                                                similar procedure and checklist should be available for closing a contact record
                                           • Closed.                                                      as well as for other status updates besides Close Pending and Closed.
                             CM-53         The system SHALL have the capability to present analysis
        102 Functional:                                                                                   OM - -Systems supporting OM must be able to aggregate data (2.4.10).
            Case Mgmt.                     results that aggregate and display real-time information
                                           based on population surveillance analysis criteria as          -Health event data should be aggregated into a centralized data store designed
                                           selected by the user.                                          specifically to support analysis of events over time (2.4.11).


                             CM-58         The system SHALL provide a “Help” interface to assist the
        107 Functional:                                                                                   Generally., EDSS should provide context sensitive HELP to provide help on the
            Case Mgmt.                     outbreak coordinator to determine exposure and outbreak        specific task being performed
                                           risks by identifying if the result of the current population
                                           assessment occurrences are greater than the:
                                           • Previous year’s occurrences
                                           • Historical average of occurrences.
                             CM-59         The system SHALL have the capability to design and
        108 Functional:                                                                                   CRA utilizes the term “campaign” which has a broader definition than the
            Case Mgmt.                     create templates for Population Surveillance/Intervention      Population Surveillance/ Intervention concept in that it can include
                                           Plans. The plan template should describe:                      countermeasures for first responders, the general population or population risk
                                           • Plan Objectives                                              groups.
                                           • Overall Goals
                                           • Start and scheduled completion dates                         CRA: Information about the characteristics of each campaign shall be captured.
                                           • Overall Plan percentage completed                            (2.2.1) – (2.2.1.1, 2.2.1.2, 2.2.1.3)


KALHD-LHD Input to EDSS                    Appendix B                                                     B-14
                                                        REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                             Requirement
   Line #      Requirement    Reference    Functional Requirements identified in the RFP associated    Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/       requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public       Outbreak Management and Early Event Detection
                                           Health Reporting
                                           • Assignment to Outbreak Coordinator                        CRA: Systems supporting CRA must be able to support multiple concurrent
                                           • Population Surveillance/Intervention Target Group ID      campaigns. (2.2.2)
                                           • Completion percentage
                                                                                                       CRA: Systems supporting CRA must be able to support merging multiple
                                           • Completion date
                                                                                                       campaigns into one. (2.2.3)
                                           • Other user-defined fields (can be table-driven values).
                                                                                                       CRA: Systems supporting CRA must be able to support splitting a campaign into
                                                                                                       multiple campaigns. (2.2.4)
                                                                                                       CRA: Systems supporting CRA must be able to support linking campaigns.
                                                                                                       (2.2.5)
                                                                                                       CRA: Linking CRA campaign data with corresponding campaign data in other
                                                                                                       systems (e.g., outbreak management systems) must be supported. (2.2.6)
                                                                                                       CRA: Systems supporting CRA should allow for collection of additional data
                                                                                                       elements defined during a campaign. An example of this would be responses to
                                                                                                       a set of questions devised as a result of statistical analysis of follow up data.
                                                                                                       (2.2.7)
                                                                                                       CRA: Systems supporting CRA must have the flexibility to specify campaign data
                                                                                                       elements as required or optional based on the characteristics of the campaign.
                                                                                                       (2.2.8) – (2.2.8.1, 2.2.8.2, 2.2.8.3)

                             CM-59
Continued in                                                                                           Among the possible countermeasures in the CRA are isolation and quarantine in
previous row                                                                                           the case of communicable disease outbreaks, whether voluntary or involuntary.
                                                                                                       This involves individual patient tracking and service provision similar to case
                                                                                                       management as described in the EDSS requirements previously described.
                                                                                                       CRA: Recording and tracking of isolation and quarantine information must be
                                                                                                       supported. (2.6.6.1)

                                                                                                       CRA: Systems supporting CRA must be able support quarantine or isolation
                                                                                                       authorizations that are issued to restrict a patient’s movement. (2.6.6.2)

                                                                                                       CRA: Systems supporting CRA must have the flexibility to support
                                                                                                       authorization information that varies based on the type of isolation or quarantine
                                                                                                       imposed. Examples of authorization information include: the campaign under
                                                                                                       which the isolation or quarantine is authorized, the agent, the level of the
                                                                                                       authorizing authority (e.g., federal, state, local), the court order number, the
                                                                                                       name of the person who signed the court order, the type of order (e.g., group,
                                                                                                       individual), the nature of the restriction (e.g., voluntary, mandatory), the type of
                                                                                                       restriction (e.g., work, food, shelter in place), and the organization and staff

KALHD-LHD Input to EDSS                    Appendix B                                                  B-15
                                                       REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                             Requirement
   Line #      Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                           Health Reporting
                                                                                                      member responsible for administering the authorization. (2.6.6.2.a)

                                                                                                      CRA: Each quarantine or isolation authorization must be assigned an identifier
                                                                                                      that is unique within the jurisdiction. (2.6.6.2.b)

                                                                                                      CRA: If the order is for a group of people, a description of the group is required.
                                                                                                      (2.6.6.2.c)

                                                                                                      CRA: If the order is for an individual, information useful to identify or locate the
                                                                                                      person should be captured. (2.6.6.2.d)

                                                                                                      CRA: Isolation and quarantine data should be communicated to the monitoring
                                                                                                      site to monitor the case’s location, health status, and compliance with the order.
                                                                                                      (2.6.6.2.e)

                                                                                                      CRA: Each patient isolation or quarantine event must be tied to the patient,
                                                                                                      campaign
                                                                                                      and authorization involved. (2.6.6.3)

                                                                                                      CRA: Patient demographics must be collected for the restricted patient. See
                                                                                                      section 2.6.1. (2.6.6.3.a)



                             CM-59                                                                    CRA: Systems supporting CRA must have the flexibility to support event
Continued in
                                                                                                      information that varies based on the type of isolation or quarantine imposed.
previous row
                                                                                                      (2.6.6.3.b )

                                                                                                      CRA: Each event must be assigned an identifier that is unique within the
                                                                                                      jurisdiction. (2.6.6.3.c)




KALHD-LHD Input to EDSS                    Appendix B                                                 B-16
                                                       REQUIREMENT DESCRIPTION                                       KALHD Functional Requirements Additions/Clarifications
                            Requirement
  Line #      Requirement    Reference    Functional Requirements identified in the RFP associated     Included data gathered at the October 3rd meeting and reviews of PHIN
                 Type         Number      with data collection, ELR, Case Management, Analysis/        requirements documents for Countermeasure/Response Administration,
                                          Visualization, Report Development and External Public        Outbreak Management and Early Event Detection
                                          Health Reporting
                            CM-59                                                                      CRA: Isolation and Quarantine Cont’d.
                                                                                                       Monitoring of isolated or quarantined patients is to be supported by triggering and
                                                                                                       capturing the results of investigator activities such as daily telephone calls and
                                                                                                       visits to the isolation or quarantine location. (2.6.6.4)

                                                                                                       CRA: Based on the type of restriction imposed, monitoring information may
                                                                                                       include: the patient, the patient isolation or quarantine event, temperature and
                                                                                                       symptom details, date and time of monitoring encounter, staff member who
                                                                                                       conducted the monitoring, number of attempts to contact the patient, the type of
                                                                                                       encounter (e.g., visit, telephone), whether the patient is complying with the
                                                                                                       quarantine order, person spoken to if monitoring occurred by phone call.
                                                                                                       (2.6.6.4.a)

                                                                                                       CRA: When the restriction is ended, the discharge date, reason and staff
                                                                                                       member authorizing the discharge should be captured. (2.6.6.4.b)

                                                                                                       CRA: Each isolation or quarantine monitoring event must be assigned an
                                                                                                       identifier that is unique within the jurisdiction. (2.6.6.4.c)

                                                                                                       CRA: Symptom tracking and/or surveillance is required as part of an isolation
                                                                                                       or quarantine monitoring event. The symptoms tracked will be from a
                                                                                                       limited list of symptoms, generally defined by a standards development
                                                                                                       organization (SDO). (2.6.6.4.d)

                                                                                                       CRA: Possible cases identified as a part of symptom tracking and/or surveillance
                                                                                                       should be reported to systems managing contact exposure
                                                                                                       tracing. (2.6.6.4.e)

                                                                                                       CRA: When monitoring occurs by telephone, the identity of the person (e.g.,
                                                                                                       patient, relative, healthcare worker at the quarantine site) contacted should be
                                                                                                       captured.
                                                                                                       (2.6.6.4.f)
                            CM-60         The system SHALL provide the capability for an authorized
        109 Functional:
            Case Mgmt.                    outbreak coordinator role to copy a Population
                                          Surveillance/ Intervention Plan template to create another
                                          Population Surveillance/Intervention Plan.
                            CM-63         The system SHALL provide the capability to allow an
        112 Functional:                                                                                OM - Systems supporting OM should capture information such as date and time
            Case Mgmt.                    authorized outbreak coordinator role to create “Activity     of an activity, activity type, who initiated the activity, and contact information to
                                          Log” entries for a Population Surveillance/Intervention

KALHD-LHD Input to EDSS                   Appendix B                                                   B-17
                                                         REQUIREMENT DESCRIPTION                                      KALHD Functional Requirements Additions/Clarifications
                              Requirement
  Line #      Requirement      Reference    Functional Requirements identified in the RFP associated        Included data gathered at the October 3rd meeting and reviews of PHIN
                 Type           Number      with data collection, ELR, Case Management, Analysis/           requirements documents for Countermeasure/Response Administration,
                                            Visualization, Report Development and External Public           Outbreak Management and Early Event Detection
                                            Health Reporting
                                            plan. The minimal details for an activity log should include:   generate activity logs for management purposes (2.2.9.1);
                                            • Activity Action Done On Date
                                                                                                            Activity logs (tools for investigators to track their actions during a case/outbreak)
                                            • Activity Action Planned Description
                                                                                                            should be supported (2.2.9.2);
                                            • Activity Action Outcome Description
                                            • Activity Action Follow-Up Description.
                                                                                                            Activity logs may also provide information needed to support communication with
                                                                                                            various jurisdictions in the event that the investigation crosses jurisdictional
                                                                                                            boundaries (2.2.9.3)
                              AVR-1         The system's Analysis, Visualization, and Report (AVR)
        117 Functional:                                                                                     Suggested export capability to an analytical tool ( Access or Excel) for use on
            Analysis,                       tools SHALL provide the capability to export selection          desktops for LHD internal analysis
            Visualization &                 results to the following formats:
                                            • Text                                                          CRA-–
            Report Dev.
                                            • Rich Text                                                     AVR Generation: Detailed an aggregate reports of the CRA data should be
                                            • Word                                                          available. Detailed reports may be used for quality assurance of data entry, to
                                            • Excel                                                         assist with any required follow up activities, or to provide lists of response team
                                            • XML                                                           members for referring organizations. Aggregate reports may be used to show
                                            • SAS                                                           campaign progress and preparedness across the entire jurisdiction. (CRA 2.7) –
                                            • Acrobat PDF                                                   (2.7.1 to 2.7.14)
                                            • Picture
                                            • CSV                                                           OM - Data should be accessible for use with commonly available analytical tools
                                            • HTML                                                          (e.g. SAS, SPSS, EPI-INFO, MS Access, MS Excel, Crystal Reports) - (2.4.12)
                                                                                                            Systems supporting OM should support multiple file formats for import and
                                                                                                            export, such as databases, spreadsheets, messages, and text files, among
                                                                                                            others. (2.5.15)
                                                                                                            Data exchange should support analysis and information sharing of possible
                                                                                                            health events at all levels of public health (e.g., national, state, local). (2.5.16)

                              AVR-2         The system's AVR tools SHALL provide the capability to
        118 Functional:                                                                                     OM - Systems supporting OM should: have the ability to produce charts, maps,
            Analysis,                       generate the following output reporting formats:                graphs that illustrate OM data (2.4.2).
            Visualization &                 • Mailing labels
            Report Dev.                     • Cross-tabulation reports
                                            • Form-style reports
                                            • Sub-reports
                                            • Conditional reports
                                            • Drill down reports
                                            • OLAP (online analytical processing) reports
                                            • GIS Map reports
                                            • Cluster mapping reports


KALHD-LHD Input to EDSS                     Appendix B                                                      B-18
                                                          REQUIREMENT DESCRIPTION                                     KALHD Functional Requirements Additions/Clarifications
                              Requirement
  Line #      Requirement      Reference    Functional Requirements identified in the RFP associated        Included data gathered at the October 3rd meeting and reviews of PHIN
                 Type           Number      with data collection, ELR, Case Management, Analysis/           requirements documents for Countermeasure/Response Administration,
                                            Visualization, Report Development and External Public           Outbreak Management and Early Event Detection
                                            Health Reporting
                              AVR-4         The system's AVR tools SHALL provide the capability to:
        120 Functional:                                                                                     OM - Systems supporting OM should: allow for analytical searches based on
            Analysis,                       • Create customizable reporting templates                       multiple criteria (2.4.1); generate electronic data dictionaries (2.4.3); have the
            Visualization &                 • Create on-demand ad-hoc objects                               ability to produce pre-formatted queries and reports (2.4.5); have the ability to
            Report Dev.                     • Allow for the definition of multiple user-defined selection   produce individual reports for each emergency team member or investigator
                                              parameter fields                                              (2.4.6); have the ability to compare characteristics of exposed and non-exposed
                                            • Allow the user to view and drop the desired database          persons (2.4.7); have the ability to produce lists of action items (2.4.8) ; have the
                                              table element into the object                                 ability to print questionnaires for multiple uses (2.4.9).
                                            • Allow the ability to create If Then/Else logic
                                            • Able to generate group and overall report summary
                                              totals
                                            • Contains on-line help assistance to export the results in
                                              a desired format.
                              AVR-6         The system SHALL provide capability for producing and
        122 Functional:                                                                                     OM-Reports should clearly indicate the number of cases, the number of contacts
            Analysis,                       maintaining at a minimum the following library of reports,      per case, the number of cases with no known epi-link at the time of diagnosis,
            Visualization &                 letters and forms:                                              the lab results and the number of vaccinations and/or treatments administered
            Report Dev.                     • Lab event reports without a corresponding physician           (2.4.4).
                                            event report.
                                            • Letter to inform a physician of the lab event reports
                                            without a matching physician event report and the lab
                                            event report indicates him/her as the reporting physician.
                                            • CDC standard reports and supplemental forms.
                                            • Performance information reports for each Epidemiologist
                                            Investigator role and for a disease program. The
                                            performance metrics will show the:
                                            --Total cases Assigned
                                            --Total cases Closed
                                            --Total cases Pending Close
                                            --Total cases In Progress
                                            • Report for each disease program showing various
                                              effectiveness metrics:
                                            --For a fiscal year
                                            --For a calendar year
                                            --For a specified date range
                              RPT-14        The system SHALL provide the capability to interface with       OM - Systems supporting OM must be able to accept data from other partner
        137 Functional:
                                            existing CDC messaging protocols, formats, and web-             systems supporting OM: 2.5.2;
            External Public
                                            enabled data collection systems (STD*MIS, HARS,                 Systems supporting OM must be able to create and send messages for lab test
            Health
                                            eHARS, ABLES, STELLAR, etc.) and SHALL be                       requests /lab results/countermeasure administration requests: 2.5.3/ 2.5.5/2.5.10
            Reporting
                                            compatible with future CDC messaging protocols (PHIN            Systems supporting OM must be able to receive, parse, and process messages
                                            MS – see FCCR10.2).                                             for lab test result responses/ countermeasures that have been administered:

KALHD-LHD Input to EDSS                     Appendix B                                                      B-19
                                                        REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                              Requirement
  Line #      Requirement      Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                 Type           Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                            Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                            Health Reporting
                                                                                                       2.5.4/2.5.9;
                                                                                                       Systems supporting OM should be able to exchange messages for lab results
                                                                                                       with systems supporting surveillance, EED, and other preparedness areas: 2.5.6;
                                                                                                       Systems supporting OM must be able to exchange messages for confirmed,
                                                                                                       probable and suspect cases, and other case classifications, with systems
                                                                                                       supporting surveillance, EED and other preparedness areas/ for investigations
                                                                                                       and exposure contacts: 2.5.7/2.5.8;
                                                                                                       Systems supporting OM must be able to exchange aggregate data: 2.5.11;
                                                                                                       Systems supporting OM should be able to provide aggregate data necessary for
                                                                                                       health event monitoring to systems that support response tracking: 2.5.12
                                                                                                       Mapping interfaces and data dictionaries must be clearly defined and included in
                                                                                                       data exchanges to indicate and describe both standard and customized fields
                                                                                                       because systems supporting OM are configurable to meet the individual needs of
                                                                                                       each event and therefore collect data specific to each event. -2.5.13
                                                                                                       Message components should be grouped by observation type (e.g., laboratory,
                                                                                                       symptom, exposure, risk, treatment) by systems supporting OM.-2.5.14
                                                                                                       Systems supporting OM should support multiple file formats for import and
                                                                                                       export, such as databases, spreadsheets, messages and text files, among
                                                                                                       others. -2.5.15

                                                                                                       Data exchange should support the analysis and information sharing of public
                                                                                                       health events at all levels of public health (e.g., national, state and local) -2.5.16
                              RPT-14                                                                   CRA System integration and data exchange:
        137 Functional:
                                                                                                        Systems integration requirements specific to systems supporting section below
            External Public
                                                                                                       and describe the types of data that these and receive. This section is limited to
            Health
                                                                                                       describing the types supported; not the requirements for transporting exchange
            Reporting -
                                                                                                       of data with partner organizations supports public all levels of public health.
            CONT’D
                                                                                                       Message construction and parsing, requirements that span PHIN functional
                                                                                                       areas are separately reviewed in “PHIN Preparedness Cross Functional available
                                                                                                       at www.cdc.gov/phin.

                                                                                                       CRA: information collected from multiple sites or prior to exchanging it with
                                                                                                       partner organizations. -2.8.1

                                                                                                       CRA: Systems supporting CRA must be able to receive, countermeasure
                                                                                                       administration requests. This requirement performance measure for assessing
                                                                                                       preparedness Preparedness Key Performance Measures, available -2.8.2

                                                                                                       CRA: When patients identified for countermeasure managed separately from the

KALHD-LHD Input to EDSS                     Appendix B                                                 B-20
                                                       REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                             Requirement
   Line #      Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                           Health Reporting
                                                                                                      system that supports outbreak management), the system receive and
                                                                                                      acknowledge information regarding patients. -2.8.2.1

                                                                                                      CRA: Systems supporting CRA should be able to create countermeasure
                                                                                                      administration requests, in accordance Administration – Referral Message
                                                                                                      Implementation www.cdc.gov/phin. - 2.8.3
                                                                                                      CRA: Systems supporting CRA must be able to exchange messages for
                                                                                                      countermeasures that have been administered. This requirement is identified as
                                                                                                      a key performance measure for assessing preparedness as described in PHIN
                                                                                                      Preparedness Key Performance Measures, available at www.cdc.gov/phin. -
                                                                                                      2.8.4
                                                                                                      CRA: Sufficient data must be supplied to national partners to conduct statistical
                                                                                                      analysis including, but not limited to, countermeasure safety and efficacy, trends
                                                                                                      in adverse events, compliance, and preparedness level. - 2.8.4.1
                                                                                                      CRA: Systems supporting CRA must be able to notify all concerned parties that
                                                                                                      corrective action may be required, such as re-training of staff and/or recall of
                                                                                                      patients for additional countermeasures, when safety and efficacy issues with a
                                                                                                      countermeasure or the campaign staff at a particular administering facility are
                                                                                                      discovered. For more information, refer to PHIN Preparedness Partner
                                                                                                      Communications and Alerting Functional Requirements, available at
                                                                                                      www.cdc.gov/phin. -2.8.5
                                                                                                      CRA: Systems supporting CRA must demonstrate the ability to exchange
                                                                                                      messages for adverse events identified during active surveillance. This
                                                                                                      requirement is identified as a key performance measure for assessing
                                                                                                      preparedness as described in PHIN Preparedness Key Performance Measures,
                                                                                                      available at www.cdc.gov/phin. --2.8.6
                                                                                                      CRA: Systems supporting CRA must be able to exchange aggregated data.
                                                                                                      Examples of aggregated data to be supported are: patient counts such as
                                                                                                      number of patients who received countermeasures; number of patients for whom
                                                                                                      the countermeasure did not have the desired outcome (e.g., an equivocal take
                                                                                                      for a smallpox vaccination); and number of patients complying with prescribed
                                                                                                      countermeasures. -2.8.7
                                                                                                      CRA: Systems supporting CRA should have the ability to receive data such as
                                                                                                      pharmaceutical information, campaign setup information, -2.8.8

                                                                                                      CRA-Countermeasures–
PHIN
requirements                                                                                          CRA: All pharmaceuticals administered must be identified by lot number and
KALHD-LHD Input to EDSS                    Appendix B                                                 B-21
                                                      REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                            Requirement
   Line #     Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                 Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                          Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                          Health Reporting
- Not                                                                                                manufacturer. (2.4.1)
associated
                                                                                                     CRA: Pharmaceutical inventory should be captured to identify and respond to
with any
                                                                                                     issues with availability of pharmaceuticals and to track the distribution and use of
requirement
                                                                                                     controlled substances. (2.4.2) –(2.4.2.1, 2.4.2.2, 2.4.2.3)
in RFP
                                                                                                     CRA: Integration with pharmaceutical stockpiles should be supported. (2.4.3)-
                                                                                                     (2.4.3.1, 2.4.3.2, 2.4.3.3)
                                                                                                     CRA: Validation of lot numbers must be used when recording countermeasure
                                                                                                     usage to ensure consistency and reduce the possibility of incorrect lot numbers.
                                                                                                     (2.4.4)
                                                                                                     CRA: Information must be stored about specific containers of prepared
                                                                                                     countermeasures, such as vaccine batch vials or large pill containers from which
                                                                                                     multiple patients may receive countermeasures. (2.4.5)-(2.4.5.1, 2.4.5.2, 2.4.5.3,
                                                                                                     2.4.5.4)
                                                                                                     CRA: Every patient encounter shall be linked to any countermeasure(s)
                                                                                                     administered to the patient during the campaign to promote tracing of possible
                                                                                                     efficacy and safety issues related to the pharmaceutical lot or the prepared
                                                                                                     countermeasure container. See section Current Countermeasure Administration
                                                                                                     Data. (2.4.6)
                                                                                                     CRA – Current Countermeasure Administration Data – Section 2.6.3
                                                                                                     CRA: Entry and tracking of current countermeasure administration data must be
                                                                                                     provided. (2.6.3.1)
                                                                                                     CRA: 2.6.3.2 Every countermeasure administration record must be assigned at
                                                                                                     least one unique identifier, such as the Patient Vaccination Number (PVN) used
                                                                                                     to identify vaccination events in the National Smallpox Preparedness Program.
                                                                                                     (2.6.3.2) –(2.6.3.1a)
                                                                                                     CRA: Every countermeasure administration record is to be linked to the
                                                                                                     campaign under which it was administered. (2.6.3.3)
                                                                                                     CRA: Each countermeasure administration record must be linked to the original
                                                                                                     patient record. (2.6.3.4)
                                                                                                     CRA: Countermeasure administration data must include: the actual dosage, the
                                                                                                     date of administration, the administering facility, the state where administered,
                                                                                                     the person who ordered the countermeasure, and the person who administered
                                                                                                     the countermeasure. (2.6.3.5)-(2.6.3.5.a, 2.6.3.5.b, 2.6.3.5.c)
                                                                                                     CRA: Systems supporting CRA must be able to capture the administration of
                                                                                                     more than one countermeasure during a patient encounter; for example, the
KALHD-LHD Input to EDSS                   Appendix B                                                 B-22
                                                      REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                            Requirement
  Line #      Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                 Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                          Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                          Health Reporting
                                                                                                     administration of both antibiotic prophylaxis and vaccination to a patient exposed
                                                                                                     to inhalational anthrax. (2.6.3.6)
                                                                                                     CRA: Systems supporting CRA must support recording the administration of
                                                                                                     single and multiple doses of a countermeasure, and combinations of
                                                                                                     pharmaceuticals that may be dispensed as a countermeasure. (2.6.3.7)
                                                                                                     CRA: Each countermeasure administration record will be traceable to the specific
                                                                                                     facility and administrator involved in the administration of the countermeasure.
                                                                                                     (2.6.3.8)
                                                                                                     CRA: Sufficient information is required to identify all patients who received
                                                                                                     countermeasures at a specific facility, by a specific person, or from a specific
                                                                                                     container, in the event of issues arising with the facility, the administrator, the
                                                                                                     container, or the pharmaceutical lots in the container. (2.6.3.9)
                                                                                                     CRA: Sufficient information must be recorded to determine when a patient should
                                                                                                     return for a follow up visit for administration of an additional countermeasure or
                                                                                                     evaluation, such as a smallpox take response reading. (2.6.3.10)
                                                                                                     CRA: The acceptance of potentially incomplete patient and patient
                                                                                                     countermeasure information from external sources such as systems used to
                                                                                                     manage outbreak data must be supported. This might consist of an electronic
                                                                                                     request to administer a countermeasure to a patient or an electronic record of a
                                                                                                     countermeasure that has already been administered. (2.6.3.11)
                                                                                                     CRA: The participation of a patient in more than one campaign must be
                                                                                                     supported. For example, systems supporting CRA must be able to record that a
                                                                                                     single person received a smallpox vaccination during the National Smallpox
                                                                                                     Preparedness Program and anthrax prophylaxis during an anthrax response
                                                                                                     campaign. (2.6.3.12)
                                                                                                     CRA: It must be possible to track a patient's progress through a series of
                                                                                                     countermeasures, such as the anthrax vaccination series, in which the
                                                                                                     appropriate time between the individual administrations varies depending on how
                                                                                                     many vaccinations have been received previously. (2.6.3.13)
                                                                                                     OM- Prophylaxis and Treatment Data Functional Requirements
                                                                                                     OM: Systems supporting OM should capture or be linked to data regarding the
                                                                                                     prophylaxis or treatment to cases, exposed individuals, or at risk persons,
                                                                                                     including the person who ordered the prophylaxis or treatment, and the name,
                                                                                                     date, type, duration, and dosage of the treatment or prophylaxis given. For
                                                                                                     specific data requirements regarding the administration of prophylaxis and
                                                                                                     treatment – Reference PHIN CRA Functional Requirements (2.2.7.1)

KALHD-LHD Input to EDSS                   Appendix B                                                 B-23
                                                       REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                             Requirement
   Line #      Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                           Health Reporting

                                                                                                      OM: Contraindication information should be collected to indicate why
                                                                                                      vaccinations, treatments, or antidotes may not have been administered or why
                                                                                                      the patient may not have complied with prescribed interventions. (2.2.7.2)

                                                                                                      CRA- Allocation and Tracking
                                                                                                      CRA: Pharmaceuticals in limited supply must be allocated to prioritize coverage
                                                                                                      to at-risk populations. The ordering, distribution and usage of limited supply
                                                                                                      pharmaceuticals may require tracking at multiple levels of public health and
                                                                                                      coordination between multiple levels of public health.
                                                                                                      CRA: Systems supporting CRA must be able to manage allocation and tracking
                                                                                                      of countermeasures from a central location, whether it is national, territorial, state
                                                                                                      or local. (2.5.1)
                                                                                                      CRA: Systems supporting CRA must be able to track and allocate
                                                                                                      countermeasures based on available quantities or apportionments. (2.5.2) –
                                                                                                      (2.5.2.1, 2.5.2.2)
                                                                                                      CRA: Systems supporting CRA must be able to base allocations upon
                                                                                                      assessment of high priority populations and usage guidelines for formulations
                                                                                                      matched to risk populations. (2.5.3) –(2.5.3.1)
                                                                                                      CRA: Systems supporting CRA must support order placement, fulfillment, and
                                                                                                      status. (2.5.4)
                                                                                                      CRA: Systems supporting CRA must be able to convert order size (e.g., dosage)
                                                                                                      to packaging. (2.5.5)
                                                                                                      CRA: Systems supporting CRA must be able to reduce allocations to a
                                                                                                      jurisdiction based on amounts ordered. (2.5.6)
                                                                                                      CRA: Systems supporting CRA must be able to reallocate based on changes to
                                                                                                      requested allocations. (2.5.7)

                                                                                                      CRA – Adverse Events
PHIN
requirements                                                                                          CRA: If an affected person suffers a negative reaction to administered
- Not                                                                                                 vaccinations or prophylaxis, adverse event data may be collected to determine
associated                                                                                            whether additional countermeasures are needed, whether there is an issue with
with any                                                                                              a particular lot of a pharmaceutical, whether pharmaceuticals dispensed from a
requirement                                                                                           certain container or batch show unusual trends, or whether a specific facility or
in RFP                                                                                                administrator has a high number of adverse events.
                                                                                                      CRA: Data should be collected to describe the characteristics of the reaction, the
                                                                                                      amount of time lapsed between the entity receiving the countermeasure and the
                                                                                                      onset of symptoms, pharmaceutical lot and batch information, as well as

KALHD-LHD Input to EDSS                    Appendix B                                                 B-24
                                                       REQUIREMENT DESCRIPTION                                 KALHD Functional Requirements Additions/Clarifications
                             Requirement
   Line #      Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                           Health Reporting
                                                                                                      countermeasure administration information (including the location and
                                                                                                      administrator). (2.6.5.1)
                                                                                                      OM Adverse Event Data Functional Requirements – 2.2.8.1
                                                                                                      OM: If an affected person suffers a negative reaction to a vaccine or prophylaxis
                                                                                                      that was administered, adverse event data may be collected and used to
                                                                                                      determine the need for additional interventions or to determine if there is a
                                                                                                      problem with the pharmaceutical, batch, or the administering facility or person.
                                                                                                      For specific data requirements regarding adverse event data, please reference
                                                                                                      PHIN Preparedness Countermeasure/Response Administration Functional
                                                                                                      Requirements and Process Flows,. (2.2.8.1)


PHIN                                                                                                  CRA Patient Demographic Data
requirements
                                                                                                      CRA: Demographic information about all patients who received countermeasures
- Not
                                                                                                      in a CRA campaign must be collected. (2.6.1.1) – (2.6.1.1.a, 2.6.1.1.b, 2.6.1.1.c,
associated
                                                                                                      2.6.1.1.d, 2.6.1.1.e, 2.6.1.1.f)
with any
requirement                                                                                           CRA: Systems supporting CRA must be able to provide a means for locating and
in RFP                                                                                                contacting patients who do not return for follow up visits, who must be monitored
                                                                                                      for compliance, or who might have received a countermeasure for which an issue
                                                                                                      has been discovered. (2.6.1.2)
                                                                                                      CRA: Systems supporting CRA must have the flexibility to specify demographic
                                                                                                      data elements as required or optional based on the characteristics of the
                                                                                                      campaign under which a countermeasure is being delivered. (2.6.1.3)
                                                                                                      CRA: Every patient should be represented only once in systems supporting CRA.
                                                                                                      (2.6.1.4) – (2.6.1.4.a, 2.6.1.4.b, 2.6.1.4.c)
                                                                                                      CRA: Sufficient information about patients must be captured electronically to link
                                                                                                      patient records to the actual people they represent, either manually or by the use
                                                                                                      of identifying information stored within systems supporting CRA. This link is
                                                                                                      necessary to support public health investigations, including exposure contact
                                                                                                      investigation, and to communicate with patients who need to receive
                                                                                                      countermeasures or who require post-administration follow up, including safety
                                                                                                      and efficacy follow up. (2.6.1.5)
                                                                                                      CRA: It must be possible to link patient records to corresponding case and/or
                                                                                                      exposure contact records in systems used to manage outbreak data. (2.6.1.6)
                                                                                                      CRA: Patients who are willing to participate in more extensive follow up including
                                                                                                      detailed surveys and photos should be electronically identifiable. (2.6.1.7)

KALHD-LHD Input to EDSS                    Appendix B                                                 B-25
                                                      REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                            Requirement
  Line #      Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                 Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                          Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                          Health Reporting
                                                                                                     CRA: Patient Historical Data (2.6.2.1 To 2.6.2.6)
                                                                                                     CRA: Patient Follow-Up (2.6.4.1 To 2.6.4.9)
                                                                                                     OM: Follow-up and monitoring functional requirements – Section 2.2.5)



                                                                                                     CRA- Historical Data
                                                                                                     CRA: Collection of historical information such as medical history (e.g.,
                                                                                                     vaccination), disease history, and other medical history including but not limited
                                                                                                     to medications and pre-existing medical conditions must be supported. (2.6.2.1)
                                                                                                     CRA: Systems supporting CRA must have the flexibility to specify historical data
                                                                                                     elements as required or optional based on the characteristics of the campaign or
                                                                                                     the countermeasure involved. For example, the data may be used in statistical
                                                                                                     analysis to determine whether a previously received countermeasure has an
                                                                                                     impact on the result of the countermeasure currently being administered.
                                                                                                     (2.6.2.2)
                                                                                                     CRA: Historical information collected must include a history identifier that is
                                                                                                     unique within the jurisdiction, the patient involved, and the campaign during
                                                                                                     which the history was collected. (2.6.2.3)
                                                                                                     CRA: In addition to the general historical information, medical history data may
                                                                                                     include the date, the result (e.g., take response, outcome), and the occurrence of
                                                                                                     adverse events. (2.6.2.4) –(2.6.2.4a, 2.6.2.4b)
                                                                                                     CRA: Disease history must include the name of the disease (from a standard list
                                                                                                     of diseases), date or timeframe (e.g., childhood, adulthood) when the patient had
                                                                                                     the disease, and comments about the progression of the disease. (2.6.2.5)
                                                                                                     CRA: Medication history information must include the name of the medication
                                                                                                     (from a standard list of medications), The reason for taking the medication, and
                                                                                                     the timeframe and dose taken. (2.6.2.6)

                                                                                                     CRA – Patient Follow Up
                                                                                                     CRA: Systems supporting CRA must provide the capability to conduct and record
                                                                                                     the results of patient follow up (2.6.4.1) –(2.6.4.1a, 2.6.4.1b)
                                                                                                     CRA: Systems supporting CRA must have the flexibility to support follow up
                                                                                                     information that varies based on the type of countermeasure administered.
                                                                                                     (2.6.4.2)
                                                                                                     CRA: Each patient follow up record will be linked to the corresponding

KALHD-LHD Input to EDSS                   Appendix B                                                 B-26
                                                       REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                             Requirement
   Line #      Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                           Health Reporting
                                                                                                      countermeasure administration record. (2.6.4.3)
                                                                                                      CRA: Follow up information must include a follow up event identifier that is
                                                                                                      unique within the jurisdiction. (2.6.4.4)
                                                                                                      CRA: Follow up information may include: the corresponding patient encounter,
                                                                                                      responses to follow up questions, reason for non-availability of information,
                                                                                                      adverse event information, general comments, the facility where the follow up
                                                                                                      event occurred, the identity of the staff member conducting the follow up, and the
                                                                                                      date the follow up event occurred, as applicable. 2.6.4.5) –(2.6.4.5a)
                                                                                                      CRA: Systems supporting CRA must be able to capture information on the
                                                                                                      success (e.g., take response) or failure (e.g., lack of take response) of a
                                                                                                      countermeasure administration, as this information will be required for some
                                                                                                      types of countermeasures. (2.6.4.6)
                                                                                                      CRA: A take response exam is a special type of follow up involving determining
                                                                                                      the outcome (e.g., take response) of a smallpox vaccination (or possibly other
                                                                                                      currently unidentified countermeasures). (2.6.4.7)-(2.6.4.7.a, 2.6.4.7b)
                                                                                                      CRA: The linking of CRA patient countermeasure administration data with any
                                                                                                      corresponding cases in a surveillance system should be supported. (2.6.4.8)


PHIN                                                                                                  OM- LINKING – SECTION 2.3.2
requirements
                                                                                                      OM: Linkages allow investigators to create meaningful analysis, characterize the
- Not
                                                                                                      event, and identify at-risk populations.
associated
with any                                                                                              OM: Systems supporting OM must support dynamically defined associations
requirement                                                                                           between entities for the purpose of defining relationships. For example, person-
in RFP                                                                                                to-person (e.g., family relationship, exposure relationship), person-to-place (e.g.,
                                                                                                      household, common place), animal-to-person, object-to-place, person-to-travel.
                                                                                                      (2.3.2.1)
                                                                                                      OM: Entity-to-epi data links must match the entity to their symptoms, survey
                                                                                                      questions, specimens/samples collected, laboratory results, and prophylaxis and
                                                                                                      treatment data. (2.3.2.2)
                                                                                                      OM: Each new case must be able to link an assigned Entity ID to an Event ID
                                                                                                      within the scope of the investigation. (2.3.2.3
                                                                                                      OM: Systems supporting OM require the ability to capture information about
                                                                                                      possible cases and potential contacts from the identification process through the
                                                                                                      treatment and follow-up process, as supported by linkages among entities,
                                                                                                      events, and actions. (2.3.2.4)

KALHD-LHD Input to EDSS                    Appendix B                                                 B-27
                                                       REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                             Requirement
   Line #      Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                  Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                           Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                           Health Reporting
                                                                                                      OM: Laboratory results must be linked to corresponding specimens/samples
                                                                                                      including multiple results from one specimen/sample), and subjects when the
                                                                                                      participating laboratory returns the results. These linkages must unambiguously
                                                                                                      associate multiple laboratory results to case and contact identifiers. (2.3.2.5) –
                                                                                                      (2.3.2.5.a)


                                                                                                      OM - System supporting OM must be able to store lab result/s and link the
PHIN
                                                                                                      result/s to the original lab test request. (2.2.6.9)
requirements
                                                                                                      System supporting OM must store data about lab results. (2.2.6.10.a)
- Not
associated                                                                                            Specimens/samples collected for laboratory testing must be assigned an
with any                                                                                              identifier (i.e., Specimen ID) that is unique within the jurisdiction. (2.2.6.1)
requirement
                                                                                                      The subject of a specimen/sample collected for laboratory testing must be linked
in RFP
                                                                                                      to the specimen/sample by an identifier (i.e., Subject ID) that is unique within the
                                                                                                      jurisdiction. (2.2.6.2)
                                                                                                      Systems supporting OM must be able to store data about the
                                                                                                      specimens/samples that are collected for laboratory testing. Examples of this
                                                                                                      data are: Specimen ID, Subject ID, purpose for test, collection date and time,
                                                                                                      subject type (e.g., human, plant, animal, food), specimen category, specimen
                                                                                                      type, suspected agent, risk indicator (e.g., infectious, radioactive, corrosive),
                                                                                                      person performing specimen/sample collection (including contact information),
                                                                                                      location of collection, and volume and quantity details. – Clinical specimen data,
                                                                                                      environmental sample data, food sample data, (2.2.6.3 (see a-d))
                                                                                                      Chain of custody information for all specimens/samples should be captured.
                                                                                                      (2.2.6.4)
                                                                                                      Chain of custody information for forensic and select agent samples must be
                                                                                                      captured, including the person who collected the sample, the location of
                                                                                                      collection, all people who came into contact with the sample during the
                                                                                                      preparation for shipment to the laboratory, and the acceptance of the package by
                                                                                                      the shipper. (2.2.6.5)
                                                                                                      Systems supporting OM must be able to create a laboratory test request for a
                                                                                                      specimen/sample or group of specimens/samples. More information about
                                                                                                      creating laboratory test requests is found in section 2.5 System Integration and
                                                                                                      Data Exchange of this document. (2.2.6.6)
                                                                                                      Information about batch shipments of specimens/samples that are transferred to
                                                                                                      test laboratories or other facilities must be collected, including the shipper (e.g.,
                                                                                                      UPS, FedEx), shipment tracking number, and the sending organization’s contact

KALHD-LHD Input to EDSS                    Appendix B                                                 B-28
                                                      REQUIREMENT DESCRIPTION                                  KALHD Functional Requirements Additions/Clarifications
                            Requirement
  Line #      Requirement    Reference    Functional Requirements identified in the RFP associated   Included data gathered at the October 3rd meeting and reviews of PHIN
                 Type         Number      with data collection, ELR, Case Management, Analysis/      requirements documents for Countermeasure/Response Administration,
                                          Visualization, Report Development and External Public      Outbreak Management and Early Event Detection
                                          Health Reporting
                                                                                                     information. (2.2.6.7)
                                                                                                     Systems supporting OM should be able to support the inclusion of labeling,
                                                                                                     packaging and shipping instructions (e.g., container type, storage condition,
                                                                                                     preservative), and the shipping manifest with batch shipments of
                                                                                                     specimens/samples. (2.2.6.8)




KALHD-LHD Input to EDSS                   Appendix B                                                 B-29
EDSS High Level Disease Event Scenario (workflow)




KALHD-LHD Input to EDSS                       Appendix B   B-30
Appendix C: KALHD/EDSS Requirements Table Cross Reference
to LHD/OM/CRA

KDHE Rqt:                 LHD TEXT        CRA ref.      OM Ref.
1) DC-1                      Y            2.1.3,4,5     2.1.1,3,4,5
                                          2.1.1.2
                                          2.3.1-5
2) DC-2                      Y            2.1.2         2.1.2
3) DC-3                      Y            2.1.1.1              2.2.2.1,2,3,4
4) DC-4                      Y              -             -
6) DC-6                      Y              -             -
11) DC-11                    Y              -             -
12) DC-12                    Y              -           2.2.4.2.a
13) DC-13                    Y              -             -
16) DC-16                    Y              -             -
25) DC-25                    Y              -             -
26) DC-26                    Y              -             -
27) DC-27                    Y              -           2.2.4.2a, 2.2.4.3a&b&c&d?
28) DC-28                    Y              -           2.2.4.2.d,e,f,g,h/2.2.4.3.d
30) DC-30                    Y              -             -
31) DC-31                    Y              -           2.3.3.1,2,3,4,5
51) CM-2                     Y              -           2.2.1.1 thru 2.2.1.9
71) CM-22                    Y              -             -
75) CM-26                    Y              -             -
76) CM-27                    -              -           2.3.1.1,2,3,4
80) CM-31                    Y              -             -
81) CM-32                    -              -           2.3.1.5 & 2.3.1.6
82) CM-33                    Y              -             -
83) CM-34                    Y              -             -
84) CM-35                    Y              -             -
88) CM-39                    Y              -             -
102) CM-53                   -              -           2.4.10 & 2.4.11
107) CM-58                   Y              -             -
108) CM-59                   -            2.2.1-8 & 2.6.6.1-4
112) CM-63                   -              -           2.2.9.1,2,3
117) AVR-1                   Y            2.7           2.4.12 & 15 & 16
118) AVR-2                   -              -           2.4.2
120) AVR-4                   -              -           2.4.1,3,5,6,7,8,9
122) AVR-6                   -              -           2.4.4
137) RPT-14                  -             2.8.1-8      2.5.2 thru 16

NOT ADDRESSED IN RFP:                     2.4          2.2.7-8
                                          2.5.1-7      2.2.6.1-9
                                          2.6.1-4      2.3.2
                                          2.6.5.1



KALHD-LHD Input to EDSS              Appendix C                                C-1

								
To top