Coordinating Diabetes Care
AUTHORING A FUNCTIONAL REQUIREMENTS ANALYSIS DOCUMENT (FRAD)
Chronic Diseases Group
HIT Standards and Systems Interoperability
March 7, 2017
Health Problem & Need for Information System
•
•
•
29.1 million: People affected by diabetes in the United States2
•
$6.5 billion: Estimated diabetes cost in Maryland, which is largely attributed to poorly managed diabetes and associated
complications including diabetic kidney disease and diabetes retinopathy, the most common complication 1
•
•
•
44%: Percentage of all kidney failure cases where the primary cause is diabetes2
o
o
o
o
9.2%: The percentage of adult population (age adjusted) affected by diabetes in Maryland 3
8 counties in MD: Including baltimore city (12.2%) and somerset county (13%) have some of the highest percentages of adult
population with diabetes in the country4
33%: Percentage of diabetic population in Maryland not receiving an annual dilated eye exam in 2010 (no recent data available) 3
166.6/100,000: Prevalence of diabetes related end-stage renal disease in Maryland3
Poorly managed diabetes can lead to complications that pose great health and economic burdens on patients. Specifically, diabetic
retinopathy (and blindness) and diabetic kidney disease both severely impact patient’s quality of life.
Due to their insidious onset (asymptomatic until advanced stage of disease), timely screening/monitoring and early intervention
become imperative to control disease progress and improve clinical outcome.
Health disparities (especially in Maryland) exist, exposing certain patients to elevated risk.
In Maryland, there is currently no statewide population health decision support system to identity those who are at high risk of
developing these complications.
Overview and Scope of the Information System
❏ We propose a population health decision support system that
● utilizes predictive modeling to identify diabetic patients who are poorly managed and are
at high risk for developing diabetic retinopathy and diabetic kidney disease
● coordinates patient care using master patient index which will allow integration of
records for each individual incorporating all data from various sources/care providers
● alerts appropriate providers for targeted intervention
● generates report for clinical researchers and policy makers
❏ Target population: patients diagnosed with diabetes currently residing in the state of Maryland
❏ Target information sources: hospital EHRs, ambulatory EHRs, diabetes registries, laboratory,
billing, and pharmacy systems
Information System Goal
•
An informatics approach used to collect high quality data on individuals with diabetes validated data from multiple sources reconciled within the repository without creating duplicate
records
•
The system will use the collected data to identify high risk patients within the population who
are risk of developing negative outcomes such as retinopathy and kidney damage - as the
program matures, we intend to identify additional patients at risk for other negative outcomes
such as nerve damage
•
Targeted individuals will be identified by a population health decision support system, generate
alerts and be contacted by healthcare providers in order to intervene and lower the risk of
complications - by the end of the first year, we anticipate a significant decrease in the incidence
of retinopathy and kidney damage compared to the previous year
Business and Technical Actors
- Technical
-
Data repositories (MPI and clinical data repositories)
CRISP (HL7 interface engines to connect to CRISP)
Various health information systems (hospital EHRs, ambulatory EHRs, diabetes registries,
laboratory, pharmacy and billing systems)
- Business
-
Project manager
Board of directors
Engineers/Software developers
Implementation manager
Healthcare providers (Case manager, medical director, clinical management team)
Policy makers
Researchers
HIPAA
Functions that the System Will Support
•
Collect clinical data of diabetes patients from multiple healthcare providers with
jurisdiction and extracted data streams in need
•
Transfer data from different sources into structure or semi-structure data and integrate
it into a single data repository
•
Generate alerts or reminders based on designed algorithms and send them to health
providers
Generate reports on the risk of diabetes complications for system evaluation purpose
•
Non-Functional Requirements
Quality Requirement
Constraints
Usability: The system should be intuitive enough for
new users to catch up within one day of use.
Implementation: The deployment duration of the
system should be less than one year. Extension should
be submitted through formal request with justification.
Reliability, dependability, robustness, safety: All critical
parts of the system should be connected with a backup
generator to ensure constant operation.
Performance: The system should be able to access any
internal page within one second response time.
Supportability, adaptability, maintainability,
portability: The system should allow institute expert to
modify the decision support rule after obtaining
applicable approval.
Interface: The system should be able to interface with
the current information system of institutes.
System security: User authentication to access system
information should not go beyond individual legitimate
need.
Legal: The system should be able to support upgrades to
any required data collection process, rules for
regulatory review, and new code sets if mandated by
government.
Use Case Description and Use Case Diagram
Collect Data
• Extract relevant data from various EHR database
Risk Stratification
• Analyze patient’s characteristics and categorized
it as low risk or high risk to develop diabetes
complication
Alert
• Generate alert for high-risk individuals to their
respective health care providers
Report
• Create report based on risk stratification for
policy maker and researcher
Workflow and
Dataflow
Diagram
System Architecture
Selected Standards
Category
Selections
Data Standards
ICD-10-CM for diagnoses, LOINC for lab tests and results, CPT for encounters and procedures,
NDC for medications
Information Content Standards
Consolidated Clinical Document Architecture (C-CDA) encoded in XML
Information Exchange Standards
HL7, NCPDP SCRIPT
Identifiers Standards
National Provider Identifier (NPI), Patient identification through statistical probabilistic
matching methods, Hospital identifiers, Record identifiers, Test order identifiers
Privacy and Security Standards
The Standards for Privacy of Individually Identifiable Health Information (“Privacy Rule”), The
HIPAA Security Rule
Functional Standards
Procedures, workflows, dataflows, and use cases are described in previous slides
Business Standards
This system is designed to be heavily automated. Data receipt, rules processing, and alert
transmission is all to be done electronically. The process model is described in previous slides.
Hardware and Software Requirements
Category
Requirements
Hardware
The hardware requirements for this system are driven by expected performance. As throughput increases (i.e. as
more provider systems are onboarded), requirements will increase.
Architecture
The system architecture diagram is included on a previous slide.
Processing Power
The interface engine must be able to process [the average expected daily record count] in under one hour. The rules
engine must be able to process [the average expected daily record count] in under one hour. The data repository
must be updated in real time.
Memory
The interface engine must be able to process batches of 10,000 records.
Storage
The data repository must be able to concurrently store the system’s entire history of clinical data records, all master
patient index records, and all required clinical vocabularies. Storage must be expandable to accommodate growing
record counts.
Software
Software requirements are based on supporting data exchange between systems and securing stored data.
Platforms
The operating system must support the programs, functions, and technologies listed below.
Programs, APIs, Internet
Technologies
The interface engine must support data transmission with the provider information systems and the data repository.
The data repository must support database software (Oracle, SQL Server, etc.), security software, and data
transmission with the interface engine and rules engine. The alert system must support data transmission with the
provider systems.
Evaluation Plan
The evaluation plan will follow the following six steps (CDC,1999) :
1. Engage stakeholders
-
Form an evaluation team
-
Engage an evaluator
-
Report status
2. Describe the program [technical level]
-
Describe the system
-
Team’s experiences (does system support data
entry and report generation?)
-
Barriers plus external factors affecting the system
3. Focus the design [usability and functional level]
-
Assess functionality (does system support user
workflow/dataflow?), quality, and barriers to users
-
Priorities: feasibility, utility, usability (is the system
user-friendly?), robustness, reliability
4. Establish metrics and gather evidence [knowledge level]
-
Determine accurate quantitative measures to assess the
complexity and robustness of the system
-
Pilot test
5. Draw conclusions [knowledge level]
-
Examine results against intended outcomes
-
Report on validity, reliability, and reproducibility
6. Develop recommendations
-
Develop recommendations
-
Explain benefits, costs plus challenges
System Development Timeline and Deliverables
Deliverables:
• A data repository that interfaces with health information systems
• A predictive modeling rules engine
• An alert and reporting system
Timeline:
Stagedesign
System
1-3System
months
design
System design
1-3System
mont development
System design
Pilot testing
1-3 months
Period
Months 1-3
Months 4-9
Month 9
Implementation phase 1
Months 10-18
System evaluation
Months 13-21
Operation
Months 22-24
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Functional Standards
Anna Orlova, PhD
Johns Hopkins Bloomberg School of Public Health
Session Outline
►
Functional standards
►
System development process: how to communicate your needs to developers
►
Documenting functional requirements
►
Final assignment
2
Functional Standards – Intro
The material in this video is subject to the copyright of the owners of the material and is being provided for educational purposes under
rules of fair use for registered students in this course only. No additional copies of the copyrighted work may be made or distributed.
HIT Standards Categories
Standards Categories
Examples
Data Standards
Vocabularies and terminologies
Information Content Standards
Reference information models (RIMs), templates, datasets
Information Exchange Standards
Message-based, structured document-based, e-mail-based
standards, IT standards
Identifiers Standards
National Provider Identifier (NPI), record ID, test order ID,
Privacy and Security Standards
Access control, consent directives, other
Functional Standards
Procedures, work processes (workflow, dataflow), checklists,
use cases
Business Standards
Guidelines, best practices
This classification of health IT standards types has been developed by the Health Information Technology Standards Panel (HITSP,
www.hitsp.org) in 2006.
4
Health IT Standards Categories – 2
►
To date, the main focus of the standard development activities has been on:
Data standards (vocabularies and terminologies)
Information content standards (data representation, RIMs)
Message-based, document-based, secure e-mail information exchange standards
IT standards ( programming languages, protocols)
5
National Biosurveillance Use Case
►
Charge:
Biosurveillance Workflow
“Transmit essential data
from electronically
enabled healthcare to
authorized public health
agencies in real-time”
A total of 40 data
elements….
Health Information Technology Standards Panel (HITSP). Biosurveillance Interoperability Specification (IS-02).
URL:http://www.hitsp.org/InteroperabilitySet_Details.aspx?MasterIS=true&InteroperabilityId=49&PrefixAlpha=1&APrefix=IS&PrefixNumeric=02
6
National Biosurveillance Use Case – Selected Standards
HIT Standards Categories
Data Standards
Information Content Standards
Information Exchange Standards
Identifiers Standards
Privacy and Security Standards
Functional Standards
Business Standards
TOTAL
Selected Standards
28
17
46
11
5
1
1
107
Note: This classification of health IT standards types has been developed by the Health Information Technology Standards Panel (HITSP,
www.hitsp.org) in 2006.
7
Communicating your Needs to Developers
Functional standard:
communicating your needs to developers
8
Client-Vendor
Communication
Reality
http://www.projectcartoon.com/ (CC BY 3.0)
9
Functional Standard – 1
►
Functional standard describes work processes that support data exchange between users
(e.g., clinicians and public health practitioners) in a format of functional requirements
analysis document (specification) for electronic communication between settings (e.g.,
clinical and public health settings)
10
Functional Standard – 2
►
Functional standard is a vehicle to assure that the work processes of stakeholders (e.g.,
clinicians and public health practitioners) related to the electronic data exchange are well
understood and agreed upon by stakeholders themselves and then communicated
clearly to the developers as functional requirements (functional standard) for the
information system
11
Functional Standard
►
Functional standard serves as a foundation for the implementation of all other standards
►
To date in the United States, there is no consensus on the format, content, and approach
for how to specify the functional requirements (functional standards)
12
Specifying
functional
requirements
13
System Development Process: How to
Communicate Your Needs to Developers
The material in this video is subject to the copyright of the owners of the material and is being provided for educational purposes under
rules of fair use for registered students in this course only. No additional copies of the copyrighted work may be made or distributed.
Information System Development Process
►
Information system development process is comprised of the following activities:
Requirements elicitation
Design
Development
Pilot testing
Implementation
Evaluation
Deployment
Bruegge B. and Dutoit A.H. Object-Oriented Software Engineering. Pearson Prentice Hall. Upper Saddle River, NJ. 3rd Edition. 1-172
3
Requirements Elicitation – 1
►
During requirements elicitation, the client/user and developer define the problem, the
goal(s), actors, and functions of the information system
►
The client/user selects use case(s); with the help of the developers, they create:
Use case diagrams, workflow, and data flow diagrams
High-level system architecture
Non-functional requirements for the information system
Hardware and software requirements, system evaluation plan
System development timeline and documentation
4
Requirements Elicitation – 2
►
These requirements are documented in a functional requirements analysis document
(specification) that serves as a contract between the client and the developer
►
The specification is written in a natural language and supports communication between
developers and users
5
Requirements Elicitation Includes – 1
►
Specifying goals
►
Specifying high-level system architecture
►
Specifying actors (business and technical)
►
Specifying hardware and software
requirements
►
Specifying functional and non-functional
requirements
►
Specifying system evaluation plan
►
Specifying use cases
►
Specifying project timeline and
documentation
►
Developing models/diagrams
► Use case, workflow, and dataflow
6
Requirement Analysis Document
►
The result of these activities is a description of the system in terms of goals, actors,
functions, and use cases in the format of the Requirement Analysis Document (RAD)
Bruegge B. and Dutoit A.H. Object-Oriented Software Engineering. Pearson Prentice Hall. Upper Saddle River, NJ. 3rd Edition. 1-172
7
Requirements Elicitation Includes – 1
►
Specifying goals
►
Specifying high-level system architecture
►
Specifying actors (business and technical)
►
Specifying hardware and software
requirements
►
Specifying functional and non-functional
requirements
►
Specifying system evaluation plan
►
Specifying use cases
►
Specifying project timeline and
documentation
►
Developing models/diagrams
► Use case, workflow, and dataflow
8
Specifying
Goals
9
Defining the Goal
►
Defining and communicating the purpose of the information system—the problem it will
help to address—by end user to developer is the key issue in the development of an
information system
10
Purpose?
11
How Do We Define Goals of our Systems? – 1
►
CDC Environmental Public Health Tracking Network’s goal is to build a standards-based,
coordinated, and integrated environmental public health tracking (surveillance) network
at the state and national level that will allow linkage and reporting of health effects data
with human exposure data and environmental hazard data
Source: Sandy Thames. (2003). PHIN Conference. Atlanta, GA.
12
How Do We Define Goals of our Systems? – 2
►
CDC Public Health Information Network’s vision is to transform public health by
coordinating its functions and organizations with information systems that enable:
Real-time data flow
Computer assisted analysis
Decision support
Professional collaboration
Rapid dissemination of information to public health, clinical care, and the public
Source: John Loonsk. (May 13, 2003). PHIN Conference. Atlanta, GA.
13
How Do We Define Goals of our Systems? – 3
►
The vision of National Electronic Data Surveillance System (NEDSS) is to have integrated
surveillance systems that can transfer appropriate public health, laboratory, and clinical
data efficiently and securely over the Internet
Source: http://www.cdc.gov/nedss
14
We Define Goals As:
►
To build the system (EPHTN)
►
To transform public health by coordinating its functions and organizations with
information systems (PHIN)
►
To have integrated surveillance systems (NEDSS)
15
So …
►
“The goal of the system is to build the system” … ?
►
This is the main reason for our systems failures
►
The goal of the system cannot be defined as “to build the system”
That is, focus on the process of building, integrating, coordinating, etc.
►
The goal of the system must be defined as “what” the system will do when built
16
Example: Immunization Registries – 1
►
Let’s attempt to define the goal of immunization registries based on this description from
the CDC Web site:
“CDC is continuing the investment to assist states in developing immunization
information systems (registries)—confidential, computerized information systems
that collect vaccination data within a geographic area. By consolidating
vaccination records from multiple health-care providers, generating reminder and
recall notifications, and assessing clinic and vaccination coverage, registries
serve as key tools to increase and sustain high vaccination coverage.
The Healthy People 2010 objective is to increase to 95% the proportion of
children aged
Purchase answer to see full
attachment