Embed Size (px)
Citation preview
Nationwide Health Information Network Committee
Standards for Public Health Data Exchange: Functional Requirements Standard for
Diabetes Care Management and Surveillance
Project Report: 2008
Baltimore, Maryland
Report to the Health Resources and Services Administration Requisition/Purchase Request No.: 07-S250-0827-AB
2
The Public Health Data Standards Consortium (PHDSC, The Consortium) is a national non-profit membership based organization of federal, state and local health agencies; professional associations, academia; public and private sector organization; international members; and individuals. Its goal is to empower the healthcare and public health communities with health information technology standards to improve individual and community health. The Consortium is committed to bringing a common voice from the public health community to the national efforts of standardization of health information technology and population health. To fulfill this mission the Consortium:
Identifies priorities for the new national standards for population health; Promotes the integration of health-related data systems to meet the health data
needs of public and private organizations, agencies and individuals; Participates in national and international efforts on the standardization of health-
related information; Represents public health interests in standards development organizations, data
content communities & standards harmonization entities; and Educates the public health community about health information technology
standards and the health information technology community about public health.
624 N. Broadway, Room 382 Baltimore, MD 21205
Phone: (410) 614-3463 Fax: (410) 614-3097
www.phdsc.org
3
DISCLAIMER
The material in this document has not been subject to agency review and approval for
publication as a HRSA report. Mention of trade names, products, or services, does not convey,
and should not be interpreted as conveying, official HRSA approval, endorsement, or
recommendation.
4
CONTRIBUTING ORGANIZATIONS AND ACKNOWLEDGEMENTS
Public Health Data Standards Consortium (PHDSC, Consortium)
PHDSC was responsible for the overall conduct of this project including the preparation of this
report. Dr. Anna O. Orlova, PHDSC’s Executive Director and Visiting Associate Professor,
Johns Hopkins School of Medicine was a Principal Investigator of the project. The report has
been reviewed by members of the Consortium.
Health Resources and Services Administration (HRSA)
HRSA provided funding for this project. Ms. Jessica Townsend and Dr. Michael Millman, Office
of Planning and Evaluation guided the development and the conduct of the project activities.
Wisconsin Department of Health and Family Services (WDHFS)
WDHFS served as a site for project activities. Dr. Laurence Hanrahan, Director of Public Health
Informatics, Chief Epidemiologist, Division of Public Health, Bureau of Health Information and
Policy guided the development of the project design and provided the review of the project
report.
5
TABLE OF CONTENTS
EXECUTIVE SUMMARY ........................................................................................................................................... 8
CURRENT ENVIRONMENT – PROBLEMS WITH HEALTH INFORMATION TECHNOLOGY IN CHRONIC DISEASE CARE MANAGEMENT, SURVEILLANCE, AND PREVENTION ............................... 11
SOLVING PROBLEMS OF INFORMATION SYSTEMS NON-INTEROPERABILITY – EFFORTS TO DATE .......................................................................................................................................................................... 13
WORKING WITH USERS........................................................................................................................................... 13 WORKING WITH VENDORS ...................................................................................................................................... 14
PROJECT GOAL, APPROACH, PARTNERS, AND METHODOLOGY ......................................................... 15
FUNCTIONAL REQUIREMENTS ANALYSIS DOCUMENT FOR ELECTRONIC HEALTH INFORMATION EXCHANGES BETWEEN CLINICAL AND PUBLIC HEALTH INFORMATION SYSTEMS IN WISCONSIN: DIABETES CARE MANAGEMENT AND SURVEILLANCE .......................... 18
PROBLEM OVERVIEW.............................................................................................................................................. 18 HEALTH INFORMATION EXCHANGES AND DIABETES CARE MANAGEMENT IN WISCONSIN ................................... 18 GOALS OF HEALTH INFORMATION EXCHANGES BETWEEN CLINICAL AND PUBLIC HEALTH INFORMATION
SYSTEMS IN DIABETES CARE MANAGEMENT: GLYCEMIC CONTROL..................................................................... 21 ACTORS – PARTICIPANTS IN HEALTH INFORMATION EXCHANGES: GLYCEMIC CONTROL .................................... 21 FUNCTIONS – NEEDS OF CLINICIANS AND PUBLIC HEALTH PRACTITIONERS IN HEALTH INFORMATION
EXCHANGES: GLYCEMIC CONTROL ........................................................................................................................ 22 NON-FUNCTIONAL REQUIREMENTS ....................................................................................................................... 22 DATA SOURCES ...................................................................................................................................................... 22 GLYCEMIC CONTROL USE CASE ............................................................................................................................ 24 HEALTH INFORMATION EXCHANGE ARCHITECTURE .............................................................................................. 30
INFORMING THE DEVELOPMENT OF INTEROPERABLE HEALTH INFORMATION EXCHANGES: IHE CARE MANAGEMENT TECHNICAL FRAMEWORK** ............................................................................. 31
PROBLEM OVERVIEW.............................................................................................................................................. 31 TECHNICAL ACTORS ............................................................................................................................................... 32 SCOPE..................................................................................................................................................................... 34 DIABETES PATIENT CARE MANAGEMENT EXAMPLE .............................................................................................. 37 PRE-CONDITIONS AND POST-CONDITIONS ............................................................................................................. 38 TRANSACTION / OPTIONS / GROUPING .................................................................................................................. 39 CODED TERMINOLOGIES ........................................................................................................................................ 42 PROCESS FLOW ...................................................................................................................................................... 42
RESULTS .................................................................................................................................................................. 44
WORKING WITH USERS: FRAD FOR DIABETES CARE MANAGEMENT AND SURVEILLANCE IN WISCONSIN ......... 44 WORKING WITH VENDORS: IHE CARE MANAGEMENT TECHNICAL FRAMEWORK ................................................. 44
DISCUSSION ............................................................................................................................................................ 50
WORKING WITH USERS........................................................................................................................................... 50 FACILITATING THE DEVELOPMENT OF HEALTH INFORMATION EXCHANGES IN WISCONSIN.................................. 50 WORKING WITH VENDORS ...................................................................................................................................... 51
CONCLUSIONS AND NEXT STEPS .................................................................................................................... 52
ATTACHMENT 1: WISCONSIN ESSENTIAL DIABETES MELLITUS CARE GUIDELINES .............................................. 53 ATTACHMENT 2: ORGANIZATIONS – ENDORSERS OF THE WISCONSIN DIABETES STRATEGIC PLAN .................. 54 ATTACHMENT 3: DIABETES MELLITUS CARE DATA SOURCES IN POPULATION HEALTH SURVEILLANCE IN
WISCONSIN ............................................................................................................................................................. 56 ATTACHMENT 4: IHE CARE MANAGEMENT PROFILE DEFINITIONS FOR ACTORS AND TRANSACTIONS ............... 57
6
TABLE OF TABLES
Table 1 - HbA1c Levels ................................................................................................................ 20
Table 2 - Diabetes Mellitus Care and Surveillance: Glycemic Control Use Case Data Set ......... 23
Table 3 - Diabetes Mellitus Care: Glycemic Control Use Case Description for HIE .................. 24
Table 4 - Transaction by Technical Actor .................................................................................... 40
Table 5 - Transaction Options by Technical Actor ....................................................................... 41
Table 6 - Examples of Clinical and Public Health Registry Functions ........................................ 46
Table 7 - Diabetes Mellitus Care Data Set for the Wisconsin Diabetes Surveillance .................. 48
7
TABLE OF FIGURES
Figure 1 - UML Use Case Diagram: Glycemic Control ............................................................... 26
Figure 2 - UML Use Case Diagram: Glycemic Control – First Patient Encounter ...................... 27
Figure 3 - UML Use Case Diagram: Glycemic Control – Second Patient Encounter .................. 28
Figure 4 - Glycemic Control: Workflow/Dataflow Diagram ....................................................... 29
Figure 5 - High Level Architecture for Wisconsin Health Information Exchanges ..................... 30
Figure 6 - Care Management Health Information Exchange Architecture Overview .................. 33
Figure 7 - Care Management Process Flow .................................................................................. 38
Figure 8 - Care Management Technical Actor Diagram .............................................................. 40
Figure 9 - Care Management Process Flow .................................................................................. 43
8
Executive Summary
The Nationwide Health Information Network (NHIN) is being developed to provide a secure,
nationwide, interoperable health information infrastructure that will connect providers,
consumers, and others involved in supporting health and healthcare. This critical part of the
national health IT agenda will enable health information to follow the consumer, be available for
clinical decision making, and support appropriate use of healthcare information beyond direct
patient care so as to improve health.1 The national strategy to develop a Nationwide Health
Information Network depends not only upon Electronic Health Record (EHR)-based systems
(EHR-S) deployed in clinical practice, but the integration of both clinical and public health
information systems into regional electronic health information exchanges (HIEs).2
The rationale for the integration of clinical EHR-S and public health information systems can be
seen in the area of chronic disease care management. While a growing number of healthcare
organizations have adopted health information technology (HIT) applications (EHR-S and
clinical registries) as primary tools for improving chronic disease care, so too have 3 public
health agencies been involved in the activities designed to improve chronic disease care
management, surveillance, and prevention. An important public health tool in this regard is a
disease-specific registry that contains information about disease prevalence, trends, and risk
factors among a population within a jurisdiction. These registries include information about
chronic diseases such as diabetes, asthma, cancer, etc.. Both clinical and public health
information systems, however, have been developed as ―siloed‖, stand-alone systems which
could lead to a lost opportunity to provide synergy between public health and clinical provider
contributions to chronic disease control and prevention.
Building interoperable health information systems requires users (clinicians and public health
professionals), who understand the information exchange content, and EHR-S vendors, who
build these exchanges, to work together in a new way. Both users and EHR-S vendors may no
longer focus only on their individual practice/program’s HIT application(s) but have to assure
that their applications are interoperable with multiple EHR-Ss and public health information
systems involved in the HIE in a particular jurisdiction and/or nationwide.
This report describes a standardized approach for EHR-S users and their vendors to work
together to assure interoperability of individual EHR-Ss, clinical registries, and public health
registries. The key to the approach piloted in this study was the manner in which users’
functional requirements were constructed to represent the needs of a particular practice or
program. This was accomplished, first, through the use of the Functional Requirement Analysis
Document methodology developed by the Public Health Data Standards Consortium (PHDSC) to
describe user needs for electronic information exchanges; and second, via the development of a
1 Department of Health and Human Services (HHS), National Health Information Network, January 29, 2009. URL:
http://www.hhs.gov/healthit/healthnetwork/background/ 2 Department of Health and Human Services (HHS), The ONC Coordinated Federal Health IT Plan 2008-2012. June
3, 2008. URL: http://www.hhs.gov/healthit/resources/HITStrategicPlan.pdf 3 Using Computerized Registries in Chronic Disease Care. First Consulting Group. California Healthcare
Foundation. 2004. URL:
http://www.chcf.org/documents/chronicdisease/ComputerizedRegistriesInChronicDisease.pdf
9
standardized technical framework for chronic care management that vendors could readily use in
designing and developing interoperable HIT products.
We worked with two partners in this project; organizations that represented users and vendors,
respectively: the Wisconsin Department of Health and Family Services (WDHFS) Diabetes
Control Program4 and Integrating the Healthcare Enterprise
5 - a collaborative of EHR-S
vendors and health professionals.
The report describes the development of the Functional Requirement Analysis Document
(FRAD) for interoperable clinical and public health information systems using the example of
diabetes care management and surveillance in Wisconsin. Diabetes Mellitus was selected as an
example of chronic disease care management because it is one of the most prevalent chronic
conditions both in Wisconsin and in the United States.
The term ―FRAD‖ was first introduced in the HRSA-funded PHDSC’s project ―Developing a
Vision for Functional Requirements Specification for Electronic Data Exchange between
Clinical and Public Health Settings‖, (2006).6 The FRAD represents a shorter version of the
Functional Requirement Analysis Document7 and follows the standard software requirement
elicitation and documentation process where users and developers define the goals of the information
system, the actors (stakeholders and information systems) that will interact with the system, the
functional and non-functional requirements of the system, the use case scenario(s), the data sources
used by the system, and the workflow and dataflow that the system will support. The purpose of
FRAD is to help users of the system specify (explain) system requirements, i.e. - user needs that the
system must support, for system developers in an organized way and in a language that both users
and developers can understand.
The Wisconsin FRAD was focused on the Glycemic Control use case, the main diabetes
screening and disease monitoring tool, and specified the information exchange goals, actors, user
functions, data sources, clinical and public health workflow and dataflow, and data content
related to information exchange within the scope of the use case. The WDHFS is planning to use
the FRAD in the Wisconsin HIE demonstration project in the spring of 2009.
In addition, we conducted the review of literature on clinical registries and the Wisconsin
Diabetes Mellitus Care Guidelines and Wisconsin Diabetes Surveillance Reports to generate a
list of clinical care and public health surveillance functions, and a list of clinical and public
health data types for comprehensive diabetes care management and surveillance to be used in
HIEs in Wisconsin. This effort helped in understanding the relationships between clinical and
public health registries in terms of using diabetes care EHR-S data for aggregated data analysis
4 Wisconsin Department of Health and Family Services; URL: http://dhfs.wisconsin.gov/
5 Integrating the Healthcare Enterprise (IHE). URL: http://www.himss.org/ASP/topics_ihe.asp:
6 Developing a Vision for Functional Requirements Specification for Electronic Data Exchange between Clinical
and Public Health Settings: Examples of School Health and Syndromic Surveillance in New York City. Public
Health Data Standards Consortium. 2006, 40p plus attachments. URL:
http://www.phdsc.org/about/committees/pdfs/nhin/NYC_School_Health_SSS_Spec_Final_103006.pdf Last
accessed on February 5, 2008. 7 Bruegge B. and Dutoit A.H. Object-Oriented Software Engineering. Pearson Prentice Hall. Upper Saddle River,
NJ. 2nd edition: 1-172.
10
at the practice level (clinical registries) and community level (public health registries). Functions
and data content of registries documented in this project could be used in informing the
development of common architecture to support both types of registries in future electronic
health information exchanges. We envision expanding the function and data content lists by
adding functionalities and data content for other chronic conditions, e.g., asthma, cardiovascular
diseases, etc.
The Wisconsin FRAD enabled us, working with EHR-S vendors at the Integrating the
Healthcare Enterprise (IHE), to develop a Chronic Care Management Technical Framework8 for
interoperable EHR-S-based HIT applications. The Framework serves as a standardized umbrella
technical specification for the development of the IHE Integration Profiles9 and Content
Profiles10
for HIT applications in chronic disease care management and surveillance. In the
future, we are planning to develop the Diabetes Content Profile for the Glycemic Control Use
Case and the Content Profile on standardizing queries to EHR-S and to clinical registries on
patient-level information for diabetes care management and on population-level information for
diabetes population-based surveillance.
This project strengthened collaboration between public health and EHR-S vendors and helped to
establish a new IHE domain ―Public Health, Research, and Quality‖ that will focus on public
health information systems’ interoperability with EHR-S systems. This domain was created in
addition to other domains at IHE that represent user’s perspectives in the development of
interoperable EHR-S-based systems such as Cardiology, Laboratory, Patient Care Coordination,
Radiology, etc.
The report includes several sections that describe HIT applications in chronic disease care
management and surveillance, the rationale for user and EHR-S vendors collaboration in the HIT
applications design and development, the project methodology, the two deliverables - the
Wisconsin FRAD for the Glycemic Control use case and the IHE Care Management Technical
Framework document, the discussion of the project findings related to the development of these
two documents, and the next steps in strengthening users and EHR-S vendors collaboration
towards achieving clinical and public health systems interoperability.
8 IHE Technical Framework is an umbrella technical document that describes the relationship between multiple
EHR-S-based HIT applications to enable interoperability across applications, e.g., Care Mngt Technical Framework. 9 IHE Integration Profile is a generic technical specification for the development of interoperable EHR-S-based
application, e.g., Cross-Document Sharing Integration Profile. 10
IHE Content Profile is a generic technical specification that defines the content for information exchanges for a
clinical or public health domain, e.g., Immunization, Cancer, Diabetes, etc..
11
Current Environment – Problems with Health Information Technology in Chronic Disease Care Management, Surveillance, and Prevention
Chronic diseases—such as heart disease, cancer, and diabetes—are the leading causes of death
and disability in the United States, accounting for 70% of the 1.7 million deaths each year in the
United States. These chronic diseases also cause major limitations in daily living for almost 1 out
of 10 Americans or about 25 million people. Although chronic diseases are among the most
common and costly health problems, they are also among the most preventable.11
The chronic
care delivery model includes self-management, care planning with a multidisciplinary team, and
on-going assessment and follow-up. Adopting healthy behaviors such as eating nutritious foods,
being physically active and avoiding tobacco use can prevent or control the devastating effects of
these diseases. 12
The Institute of Medicine emphasized that ―good information about patients and their care is
important to improve healthcare delivery outcomes‖.13
Clinical disease registries have been used
by clinicians to track patient information within the practice; reach their patients with gaps in
care and assure that appropriate and timely care is provided during patient visits; and evaluate
practice’s performance. The first clinical registries were developed in 1980s. With increasing
evidence that a more systematic information management approach helps improve healthcare
outcomes, a growing number of provider organizations adopted registries as a primary tool for
improving chronic care.14
Clinical registries focus on selected information relevant to one or more chronic diseases, i.e.,
diabetes registries, cancer registries, asthma registries, multiple conditions registries, etc. Data
for these registries comes from practice management systems, claims systems, laboratory
systems, pharmacy systems, and EHR-Ss. Clinical registries are built as stand-alone systems to
supplement EHR-Ss15
as they manage a much smaller amount of patient information than EHR-
S. Most clinical registries operate separately from the practice’s EHR-S though some EHR-S
products include registry functions.
Clinical registry applications were developed as homegrown systems (designed and programmed
locally); however, some use commercial registry products and/or open source products including
those developed by governmental agencies, e.g., Cardiovascular and Diabetes Electronic
Management System (CVDEMS)16
developed for organizations participating in chronic disease
11
Centers for Disease Control and Prevention (CDC). National Center for Chronic Disease Prevention and Health
Promotion (NCCDPHP). URL: http://www.cdc.gov/nccdphp/ 12
Bodenheimer T. et al. Improving Primary Care for patients with Chronic Illness: The Chronic Care Model, Part 2.
JAMA, 2002: 288(15): 1909-1914. 13
Institute of Medicine. Crossing the Quality Chasm. National Academy P, Washington DC, 2001. 14
Using Computerized Registries in Chronic Disease Care. First Consulting Group. California Healthcare
Foundation. 2004. URL:
http://www.chcf.org/documents/chronicdisease/ComputerizedRegistriesInChronicDisease.pdf 15
In this report, terms Electronic Health Record Systems (EHR-S) and Electronic Medical Record Systems (EMR-
S) are used interchangeably. 16
Health Resources and Services Administration (HRSA). Bureau of Primary Health Care. Cardiovascular and
Diabetes Electronic Management System (CVDEMS) Manual. URL:
http://www.cpca.org/healthcollabs/documents/CVDEMS%20USER%20MANUAL.pdf
12
management programs of the Bureau of Primary Health Care, Health Resources and Services
Administration (HRSA). Registry applications reside on a personal computer (PC) or network
server at the provider organization; they may be hosted by a commercial vendor or an external
entity at another location, i.e., an organization that provides data integration services including
registry services.
Public health agencies have been involved in the activities related to chronic disease care
management and disease surveillance and prevention. To support these activities public health
agency programs/divisions maintain disease-specific registries that contain information about
chronic conditions prevalence, trends, risk factors, etc., among populations within a jurisdiction.
These registries are populated with data from clinical settings (mostly sent via paper-based forms
or submitted electronically through program-specific web-based portals) as well as with data
collected through various statewide and national surveys, including the Behavioral Risk Factor
Surveillance Survey (BRFSS) that provides information regarding a healthy lifestyle, i.e.,
physical activity, tobacco use, nutrition information, etc..
Public health registry applications operate as stand-alone information systems that are not
interoperable with other information systems within an agency. As clinical registries, public
health registry applications were developed as homegrown systems; some use commercial
registry products; and/or open source products including those developed by governmental
agencies. Public health registry applications reside on a personal computer (PC) or agency’s
network server.
With the national effort on developing a Nationwide Health Information Network of regional
electronic health information exchanges (HIEs) built upon EHR-Ss deployed in clinical settings,
various clinical and public health information system applications have to be integrated in the
HIEs.17
HIEs have to assure that (1) EHR-Ss and clinical registries built for individual practices
can exchange data across practices, i.e., become interoperable; and (2) clinical EHR-Ss and
registries can exchange data with public health registries.
To enable these data exchanges, HIEs have to support functions of various disease-specific
clinical and public health registries. This requires users (clinicians and public health
professionals), who understand the information exchange content, and EHR-vendors, who build
these exchanges, to work together in a new way. Both users and EHR-S vendors may no longer
focus only on their individual practice/program’s HIT application(s); now users and vendors
have to assure that their individual applications are interoperable with multiple EHR-Ss and
other registries involved in the HIE in a particular jurisdiction and/or nationwide.
This report describes a potential approach of how users and EHR-S vendors can work together to
assure interoperability of individual EHR-Ss and clinical and public health registries within
HIEs.
17
Department of Health and Human Services (HHS), The ONC Coordinated Federal Health IT Plan 2008-2012.
June 3, 2008. URL: http://www.hhs.gov/healthit/resources/HITStrategicPlan.pdf
13
Solving Problems of Information Systems Non-Interoperability – Efforts to Date
Working with Users
Building HIEs between multiple clinical settings and public health programs requires users to
share HIT applications. In order to do so, users have to achieve a consensus on (a) common
functionalities for interoperable EHR-based clinical and public health information systems across
multiple health care organizations and public health programs; and (b) common data sets to be
exchanged. To assure successful deployment of the interoperable EHR-based products, users
also have to understand the work processes and data flows related to information management of
entities (stakeholders, actors) involved in the exchange, i.e., an individual practice, public health
program, laboratory, etc.. This requires an organized approach in documenting functions, data
sets, work processes, and data flow in information management at these entities as they relate to
patient care management, e.g., patient visits, patient follow-up, practice management, health
education, etc., and population-based surveillance, e.g., data reporting to public health
program(s), specific public health program(s) activities, etc. For an individual practice/program
these processes can be documented (specified) in the Functional Requirement Analysis
Document (FRAD) – a standardized information system design specification that describes user
needs for an information technology (IT) application. 18
FRAD serves as a functional standard for
HIT application.19
However, in the United States, FRADs have not been widely used by users in guiding the design
of HIT applications. The Health Information Technology Standards Panel (HITSP)20
Interoperability Specification for the national Biosurveillance Use Case identified no functional
standards as references. Users are largely unaware of their role in the information systems design
and are often lacking informatics skills needed to participate in the FRAD development.
With the support from HRSA, the Public Health Data Standards Consortium (PHDSC) has
developed 3 FRADs for the public health domains of school health, syndromic surveillance,21
and diabetes (described further in this report) in two jurisdictions, New York City and the State
of Wisconsin. The PHDSC has been advocating for the use of functional standards (FRADs) to
18
Bruegge B. and Dutoit A.H. Object-Oriented Software Engineering. Pearson Prentice Hall. Upper Saddle River,
NJ. 2nd Edition. 1-172. 19
Towards a Functional Standard on Electronic Data Exchange between Clinical Care and Public Health. Final
Report to the Health Resources and Services Administration. Baltimore, MD: Public Health Data Standards
Consortium; 2007. URL:<http://www.phdsc.org/about/committees/pdfs/PHDSC-HRSA%20Panel%20-
%20December%205-6%202006%20-%20Final%20Report.pdf. 20
Health Information Technology Standards Panel (HITSP). [cited 29 Mar 2008]; Available from:
http://www.ansi.org/standards_activities/standards_boards_panels/hisb/hitsp.aspx?menuid=3 21
Developing a Vision for Functional Requirements Specification for Electronic Data Exchange between Clinical
and Public Health Settings: Examples of School Health and Syndromic Surveillance in New York City. Public
Health Data Standards Consortium. 2006, 40p plus attachments. URL:
http://www.phdsc.org/about/committees/pdfs/nhin/NYC_School_Health_SSS_Spec_Final_103006.pdf
14
become a standard informatics practice in the public health agencies to specify public health
information systems requirements to vendors from the user perspectives.22
FRAD is a product of the requirement analysis phase of the information system design.
Specifying user needs for an IT application in IT language and format, FRAD allows users to
control the application design and development process to assure that their needs specified in the
FRAD are adequately translated into the IT product. Forty to sixty percent of errors in systems
have been traced back to the requirements analysis phase; 70-85% of total revisions can be
attributed to requirements errors.23
Lack of FRAD use can significantly jeopardize the
development of successful HIT applications.
FRADs are critical in the development of interoperable HIEs. Because the FRAD describes an
individual application design in a structured way (HIT application goal, actors, functions, data
sources, workflow and data flow models, and a high level architecture), comparison of individual
FRADs allows users to distill common features across multiple individual applications within
HIEs and to build a consensus among users of different HIT products on those features, setting a
common ground for interoperability of HIT applications under regional HIEs and a NHIN.
Working with Vendors
IT vendors use proprietary technical documentations to describe the design and development of
IT application. Vendor’s proprietary requirement analysis documents (RADs) of user needs for
IT application design (often written without direct user involvement) and Information System
(IS) Development Specifications 24
describe a particular application that may not include
requirements to exchange data across the applications unless specifically requested by users.
The Integrating the Healthcare Enterprise (IHE) – a collaborative of EHR-S vendors and health
professional associations - has been focusing on enabling interoperability (information
exchanges) across HIT products. IHE develops specific technical documents for HIT vendors
(Technical Frameworks, Integration Profiles, Content Profiles, etc.) which allow vendors to build
their individual systems in compliance with common interoperability standards, thereby enabling
HIEs. As the result, the proprietary RADs and IS development specifications have to comply
with the consensus-based common IHE technical specifications used across vendors. In its
process, IHE relies on the user input (professional associations) guiding the development of the
IHE technical documents.
Based upon invitation from IHE to represent public health in the development of interoperability
standards, the PHDSC has been working to engage the public health community in helping
vendors to define unified public health requirements for interoperable EHR-S-based clinical and
22
PHDSC/HRSA Expert Panel in Electronic Data Exchanges; 2006 December 5-6, 2006; Washington, DC: Public
Health Data Standards Consortium and Health resources and Services Administration; 2006. p. URL:
http://www.phdsc.org/about/committees/nhin.htm 23
Requirement Management. Leffingwell D, Editor, 1997. URL:
http://www.serena.com/docs/repository/products/rm/wp900-001-0505.pdf 24
Bruegge B. and Dutoit A.H. Object-Oriented Software Engineering. Pearson Prentice Hall. Upper Saddle River,
NJ. 2nd Edition. 1-172.
15
public health information systems.25
The PHDSC has proposed using FRAD as a tool for
communicating standardized user requirements into the IHE process.
Project Goal, Approach, Partners, and Methodology
The goal of this project was to develop an approach of how users and EHR-S vendors can work
together to assure interoperability of individual EHR-Ss, clinical registries, and public health
registries within HIEs by standardizing the health information technology (HIT) application
design and development.
The objectives of this project were to:
(1) To use FRAD methodology to document functional requirements for interoperable clinical
and public health information systems for chronic care management, surveillance and
prevention
(2) Translate the FRAD content into technical documentation for vendors to build interoperable
standardized EHR-S-based clinical-public health information system.
Our approach was based on (1) working with users on documenting functional requirements for
the design of an individual HIT application for a selected domain based on the FRAD
methodology described below; and (2) using FRAD content in working with EHR-S vendors at
IHE to inform the development of standardized technical documents (Technical Frameworks,
Integration Profiles, Content Profiles, etc) which EHR-S vendors will use to build interoperable
HIT products for HIEs.
Diabetes Mellitus was selected as an example of the chronic disease management domain for this
project in consultation with HRSA. This domain was selected because of the high prevalence of
diabetes in the United States. From 1980 through 2005, the number of Americans with diabetes
increased from 5.6 million to 15.8 million. People aged 65 years or older account for
approximately 38% of the population with diabetes.26
We worked with two partners in this project, i.e. organizations who represented users and
vendors. The Wisconsin Department of Health and Family Services (WDHFS)27
participated in
the development of the functional requirements analysis document for diabetes care management
and surveillance from the user perspectives. Using the Wisconsin FRAD, we further worked with
the Integrating the Healthcare Enterprise to develop a Technical Framework for interoperable
HIT applications in chronic disease care management.
25
Building a Roadmap for Health Information Systems Interoperability for Public Health. Public Health Data
Standards Consortium. 2008, 70pp. URL: http://static.ihe.net/Technical_Framework/upload/IHE-
PHDSC_Public_Health_White_Paper_2008-07-29.pdf 26
Centers for Disease Control and Prevention (CDC). Diabetes Data and Trends. URL
http://www.cdc.gov/diabetes/statistics/prev/national/figpersons.htm 27
Wisconsin Department of Health and Family Services; URL: http://dhfs.wisconsin.gov/
16
The PHDSC FRAD development methodology28
was used in the development of the WDHFS
FRAD for diabetes care management and surveillance. The WDHFS Public Health Information
Network (WI-PHIN) and WDHFS Diabetes Prevention and Control Program (Program) served
as examples of public health programs to be involved in HIEs in Wisconsin.
The FRAD document was developed based on the Wisconsin Diabetes Mellitus Guidelines 29
(Attachment 1) and was focused on the Glycemic Control use case. The diabetes domain-specific
information for the FRAD was obtained via (a) an interview with the WDHFS Diabetes
Prevention and Control Program staff in November 2007, (b) review of the Program reports and
publications; and (c) literature search. In the interview we asked questions about the Program
staff’s current work practices and data-generating activities related to diabetes care management,
disease surveillance and prevention, as well as their vision for future electronic HIEs. The FRAD
was validated by the WDHFS informatics staff. The PHDSC Nationwide Health Information
Network Committee served as an Advisory Panel for the development of the Wisconsin FRAD.
Because both clinical and public health registries play significant roles in diabetes care
management and surveillance, we conducted broad analysis of clinical and public health registry
functions as well as analysis of data content for both systems used in diabetes care management
and surveillance via a literature search and by reviewing the Program’s annual surveillance
reports.30,31
We further worked with IHE to propagate the Wisconsin FRAD for diabetes care management
and surveillance into the IHE Care Management Technical Framework (Framework) document
that will serve as an umbrella specification for the future development of the IHE Integration
Profiles and Content Profiles to assure interoperability between HIT applications in chronic
disease care management and surveillance.
In addition to working on the development of the IHE Care Management Technical Framework,
we also participated in the development of IHE Immunization Registry Content Profile and IHE
Cancer Registry Content Profile. This work was conducted in partnership with the American
Immunization Registry Association (AIRA) and North America Association of Central Cancer
Registries (NAACCR) & CDC Cancer Registries Program, respectively. Though this work was
out of scope of the HRSA-funded activities on diabetes care management described in this
report, it helped PHDSC to build a stronger presence at IHE, allowed us to better understand IHE
processes on the development of their deliverables (Frameworks, Integration and Content
Profiles) that will be used in our future work on specifying data content for diabetes case
28
Developing a Vision for Functional Requirements Specification for Electronic Data Exchange between Clinical
and Public Health Settings: Examples of School Health and Syndromic Surveillance in New York City. Public
Health Data Standards Consortium. 2006, 40p plus attachments. URL:
http://www.phdsc.org/about/committees/pdfs/nhin/NYC_School_Health_SSS_Spec_Final_103006.pdf Last
accessed on February 5, 2008. 29
Wisconsin Essential Diabetes Mellitus Care Guidelines. 2004. URL
http://dhfs.wisconsin.gov/health/diabetes/PDFs/GLIntro.pdf 30
2005. Wisconsin Diabetes Surveillance Report. URL: http://dhfs.wisconsin.gov/health/diabetes/survrpt.htm
Last accessed February 13, 2008. 31
2006. Wisconsin Diabetes Surveillance Report. URL: http://dhfs.wisconsin.gov/health/diabetes/survrpt.htm
Last accessed February 13, 2008.
17
management and surveillance information exchanges, and allowed us to better understand
commonalities across different registries.
In working with IHE, we used the IHE consensus-based methodology that included participation
in over twenty (20) 2-hour conference calls and four (4) 2-3 day face-to-face meetings of the IHE
Patient Care Coordination (PCC) and Information Technology Infrastructure (ITI) Technical
Committees to contribute in writing and reviewing of the Framework document and other
relevant technical documentation.
Sections that follow present the Wisconsin FRAD and the IHE Care Management Technical
Framework.
18
Functional Requirements Analysis Document for Electronic Health Information Exchanges between Clinical and Public Health Information Systems in
Wisconsin: Diabetes Care Management and Surveillance
Problem Overview
In Wisconsin, approximately eight percent of adults (329,000) have diabetes. Additionally, an
estimated 3,000 children in Wisconsin have been diagnosed with diabetes. The prevalence of
diabetes has increased in the past decade. Using a three-year moving average, diabetes has
increased 33% from 1989 to 2001 (4.2% to 5.6%). Furthermore, an estimated 836,000 persons in
Wisconsin aged 40-74 years have pre-diabetes. Diabetes is more prevalent in certain racial and
ethnic populations, including Hispanics/Latinos, African Americans, and American Indians.
The cost of diabetes in Wisconsin is staggering, totaling $2.8 billion in 1998 including estimates
of direct annual medical care costs of $1.26 billion and indirect costs (lost workdays, restricted
activity days, mortality, and permanent disabilities) of $1.54 billion. While diabetes is currently a
serious health issue, the prevalence is expected to grow each year as the population diversifies
and ages and as the number of overweight and obese people increase in Wisconsin. Being
overweight or obese increases the risk of developing type 2 diabetes; the epidemics of diabetes
and overweight/obesity are strongly associated. The Wisconsin Diabetes Strategic Plan, 2004-
2009 provides a framework for Wisconsin organizations to mobilize around a set of common
goals affecting all areas of diabetes care and prevention.32
Various organizations in Wisconsin
endorsed the Strategic Plan (Attachment 2). Health Information Exchanges and Diabetes Care Management in Wisconsin
Under the Governor’s Executive Order, the eHealth33
Care Quality and Patient Safety Board
(Board) has been established to develop a roadmap for statewide use of EHR-Ss to share
information and to improve patient care while protecting patient privacy. The goal is to have
100% adoption of EHR-Ss by healthcare providers and to have appropriate exchanges of health
information within these systems in five years.34
The Wisconsin Department of Health and Family Services (WDHFS) is one of the key
participants in the Wisconsin State eHealth Initiative. Public health data systems maintained by
the Department should be ready to receive/exchange data from/with providers’ EHR-S
electronically via Electronic Health Record – Public Health (EHR-PH) interoperable information
exchanges.
32
Wisconsin Diabetes Strategic Plan. 2004-2009. URL:
http://dhfs.wisconsin.gov/health/diabetes/strategicplan.HTM Last accessed on February 5, 2008. 33
The term ―eHealth or e-health‖ stands for the electronically enabled health care, i.e., HIT applications adopted in
health care. 34
State of Wisconsin. eHealth Care Quality and Patient Safety Board. URL:
http://www.wisgov.state.wi.us/appointments_detail.asp?boardid=203.
19
The Wisconsin Essential Diabetes Mellitus Care Guidelines35
(Attachment 1) require physicians
from various specialties (primary care providers, endocrinologists, cardiologists,
ophthalmologists, dentists, etc.) and various clinical settings to coordinate patient care and
exchange patient information. Thirteen primary care clinics at Thedacare in northeastern
Wisconsin have been using a clinical registry for chronic care management tracking of the
National Committee for Quality Assurance (NCQA)-recommended services and interventions
for chronic disease and preventive care.36
The WDHFS Wisconsin Collaborative Diabetes
Quality Improvement Project37
is aimed to evaluate the implementation of the Guidelines by
comparing data from participating healthcare management organizations (HMOs). The
performance on all Comprehensive Diabetes Care measures38
in Wisconsin has improved as
follows:
↑ LDL Screening improved by 34% since 1999 (24 percentage points from 70% to 94%)
↑ LDL Controlled <130 mg/dL improved by 68% since 1999 (30 percentage points from
44% to 74%)
↑ LDL Controlled <100 mg/dL improved by 9% since 2004 (4 percentage points from 47%
to 51%)
↑ Nephropathy Monitoring improved by 42% since 1999 (19 percentage points from 45% to
64%)
↑ Poorly Controlled HbA1c (>9.0%) improved by 28% since 1999 (8 percentage points from
29% to 21%; lower value desired)
↑ One/more HbA1c Tests improved by 10% since 1999 (8 percentage points from 84% to
92%)
↑ Eye Exam improved by 10% since 1999 (6 percentage points from 63% to 69%).
The WDHFS Diabetes Prevention and Control Program collects their data through various
surveys and/or administrative data sources (Attachment 3) using paper-based forms. The EHR-
based HIEs across clinicians and the Program could help improve population-based surveillance
on diabetes, diabetes care outcomes evaluation, and communication across participants in
diabetes care, control, and prevention (patients, clinicians, public health practitioners, and the
general public) in Wisconsin.
The proposed specification is aimed to describe work processes and information exchanges
related to diabetes care management, surveillance, and prevention between patients, clinicians,
and public health practitioners to inform the development of electronic HIEs for diabetes care
and control in Wisconsin. As the first step, this specification is focused on one component of the
35
Wisconsin Essential Diabetes Mellitus Care Guidelines. 2008. URL:
http://dhs.wisconsin.gov/health/diabetes/PDFs/GLIntro.pdf 36
The National Committee for Quality Assurance (NCQA). URL: http://www.ncqa.org/tabid/675/Default.aspx 37
The Wisconsin Collaborative Diabetes Quality Improvement Project, 2006.
URL:http://dhfs.wisconsin.gov/health/diabetes/hmo.htm 38
Health Plan Employer Data and Information Set (HEDIS). URL:
http://en.wikipedia.org/wiki/Health_Plan_Employer_Data_and_Information_Set Last accessed on February 8, 2008.
20
diabetes care management – Glycemic Control – that will serve as the first phase in specifying
functional requirements for HIEs for diabetes care and control.
The goal of diabetes care management is the prevention of acute and chronic complications of
diabetes mellitus. Traditional chronic complications of diabetes are viewed as the microvascular
complications of diabetes, including retinopathy, nephropathy, and neuropathy. Nevertheless, the
macrovascular complications of diabetes are more prevalent and are the major cause of disability
and death in patients with diabetes.39
Reduction in hyperglycemia (elevated levels of glucose in
the blood) significantly decreases both the micro- and macrovascular complications of
diabetes.40,41,42
Glycemic control is referred to periodic measurements of the hemoglobin HbA1c (HbA1c or
A1c), glycosylated hemoglobin, as an indicator for levels of glucose in the blood. HbA1c test
has become the ―golden standard‖ and a primary method for accessing and monitoring glycemic
control in patients with type 1 and type 2 diabetes, and one of the Healthcare Effectiveness Data
and Information Set (HEDIS)43
Comprehensive Diabetes Care performance measures in clinical
care of diabetes patients.
All laboratories determining HbA1c should use methods certified by the National
Glycohemoglobin Standardization Program. High-performance liquid chromatography is used
for HbA1c assays tests. Table 1 presents HbA1c thresholds in non-diabetic and diabetic
individuals.
Table 1 - HbA1c Levels
Patient Type HbA1c Levels*
Non-diabetic Person Perfect 4-6% 70-130 mg/dl (3.9-7.2 mMol/L)
Persons with Diabetes Average < 8% < 200 mg/dl (11 mMol/l)
Poor 9-15% 200-500 mg/dl (11-28 mMol/L)
39
American College of Endocrinology (ACE) Consensus Statement on Guidelines for Glycemic Control. Endocrine
Practice. 2002. 8(1):5-11 40
Diabetes Control and Complications Trial Research Group. The effect of intensive treatment of diabetes on the
development and progression of long-term complications in insulin-dependent diabetes mellitus. N Engl J Med.
1993;329:977-986. 41
Ohkubo Y, Kishikawa H, Araki E, et al. Intensive insulin therapy prevents the progression of diabetic
microvascular complications in Japanese patients with non-insulin-dependent diabetes mellitus: a randomized
prospective 6-year study. Diabetes Res Clin Pract. 1995; 28:103-117. 42
10. UK Prospective Diabetes Study (UKPDS) Group. Intensive blood-glucose control with sulphonylureas or
insulin compared with conventional treatment and risk of complications in patients with type 2 diabetes (UKPDS
33)[erratum in Lancet. 1999;354:602]. Lancet. 1998;352:837-853. 43
National Committee for Quality Assurance (NCQA). Healthcare Effectiveness Data and Information Set
(HEDIS). URL: http://www.ncqa.org/tabid/59/Default.aspx
21
The HbA1c assessments should be performed at least twice per year in patients who are at the
target level (<7.0 %) and quarterly or more frequently in patients who are above the target, who
are undergoing a change in therapy, or both44
.
To inform the development of electronic HIEs for diabetes care in Wisconsin, we selected
Glycemic Control as an example of the clinical scenario (use case) that involves information
exchanges between participants in diabetes care (patient, clinicians, and laboratories) and
population-health surveillance (clinicians, laboratories, and public health practitioners). Goals of Health Information Exchanges between Clinical and Public Health Information Systems in Diabetes Care Management: Glycemic Control
Clinical Care Goals:
1. To monitor blood sugar levels (HbA1c levels) in patients with diabetes to prevent acute
and chronic complications;
2. To inform clinical decisions in defining diabetes care management plan by streamlining
patient encounter and laboratory test information;
3. To improve communication between patient and provider on care coordination;
4. To improve practice’s reporting of performance measures.
Population Health Goals:
1. To monitor prevalence of diabetes in the community and HbA1c testing trends
(frequency and levels);
2. To inform clinical decisions in defining diabetes care management plan by providing
clinicians with community health information and community resources;
3. To improve communication between patients and providers on care coordination by
providing patients with educational materials on diabetes management and information
on community resources.
Actors – Participants in Health Information Exchanges: Glycemic Control
The following organizations will participate in HIEs:
Clinical Settings that Provide Diabetes Care:
o Two Federally Qualified Health Centers (FQHC)
o Department of Family Medicine, University of Wisconsin
Laboratory(ies) that performs HbA1c tests
Wisconsin Department of Health and Family Services
o Wisconsin Public Health Information Network (WI-PHIN)
o Wisconsin Diabetes Prevention and Control Program
44
Wisconsin Essential Diabetes Mellitus Care Guidelines. 2008. URL:
http://dhs.wisconsin.gov/health/diabetes/PDFs/GLIntro.pdf
22
Functions – Needs of Clinicians and Public Health Practitioners in Health Information Exchanges: Glycemic Control
The following functional requirements will be supported by HIE:
1. Collect, store, and manage patient’s encounter data in the EHR-S deployed at the
healthcare setting;
2. Collect, store, and manage HbA1c test data in the electronic Laboratory Information
Management System (LIMS or LIS) deployed at the laboratory setting;
3. Integrate EHR-S and LIMS to exchange patient HbA1c test orders and results data;
4. Enable access to the EHR-S and/or LIMS for an authorized public health personnel via
WI-PHIN to retrieve de-identified information on HbA1c tests results for population-
based surveillance;
5. Communicate community-level information on diabetes surveillance and community
resources back to clinicians.
The full list of clinical and public health functions for diabetes care and surveillance is presented
in Table 6.
Non-Functional Requirements
The following non-functional requirements will be supported by HIE:
1. Assure reliable health information exchange, e.g., periodic data uploads, back-ups, audit
trail, etc.;
2. Assure secure information exchanges across all participants, e.g., authorized user access
control;
3. Assure patient privacy protection, e.g., patient consent, anonymization of information
used for population-level surveillance, etc.;
4. Assure adherence to the national health information technology standards.
Data Sources
For patient care management purposes, the following clinical data sources that contain individual
patient information will be included in HIE (Figure 4 & 5):
• Electronic Health Record Systems and
• Laboratory Information Management Systems
For public health surveillance purposes and to generate diabetes surveillance reports to
providers, in addition to the clinical data sources (listed above) other data sources will be
included in HIE as follows:
• Wisconsin Behavioral Risk Factor Survey (BRFS)
• Wisconsin Youth Risk Behavior Survey (YRBS)
• Wisconsin Inpatient Hospitalization Discharge Database
23
• Wisconsin Emergency Department Visits
• Wisconsin Mortality Files
• End-stage Renal Disease (ESRD) Network Data
• Wisconsin Medicaid Program Data
• Wisconsin Medicare Program Data
• Wisconsin Census Records and Population Estimates
• Wisconsin Birth Records
• Wisconsin Family Health Survey
• Wisconsin Collaborative Diabetes Quality Improvement Project Data
• Wisconsin Diabetes Quality Improvement Project Data from the Section-330 Federally-
Qualified Community Health Centers
Data forms used by these data sources will be collected and cross-mapped to define a dataset to
be used in the HIE. Table 2 contains examples of data categories and related national standards
by data source in the Glycemic Control Use Case. The full diabetes care and surveillance data set
is presented in Table 7.
Table 2 - Diabetes Mellitus Care and Surveillance: Glycemic Control Use Case Data Set
Data Source Data Category Data Type/Element Related Standard
Individual Patient Clinical Data
Electronic Health Record System
Provider/Setting Demographic
Patient Demographic IHE PX PDQ
45
HITSP CE IS 0346
Visit/Encounter Data HL7 CDA 2
47
HITSP BIO IS 0248
HbA1c Order HITSP BIO IS 02
Claims X12 837
49
Laboratory Information Management System
HbA1c Results
HITSP EHR-Lab IS 01 IHE-Lab
50
45
Integrating the Healthcare Enterprise (IHE). Patient Demographic Query Profile. URL:
http://static.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_PIX_PDQ_HL7v3_TI_2007_08_15.pd
f 46
Health Information Technology Standards Panel (HITSP). Consumer Empowerment (CE) Interoperability
Specification (IS). HITSP CE IS 03. URL: http://www.hitsp.org 47
Health Level Seven (HL7). Clinical Document Architecture (CDA). Version 2. URL; http://www.hl7.org 48
Health Information Technology Standards Panel (HITSP). Biosurveillance (BIO) Interoperability Specification
(IS). HITSP BIO IS 03. URL: http://www.hitsp.org 49
Accredited Standard Committee (ASC). X12. URL: http://www.x12.org/ 50
Health Information Technology Standards Panel (HITSP). Electronic Health Record-Laboratory (EHR-Lab)
Interoperability Specification (IS). HITSP BIO IS 01. URL: http://www.hitsp.org
24
Population Health Data
EHR-S, LIMS Behavioral Risk Factor Survey (BRFS)
Aggregate Diabetes Surveillance Data: Current
Status of Diabetes Care
Self–Reported Responses on Frequency of HbA1c Test
Aggregate Diabetes Surveillance Data:
Trends in Diabetes Care
Percent of Patients Self-Reported Having in the Past Year HbA1c Tested Seen a Provider
EHRS, BRFS
Aggregate Diabetes Surveillance Reports
Diabetes Prevalence by Age County Race/Ethnicity
Sociodemographic Marital Status Employment Household Income Education Level
Risk Factors BMI Weight Status Physical Activity Physical Activity & Weight Loss Smoking Status Cardiovascular Conditions
o Cholesterol checked o Told cholesterol high o Told blood pressure high o Taking medication for high
blood pressure Fruit and Vegetable Consumption
Status
American Diabetes Association (ADA)
Economic Costs of Diabetes Costs Direct (Medical Care) Indirect (Lost Productivity)
Agency for Healthcare Research and Quality (AHRQ)
HEDIS: Diabetes Care
Glycemic Control Use Case
Table 3 contains the description of the Glycemic Control use case for HIE.
Table 3 - Diabetes Mellitus Care: Glycemic Control Use Case Description for HIE
Use Case Name
Glycemic Control
Business Actors (Personnel)
A. Healthcare Provider Federally Qualified Health Centers (2 clinics) University of Wisconsin Family Medicine (1 clinic)
Physician
Nurse
Medical assistant
Clerk
25
B. Laboratory Staff
Technician
Laboratory Information Management System (LIMS) personnel
C. Public Health Staff
Wisconsin Diabetes Prevention and Control Program Staff
Wisconsin Public Health Information Network (WI-PHIN) Staff
D. Consumer (Patient)
Technical Actors (Information Systems)
Electronic Health Record Systems
Laboratory Information Management Systems
Wisconsin Public Health Information Network
Patient’s Personal Health Record (PHR), Phone
Flow of Events Data Categories by Events
1st
Encounter
Patient visits Healthcare Provider (1st
Encounter) 1st
Encounter
Clerk conducts registration, obtains patient consent(s), and starts the encounter in EHR-S
Demographic data
Nurse obtains vital signs and enters data into EHR-S Vital signs data
Physician conducts exam and enters exam data into EHR-S Exam data
Physician orders HbA1c test via EHR-S Lab order data
Nurse receives order via EHR-S, draws blood specimen, sends specimen to the Laboratory
Laboratory LIMS receives test order from EHR-S Lab result data
Laboratory Personnel processes the specimen (receives/logs-in/analyze) and enters test results into LIMS
LIMS uploads test result data into EHR-S and anonymized test results data to WI-PHIN
Physician retrieves HbA1c results from EHR-S and reviews results
EHR-S uploads 1st encounter data including HbA1c results into PHR Encounter data
Physician communicates HbA1c results to Patient and a need for a follow-up visit via phone
Outreach report
2nd
Encounter
Clerk schedules the appointment in EHR-S Appointment Schedule
EHR-S sends appointment information to PHR and via phone
Patient visits Healthcare Provider (2nd
Encounter) 2nd
Encounter
Clerk conducts registration and starts the 2nd
encounter in EHR-S Demographic data
Nurse obtains vital signs and enters data into EHR-S Vital signs data
Physician conducts exam and enters exam data into EHR-S Exam data
Physician and Patient develop care management plan Care plan data
Provider records plan into EHR-S
EHR-S uploads 2nd
encounter data including HbA1c results into PHR Encounter data
Authorized Public Health Officer retrieves anonymized HbA1c test result data from EHR-S or LIMS for surveillance purposes via WI-PHIN
Diabetes Care Performance Measures and Surveillance Reports WI Diabetes Program staff gathers additional HbA1c data from other
data sources
26
WI Diabetes Program staff generates HbA1c surveillance reports
WI-PHIN transmits diabetes surveillance reports to EHR-S
EHR-S receives diabetes surveillance reports from WI-PHIN
Entry Condition
Patient visits Provider; Provider orders HbA1c test
Exit Condition
Provider develops care management plan; Provider receives diabetes surveillance reports
Figure 1 shows the UML Use Case diagram for the Glycemic Control use case, including both
the first and second patient encounters.
Figure 1 - UML Use Case Diagram: Glycemic Control
27
Figure 2 shows the Glycemic Control UML Use Case diagram for the first patient encounter.
Figure 2 - UML Use Case Diagram: Glycemic Control – First Patient Encounter
28
Figure 3 shows the Glycemic Control UML Use Case diagram for the second patient encounter
and the Public Health actions.
Figure 3 - UML Use Case Diagram: Glycemic Control – Second Patient Encounter
29
Figure 4 presents the Workflow/Dataflow diagram for the Glycemic Control use case for the 1st encounter. Note that Figure 4 skips
the interactions of a clerk and a nurse with the EHR-S, including capture of patient consent(s), prior to the physician exam and
HbA1c test order.
Figure 4 - Glycemic Control: Workflow/Dataflow Diagram
30
Health Information Exchange Architecture
Figure 5 presents the proposed high level architecture for the Wisconsin Health Information Exchanges related to the Glycemic
Control Use Case.
Figure 5 - High Level Architecture for Wisconsin Health Information Exchanges
31
Informing the Development of Interoperable Health Information Exchanges: IHE Care Management Technical Framework**
** This section includes inserts from the draft IHE Care Management Technical Framework51
that is under
development through the 2007-2008 IHE development cycle. The Profile development will be completed in the Fall
of 2008.
Problem Overview
The IHE Care Management (CM) Profile supports the exchange of information between HIT
systems and applications used to manage care for specific conditions. Examples of these systems
include Cancer Registries, Chronic Disease Management Systems, Disease Registries, and
Immunization Information Systems. The exchange of information across the participants of care
can help improve the care of patients and practices performance outcomes and support wellness
programs and public health surveillance including tracking prevalence of chronic diseases in the
community. These systems often include decision support capabilities, using evidence-based
guidelines for care of patients. They often use ad-hoc data gathering to collect information from
many different sources to populate data repositories, which are then used to support and manage
care for different patient populations. Information is provided to these systems from a number of
Clinical Data Sources (i.e., HIT systems) including:
• Physician Offices
• Imaging Centers
• Laboratories
• Surgery Centers
• Emergency Departments
• Inpatient Settings
• Insurance Providers, etc.
In order to manage patient care using these Clinical Data Sources, numerous data points are
routinely gathered through clinical encounters. The data gathered varies based upon the
condition being managed and may include:
• Current and Past Medical History
• Family History and other Risk Factors (commonly called Social History)
• Medications (Current and Prior)
• Allergies and Adverse Reactions
• Vital Signs and Other Observations
• Laboratory and Diagnostic Test Results
• Immunizations
• Procedures
• Surgical History, etc.
51
Integrating the Health Care Enterprise (IHE). Care Management Integration Profile. 2008. URL:
http://static.ihe.net/Technical_Framework/upload/IHE_PCC_Care_Management_CM_Supplement_2008-06-18.pdf
32
Current practices of information exchanges involve the creation of ad hoc interfaces to pass this
information from each HIT application to the Care Management System (i.e., registry). Given the
large number of applications and conditions which are managed in this fashion, it is not practical
or cost effective to design one-off interfaces for each combination that needs to communicate
with the Care Management System (CMS). Thus, there is a need for a method to easily and
automatically configure how multiple HIT systems can transmit this data, either on an ad hoc or
a scheduled basis, and to automate the transmission of this information.
One goal of this profile is to systematically define the data gathering requirements for
participating information systems in a way that supports existing and future deployments. If the
data requirements are specified in sufficient detail, and presented to the receiving applications in
an electronic format, then the sending application can automatically determine what information
to send (report) and when. In turn, the receiving applications can automatically determine what
information to obtain (receive) and when.
The Care Management health information exchanges architecture is depicted in Figure 6.
Technical Actors
The following technical actors (IT applications) are included in the Care Management
information exchanges:
Guideline Manager
Care Manager
Clinical Data Source including:
o EHR-S,
o Laboratory Information Management Systems
o Personal Health Record
o Patient Self-monitoring Device, etc.
Attachment 4 contains definitions for technical actors in this Profile.
33
Figure 6 - Care Management Health Information Exchange Architecture Overview
Guideline Development Organization
HIE
Health Information Exchange Service Provider
Self-
PHR
34
Scope
A guideline-based approach to care management can address the overall coordination of patient
care as described below.
1. Care providers define guidelines for disease management.
Using an evidence based approach, specialist groups (Guideline Development
Organizations) define a current ―best practice‖ guidelines for care management of the
disease, including all of the assessments, diagnostic tests, treatments, medications,
patient’s self-management, health education, etc. that define high quality care.
2. Patients are identified for potential enrollment in a disease care management program.
Patients are seen by a clinician during a routine visit. The clinician may order
tests/procedures to evaluate the patient for enrollment in the program.
Patient consent is obtained for participation in the plan including consent to participate in
an EHR-S, consent for use of personal health information for clinical care, consent for
disclosure of information for clinical care, consent for enrollment in self-management
plan, consent for disclosure of data for additional use (e.g., public health surveillance and
research), etc.
3. Patient demographics and clinical data are collected for enrollment in care management
program.
Patient data necessary to make a decision on patient suitability for enrollment, as defined
by the disease management guideline, is gathered.
Patient demographics and a sub-set of initial data may be transferred from the patient’s
PHR.
4. Patients are identified for enrollment.
Patients fitting the requirements for enrollment in the care management program are
identified, either through manual study or automatically through clinical decision support
tools.
5. Patients are enrolled in a disease management program.
Clinician enrolls patient in a disease management program. The care management plan
under the program is discussed with the patient. This may involve notifying a care
coordinator or others involved in care within the clinician’s office or elsewhere.
Clinician may recommend a remote self-management plan, which is discussed with the
patient. This may involve notifying a care coordinator within the clinician’s office or
elsewhere to initiate the remote monitoring process with the patient or caregiver.
Patient consents are obtained for enrollment in a disease management program and a self-
management plan as described above in section 2.
o Alternative: Patients may enroll themselves in a disease management
program including self-management plan.
35
The Care Management System notifies the clinician that the patient has been enrolled in
the care management program including a self management plan. The patient may
acquire a monitoring device with the ability to send the data to a PHR, or other method of
information exchange including a mechanism to send self-management data to the
clinician’s EHR-S.
6. Data is gathered on patients from Clinical Data Sources based on the disease management
guidelines.
Clinician receives notification of patient data received from Clinical Data Sources into
the EHR-S.
The patient’s information is displayed in the clinician’s EHR-S for review. The clinician
is able to determine the source of the data (e.g., clinic, lab, or self-monitoring device), the
date/time of the measurement, and any supporting data. The clinician may accept or deny
transmission of data depending upon whether this data is relevant to the care management
plan.
o Alternative: The information communicated to the clinician’s EHR may
include all data, or a sub-set of data (e.g., a medical summary).
o Alternative: The information may be a set of data identified for review by a
care coordinator. If information is reviewed by a care coordinator, the
information received in the EHR-S may contain assessment information such
as a summary of the care coordinator’s findings/recommendations, summary
of interactions with the patient, or specific items for the clinician to consider.
o Alternative: The information communicated to the EHR-S includes data that
may or may not be utilized by decision support to alert the clinician. Alert
information may be generated by the device, data intermediary, or information
exchange and may be communicated to the clinician’s EHR_S.
Necessary authentication and authorization mechanisms are established to send and
receive patient’s data.
7. Self-management data for the patient is gathered during routine patient care.
Clinician accepts remote self-management information transferred to the EHR-S.
o Alternative: Patient uses monitoring device to obtain data. (Some devices
may be set up to take measurements on a pre-defined schedule and may
require no action by the patient uploading data into PHR and EHR-S.)
Clinician receives notification of patient request to send self-management information to
the EHR-S. The clinician may accept or deny transmission of self-management data
depending upon whether this data is relevant to the care management plan.
If the remote self-monitoring information was reviewed by a care coordinator, the
information received in the EHR-S may contain assessment information such as a
summary of the care coordinator’s findings/recommendations, summary of interactions
with the patient, or specific items for the clinician to consider, etc.
o Alternative: The remote self-monitoring information communicated to the
EHR includes data that may or may not be utilized by decision support to alert
36
the clinician. Alert information may be generated by the device, data
intermediary, or information exchange and may be communicated to the
clinician’s EHR-S.
8. Decision support systems can monitor changes to information provided during healthcare
activities, and recommend actions to support the care of the patient.
The clinician or decision support system may recommend a follow-up office visit, urgent
care, or a discussion with the patient about following the recommended care plan (e.g.
medications, diet, etc.). The clinician may order additional tests, if appropriate.
The clinician may need to modify the patient’s care plan based upon information received
and evaluation of the patient.
The modified care plan and recommendations may be electronically accessed by the
patient. The patient implements the updated care plan. Remote self-management may
continue as directed by care providers. The modified plan may also need to be
communicated to other providers or care coordinators.
Changes to care plan and patient data are fed back to the organization defining disease
management guidelines for refinement of the guidelines and continuing research.
Because the complete use case for Care Management is extensive and very complex, it has been
necessary to limit the scope for the 2008-2009 year development to a small subset of the desired
functionality. The focus for this year is:
1. The definition and communication of the data variables needed to support guideline
oriented care.
2. The exchange of this information to and from HIT systems.
3. Association, through a query mechanism, of guidelines used for care with patients needing
care under those guidelines.
4. Communication of information from the patient EHR meeting the guideline criteria to the
system used to manage the care for a specific condition or conditions.
5. Support for communications using traditional HL7 Version 2 messaging, and HL7 Version
3 messaging over web services.
Future work by IHE Patient Care Coordination Committee (PCC) will expand this functionality
to provide further transactions covering:
1. Decision support to locate patients that qualify for care management programs.
2. Administrative activities involving the enrollment of patients in care management
programs.
3. Decision support to activate workflow in care management and support clinical decision-
making.
4. Communication of guidelines in electronic format to support clinical decision support.
5. Use of aggregated data collected by the care management programs to inform the
revision of care guidelines.
6. Use of aggregated data collected by the care management programs for public health
surveillance and disease prevention interventions.
37
The present level of support for guideline definition in this profile is sufficient to identify the
variables needed for decision support to the care management system and its sources of clinical
data, but is not intended to convey the complete guideline definition.
IHE Patient Care Coordination Committee will continue to work with relevant standards
organizations with respect to the development of appropriate standards in the areas of guideline
definition and clinical decision support to enable these future activities.
Diabetes Patient Care Management Example
Ms. Mabel Jones visits her Primary Care Practitioner (PCP), Dr. Martin, and is diagnosed as
having Type 2 Diabetes Mellitus. He counsels her about lifestyle changes and refers her to the
diabetes clinic in the local hospital. The diabetes clinic that she is referred to has a Care
Management System (clinical registry), which provides a care plan for patients and monitors their
progress, both through self-management and through continuing routine visits with the clinic and
PCPs. Figure 7 depicts the Care Management process flow for the diabetes clinical scenario
described below.
The American Diabetes Association (ADA) publishes updated treatment guidelines every
January and makes these guidelines available electronically to everyone (not just subscribers).
The diabetes clinic is an ADA subscriber. The clinic’s Care Management System electronically
uploads the guidelines to assure care provision in accordance with the latest recommendations.
(Figure 7, Steps 1 & 2)
Mabel is seen at the diabetes clinic. She is assessed by an internist and meets with a registered
nurse, dietician, and pharmacist who enroll her in their care management program and create a
care plan for her using the ADA guidelines, which specify all of the medical tests, medications,
and follow-up appointments recommended for care of her condition. Her care plan includes
blood glucose measurements four times daily, as well as a regimen of oral drugs, so Mabel is
supplied with a home monitoring system with a blood glucose monitor and a prescription for
glipizide. When her enrollment is completed a query for relevant results is sent from the clinic’s
Care Management System to the EHR-S at her PCP’s office, the clinical information systems
(CIS) at the hospital, the Laboratory Information Management System at the local laboratory,
and her home Personal Health Record system. (Figure 7, Steps 3 & 4).
Six months pass and Mabel is fairly compliant with her diabetes management. Mabel checks her
glucose levels daily and uploads the test results in her home PHR. She has purchased additional
equipment and is now able to measure her blood pressure and weight regularly and input these
data into her PHR. These measurements, as well as the results from the follow-up appointments
she has had with her PCP, have been sent to the clinic’s Care Management System (Figure 7,
Step 5), which has been monitoring her status. The Care Management System’s clinical decision
support software initially detected the fact that her blood glucose levels were not being optimally
controlled and suggested adjustments to her medications, which were accepted by the clinic’s
internist who in turn changed Mabel’s care plan (Figure 7, Steps 5 & 6). Soon her measurements
were within the acceptable range.
38
Figure 7 - Care Management Process Flow
Pre-conditions and Post-conditions
Before Care Management
Pre-conditions: The care management guidelines are defined by the Guideline Development
Organization.
Use Case Events Flow:
1. Using the defined care management guidelines, a set of data variables are collected in
report form.
2. A Clinical Analyst reviews the data variables with the Care Management System designers
to establish criteria and mappings from a Clinical Data Source (e.g., EHR-S).
3. An interface engineer creates appropriate interface messages and integrates the Care
Management System with the Clinical Data Source.
4. Patients are enrolled in the care management program with an appropriate care
management plan.
5. When the Clinical Data Source updates information from a patient enrolled with the
appropriate care management plan, one or more messages are sent to the Care
Management System from the Clinical Data Source containing information specific to
that plan.
Post-condition: The Care Management System is supported by one Clinical Data Source. Repeat
steps 2-5 above for the next Clinical Data Source.
After Care Management
Pre-conditions: The care management guidelines are defined by the Guideline Development
Organization.
39
Use Case Events Flow:
1. Using the care management guideline, a set of data variables are defined in an electronic
format using established vocabularies and defined units and measures, in conjunction
with clinical analysts and informatics experts. This electronic format is stored in a
Guideline Manager and reported to the Care Management System.
2. Data variables used for care management are allocated automatically by the Care
Management System reading the electronic specification.
3. The Care Management System enables reporting for enrolled patients by issuing queries to
the Clinical Data Source documenting the guideline being used.
4. [Option] Reporting is enabled for a patient by an "out-of-band" communication not
specified in this profile.
5. Clinical Data Sources configure the outbound interfaces for reporting the data variables by
locating the guideline definition and reading the electronic specification of the data
variables needed from it.
6. [Option] Clinical Data Source is configured to handle the reporting of data using
traditional interfacing methods and uses the query to simply indicate which preconfigured
interface to use.
7. When the Clinical Data Source updates information from a patient enrolled with the
appropriate care management plan, one or more messages are sent to the Care
Management System from the Clinical Data Source containing information specific to
that plan.
.
Post-condition: The Care Management System is updated with patient data from multiple
Clinical Data Sources.
Note: While enrollment is out of scope for this profile, the "enrollment" of a patient in a program
can be enabled in the Clinical Data Source by receipt of the query specified in step 3 above.
Transaction / Options / Grouping
Transactions. The Guideline Manager keeps track of guidelines and responds to requests for
information about guidelines (transaction PCC-8). When new guidelines are received, or existing
guidelines are updated, it notifies the Care Manager actor (transaction PCC-7); the Care Manager
is responsible for receiving notifications of new or updated guidelines (transaction PCC-8). Upon
receipt of these guidelines, it can analyze them in detail and then issue queries to various Clinical
Data Sources (transaction PCC-9). The Clinical Data Sources will then pass back information to
the Care Manager (transaction PCC-10 or PCC-11) enabling the Care Manager to evaluate next
steps for the management of the patients' condition(s).
The narrative above contains the following transactions:
Request Guideline Data (PCC-8)
Guideline Notification (PCC-7)
Care Management Data Query (PCC-9)
V3 Care Management Update (PCC-10)
40
V2 Care Management Update (PCC-11)
Attachment 4 contains definitions of transactions included in the Care Management profile.
Figure 8 shows the technical actors and transactions in this Profile. Table 4 provides the list of
required (R) and optional (O) transactions in this Profile by technical actor.
Figure 8 - Care Management Technical Actor Diagram
Table 4 - Transaction by Technical Actor
Note 1: At least one of these transactions must be supported.
Note 2: A Clinical Data source that implements the Care Record option shall implement this
transaction.
41
Options. The transaction options by technical actor applicable for this profile are summarized in
Table 5.
Table 5 - Transaction Options by Technical Actor
Care Record Option. A Clinical Data Source Actor that implements the Care Record Option
sends updates to the Clinical Data Manager using PCC-10 (V3 Care Management Update), and
must also support receipt of PCC-9 (Care Management Data Query).
HL7 Version 2 Option. A Clinical Data Source Actor that implements the HL7 Version 2 option
sends updates to the Clinical Data Manager using PCC-11 (V2 Care Management Update).
Guideline Management Option. A Care Manager that implements the Care Manager Option
supports the receipt of PCC-7 (Guideline Notification) 1010 transaction.
Grouping. The following groupings are applicable to this profile:
ATNA and CT. The technical actors of this profile must implement the ATNA Secure Node or
Secure Application Actor, and the CT Time Client Actor.
Query for Existing Data (QED). The Care Manager may be grouped with the Clinical Data
Source actors of the QED profile to facilitate communication of care management trends or other
information to PHR or EHR systems.
Cross-enterprise Document Sharing (XDS). The Care Manager may be grouped with the
Document Source actor of the XDS profile to facilitate communication of care summaries from
the Care Management system to an XDS Repository, for subsequent access by a Care Provider or
the patient.
Analyzer / Aggregator. The Care Manager actor may be grouped with the Analyzer / Aggregator
actor of the PEQD profile to support aggregation of quality reporting data to measure
conformance to evidence-based guidelines.
Basic Patient Privacy Consent (BPPC). The Clinical Data Source actor may be grouped with the
Content Consumer Actor of the BPPC profile to obtain information about consents to share data.
42
Coded Terminologies
This profile supports the capability to record entries beyond the IHE required coding associated
with structured data. Business actors from this profile may choose to utilize coded data, but
interoperability at this level requires an agreement between the communicating parties that is
beyond the scope of this Profile.
To facilitate this level of interoperability, the applications that integrate business actors within
this profile shall provide a link to their HL7 conformance profile within their IHE Integration
statement. The conformance profile describes the structure of the information which they are
capable of creating or consuming. The conformance profile shall state which templates are
supported by the application implementing the profile and which vocabularies and/or data types
are used within those templates. It should also indicate the optional components of the entry that
are supported. An Example HL7 Conformance Profile is available to show how to construct such
a statement. See the HL7 Refinement Constraint and Localization for more details on HL7
conformance profiles.
Process Flow
This Profile supports the following process flow across technical actors (Figure 9):
1. A guideline is defined and activated in the Guideline Manager. The set of data variables are
communicated in electronic format to the Care Management System.
2. The Care Manager sends a query for the clinical data identified by the guideline to Clinical
Data Source 1 and Clinical Data Source 2.
3. Clinical Data Source 1 is configured out of band to respond appropriately to the query
identified by the Guideline Manager.
4. Clinical Data Source 2 queries the Care Manager for the guideline identified in the query and
configures itself to respond appropriately based on the data variables identified in the
guideline.
5. Upon updating applicable patient data, Clinical Data Source 1 sends an HL7 Version 2
message specified by the guideline to the Care Manager.
6. Upon updating applicable patient data, Clinical Data Source 2 sends an HL7 Version 3 Care
Record Update to the Care Manager, based on the configuration computed in step 4.
43
Figure 9 - Care Management Process Flow
44
Results
Working with Users: FRAD for Diabetes Care Management and Surveillance in Wisconsin
To inform the development of Wisconsin HIE we formulated user functional requirements for
health information exchanges between clinical EHR-based clinical systems and the public health
information system (registry) based on the Wisconsin Diabetes Mellitus Care Guidelines
(Attachment 1) in the Wisconsin Functional Requirement Analysis Document for Diabetes Care
Management and Surveillance.
Due to the limited scope, the FRAD was focused on describing functional requirements for
information exchange for the one component (use case) of the diabetes care management, i.e.,
Glycemic Control – the main disease screening and monitoring tool in diabetes care. The full list
of clinical and public health functions for diabetes care management and surveillance to be
supported by HIEs is presented in Table 6.52
Table 2 of the FRAD presents clinical and public health data types for the Glycemic Control use
case. The full data content to be included in the exchange for diabetes care management and
surveillance is presented in Table 7. The public health data types were identified by reviewing
the Wisconsin Diabetes Control Program’s reports. These data are collected by the Program from
various data sources including non-clinical data sources (surveys) (Attachment 3).
The FRAD has been used in guiding our work with vendors at IHE as explained below.
Working with Vendors: IHE Care Management Technical Framework
The IHE activities on the development of the Care Management Technical Framework have been
initiated by Health Canada in the fall of 2007. We supported this initiative because of our work
on the development of the Wisconsin FRAD for diabetes care and surveillance that was
complementary to the IHE efforts. We used the Wisconsin FRAD as an example of chronic
disease care management in the development of the Framework, i.e., we used the Wisconsin
Diabetes Care Management Guidelines (Attachment 1) as an example of the clinical guidelines
for chronic disease care management. We also used the data sources from the Wisconsin FRAD
as examples of data sources for the Framework. The clinical scenario example in the Framework
has been developed by Canadian authors of the document, though the work on the Wisconsin
FRAD allowed us to gain knowledge on diabetes care management and, therefore, to critique and
refine the diabetes scenario in the Framework.
The Framework identified the three major components (technical actors) in the HIE for chronic
disease management: a Guideline Manager - a module that maintains clinical guidelines and
allows querying them to guide clinical practice; a Care Manager - a module that maintains
business practices and processes (operational procedures) for an individual healthcare
52
Using Computerized Registries in Chronic Disease Care. First Consulting Group. California Healthcare
Foundation. 2004. URL:
http://www.chcf.org/documents/chronicdisease/ComputerizedRegistriesInChronicDisease.pdf
45
organization and an organization that will provide health information exchange services, (e.g.,
regional health information organization); and, lastly, Clinical Data Sources - EHR-Ss deployed
in healthcare organizations. The Framework specified the high-level architecture for chronic
disease care management, the generic process flow, and transactions between technical actors to
enable HIEs.
Though the public health agency is not specified in the Framework at this time as a particular
data source or guideline creator, we are planning to work with IHE in the future to add to the
Framework public health diabetes control programs and information systems to the list of
business actors (clinical settings, laboratory, etc.) and technical actors (EHR-S, clinical registries
and public health registries), respectively. The work on the Wisconsin FRAD allowed us to
identify public health registry functions (Table 6) and data content (Table 7) that will be used in
the development of the Integration and Content profiles for diabetes care management and
surveillance in the 2009 IHE profile development cycle.
46
Table 6 - Examples of Clinical and Public Health Registry Functions
Elements of Chronic Care Management
Registry Functions
Basic Advanced
Clinical Registries53
Embed evidence-based clinical guidelines into daily clinical practice
Incorporate care guidelines for primary care into reports and displays for care team
Incorporate information about decision criteria for patient care
Incorporate information about care management guidelines into reports and displays for care team
Include prompts recommending changes in patient care plan using guideline-based algorithms and patient-specific information
Incorporate care guidelines for primary care with input from relevant specialists
Incorporate information about decision support for patient referral to specialists in patient displays and reports for care team
Include prompts recommending referrals for specific patients using guideline-based algorithms and patient-specific information
Send e-mail notifications to physicians or care team when patients are seen in emergency department
Facilitate individual patient care planning
Provide condition-specific view of current patient status and progress
Recommend changes in patient care plan using guideline-based algorithms and patient-specific information
Provide timely reminders for providers and patients
Track desired intervals for next visit, test, or contact based on care guidelines
Send e-mail notifications to physicians or care team regarding patient due to visit, test, or contact
Allow clinicians to record patient-specific interval for next visit or intervention
Include information about due date for visit and other interventions in patient reports and displays
Send phone/e-mail notifications to patients regarding due dates for visit, test, or contact
Ensure regular follow-up by the care team
Provide patient lists sorted according to overdue status (e.g., no HbA1c during last 6 months) or patient status according to management control (e.g., HbA1c>8.0 or personal goal)
Provide telephone call lists and/or mailing labels and patient reminder letters for follow-up
Provide outreach or exception lists for each physician or care team
Display next appointment data for patients on outreach or exceptions lists
Share information with patients and providers to coordinate care
Provide access to patient information to all members of care team
Provide access to patient information to others involved in care (e.g., specialists, emergency room care team, etc.)
Record patient self-management plan for subsequent access by care team
Provide patient with the record of care plan and self-management plan
Identify relevant population for care Track information for identified subpopulation of patients with a designated chronic condition
Manage list of active and engaged patients for each provider and care team
53
Using Computerized Registries in Chronic Disease Care. First Consulting Group. California Healthcare
Foundation. 2004. URL:
http://www.chcf.org/documents/chronicdisease/ComputerizedRegistriesInChronicDisease.pdf
47
Monitor performance of practice team and care system
Provide population reports for lists of patients and user-specified conditions of management control (e.g., HbA1c<8) or guideline compliance status (e.g., two HbA1c tests in past year)
Provide tabular analysis of trends in any of the above
Provide population reports for individual physicians and care teams, clinics, and medical groups
Provide peer comparison reports by individual physician, care team, and clinic
Provide graphic displays of trends in user-specific conditions of management control and guideline compliance in population reports
Public Health Registries
Monitor status of care within a jurisdiction
Provide reports and graphical displays (by practice, region, age group, race, etc.) on care guidelines compliance status (frequency of HbA1c Tests, Dilated Eye Exams, Flu Shots; compliance with medication prescription schedule, etc.)
Monitor disease-related hospitalizations within a jurisdiction
Track number/percent of hospitalizations by disease (by age, race, region, etc.); calculate charges/costs; produce graphical displays of findings
Track number/percent of complications by disease (by age, race, region, etc.); calculate charges/costs; produce graphical displays of findings
Track length of stay by disease (by hospital, region, etc.); calculate charges/costs; produce graphical displays of findings
Calculate mortality rates (by age, race, hospital, region, etc.); produce graphical displays of findings
Survey disease prevalence, trends, risk factors, etc. within a jurisdiction
Calculate disease prevalence and trends by region, age group, race; produce graphical displays of findings
Calculate disease prevalence and trends by socio-demographics (marital status, employment, household income, education level); produce graphical displays of findings
Calculate disease prevalence and trends by risk factors (BMI, physical activity, smoking status, food consumption, pre-conditions, e.g., cholesterol level, high blood pressure, etc.); produce graphical displays of findings
48
Table 7 - Diabetes Mellitus Care Data Set for the Wisconsin Diabetes Surveillance54
Data Source Data Category Data Type/Element Related Standard Individual Patient Clinical Data
Outpatient Electronic Health Record System (EHRS)
Pt’s Demographics IHE PX PDQ HITSP CE IS 03
Provider’s Demographics
Visit/Encounter Data CDA 2 HITSP BIO IS 02
Lab Orders HITSP BIO IS 02
Claims X12 837
Laboratory Information Management System (LIMS)
Lab Results HITSP EHR-Lab IS 01 IHE-Lab
Population Health Data
Behavioral Risk Factor Survey (BRFS)
Aggregate Diabetes Surveillance Data: Current Status of
Diabetes Care
Self–Reported Responses on Frequency of HbA1c Test Time Respondent had Last Dilated
Eye Exam Receiving Flu Shot in Past Year and
Pneumococcal Shot Ever Selected Aspects of Diabetes Care
o Took Course/Class – Manage Diabetes
o Taking Pills for Diabetes o Currently Taking Insulin o Ever Told Diabetes Affected Their
Eyes o Any Sores Took >4w to Heal
Immunization Registry
Aggregate Diabetes Surveillance Data: Trends in Diabetes
Care
Percent of Patients Self-Reported Having in the Past Year HbA1c Tested Seen a Provider Receiving a Dilated Eye Exam Their Feet Checked Flu Shot Pneumococcal Shot Ever Seen by a Dentist A Weight Corresponding to Not
Overweight/ Overweight/Obese
Told Their Cholesterol or Blood Pressure is High
Current Smoker55
Aggregate Diabetes Surveillance Data:
Surveillance Reports
Diabetes Prevalence by Age County Race/Ethnicity
Sociodemographic variables Marital Status Employment Household Income Education Level
Risk Factors BMI Weight Status Physical Activity Physical Activity & Weight Loss
54
Wisconsin Diabetes Surveillance Report. URL: http://dhfs.wisconsin.gov/health/diabetes/survrpt.htm
Last accessed February 13, 2008. 55
―Current Smoker‖ data type added based on review of this report conducted by Minnesota Department of Health.
49
Smoking Status Cardiovascular Conditions
o Cholesterol checked o Told cholesterol high o Told blood pressure high o Taking medication for high blood
pressure o Fruit and Vegetable Consumption
Status
WI Inpatient Hospital Discharge Database
Aggregate Diabetes Surveillance Data: Diabetes-Related Hospitalizations
Number of Hospital Discharges with Diabetes as Principal Diagnosis Any Diagnosis
Percent of Diabetes-Related Hospitalizations as Hospitalizations Charges
Age-Adjusted Rates of Hospital Discharges with Diabetes Listed as Any Diagnosis
Age-Specific Rates of Hospital Discharges with Diabetes as Principal Diagnosis Any Diagnosis
Mean Length of Hospital Stay Days Charges
Diabetes-Relates Amputations Number Percent Age-Adjusted Rates Age-Adjusted Rates by Sex
United States Renal Data System (USRDS)
Aggregate Diabetes Surveillance Data: Diabetes-Related Hospitalizations
End-Stage Renal Disease Age-Adjusted Prevalence Rate by
o Year o Age group
Age-Adjusted Incidence Rate by o Year o Age group
Wisconsin Vital Records Aggregate Diabetes Surveillance Data: Diabetes-Related Hospitalizations
Diabetes Mortality Number Age-Adjusted Mortality Rate
American Diabetes Association (ADA)
Economic Costs of Diabetes
Costs Direct (Medical Care) Indirect (Lost Productivity)
Agency for Healthcare Research and Quality (AHRQ)
HEDIS: Comprehensive Diabetes Care
Measures
50
Discussion
Working with Users
We used the PHDSC FRAD methodology for the user functional requirements elicitation and
documentation for a particular chronic disease-specific domain (diabetes) in a particular
jurisdiction (Wisconsin). The FRAD methodology (interviews with users to describe their needs
in HIE; and documentation of these needs in the structured format of the requirement analysis
document) has been successfully used to formulate the diabetes care requirements for HIE in
Wisconsin.
The Wisconsin FRAD is the third one developed by the PHDSC in addition to the school health
and syndromic surveillance FRADs, New York City Department of Health & Mental Hygiene.
Applying the FRAD methodology for these three distinct domains showed its suitability for
documenting user functional requirements for HIT applications to be shared by clinical and
public health settings in various domains and jurisdictions. The Wisconsin FRAD can be
recommended for further use as a template for gathering user functional requirements for EHR-
based clinical and public health HIT applications for other components of the diabetes care
management, other diseases, and other jurisdictions.
Though the Wisconsin FRAD uses informatics terminology (actions=functions; actors = HIE
participants) and the Unified Modeling Language (UML) modeling tools for visual
representation of user interactions and workflow & data flow in the use case, it has been
positively received by the WDHFS staff who reviewed the FRAD. The FRAD was
recommended to be used in the development of educational materials, i.e., tutorial and
presentation, at the Wisconsin HIE meetings to inform public health and clinical practitioners on
their role in informing EHR-S vendors about user needs in HIT applications under HIEs. This
presentation may help facilitate user involvement in guiding the development of Wisconsin
HIEs. The WDHFS is planning to use the FRAD in the Wisconsin HIE demonstration project in
the spring of 2009.
Facilitating the Development of Health Information Exchanges in Wisconsin
As of today, there is neither a diabetes public health registry in Wisconsin nor any direct data
exchanges between clinicians and the WDHFS Diabetes Control and Prevention Program for
public health surveillance. Currently, the Program staff collects data mostly from non-clinical
data sources (surveys, etc.) (Attachment 3) in order to generate population-based surveillance
reports. This activity is funded by the Centers for Disease Control (CDC) Diabetes Control
Program. Under the Wisconsin eHealth initiative, there are plans that the Diabetes Control and
Prevention Program will become an integral part of the WI-PHIN and the Wisconsin HIE and,
therefore, the Program will be able to obtain data directly from clinical data sources enhancing
the diabetes population-based surveillance.
Integrating diabetes public health registry functions and data content in the Wisconsin HIE will
enable the Program to (1) obtain program-specific information from EHR-based HIEs in real-
time, (2) automate generation of the Program’s diabetes surveillance reports, and (3) make the
51
reports available for healthcare providers who could use this community-level and statewide
information in care delivery and practice’ resources planning.
The identified public health registry functions (Table 6) and data content (Table 7) for diabetes
surveillance can be used to inform the development of electronic HIEs for diabetes care
management and surveillance in Wisconsin. Further validation of these functions and data
content by comparing them with registry functions and data content used in other jurisdictions
and other diseases will help in building the common (standardized) functionality and common
(standardized) data content for EHR-S-based HIEs for chronic care management and
surveillance. In the future, diabetes data can be integrated with data from other public health
programs, e.g., cardiovascular disease control, asthma control, etc., under the WI-PHIN for
comprehensive population-based health assessments, program evaluations, resource allocation,
etc..
Working with Vendors
The Wisconsin FRAD enabled us to work with EHR-S vendors on the development of a generic
Technical Framework for interoperable EHR-S-based HIT applications to support the healthcare
delivery functionality and public health surveillance functionality for chronic diseases in regional
and nationwide health information exchanges.
The Framework serves as a standardized umbrella technical specification for the development of
the IHE Integration Profiles and Content Profiles for HIT applications in chronic disease care
management and surveillance. The user requirements that will be elicited through the FRAD
development process for additional diabetes care use cases, e.g. referrals to specialists, eye exam,
HEDIS measures, etc., can be used in the future development of the Integration and Content
profiles under the Framework. The Integration Profile and Content Profiles documents will
further standardize functionalities and common data sets across information systems involved in
HIEs in chronic disease care management including EHR-Ss, Laboratory Information
Management Systems (LIMS), and Clinical and Public Health Registries. These Profiles will
enable vendors to develop interoperable HIT applications to support regional and nationwide
health information exchanges under a NHIN.
52
Conclusions and Next Steps
The project successfully employed FRAD methodology for a new domain (diabetes) and in a
new jurisdiction (Wisconsin). The developed FRAD for Glycemic Control - primary screening
and monitoring tool in diabetes care management - specified functional requirements and data
content for future EHR-S-based information exchanges between clinical settings and the
Wisconsin Diabetes Control Program. This FRAD, therefore, could be used in informing the
development of HIEs for diabetes care management and surveillance in Wisconsin.
The review of literature on clinical registries, the Wisconsin Diabetes Mellitus Care Guidelines,
and WDHFS Diabetes Surveillance Reports helped to generate a list of clinical care and public
health surveillance functions and a list of clinical and public health data types for comprehensive
diabetes care management and surveillance to be used in HIEs in Wisconsin. This effort helped
in understanding the relationships between clinical and public health registries in terms of using
diabetes care EHR-S data for aggregated data analysis at the practice level (clinical registries)
and community level (public health registries). Functions and data content of registries
documented in this project could be used in informing the development of common architecture
to support both types of registries in the future electronic health information exchanges. We
envision expanding the function and data content lists by adding functionalities and data content
for other chronic conditions, e.g., asthma, cardiovascular diseases, etc.
The project strengthened collaboration between public health and EHR-S vendors at the
Integrating the Healthcare Enterprise; helped PHDSC to establish a new IHE domain ―Public
Health, Research and Quality‖ that will focus on public health information systems
interoperability with EHR-S systems; and, therefore, helped to establish a mechanism for public
health user participation in guiding vendors on the development of interoperable clinical and
public health systems.
The project helped identify future directions for building collaboration between public health and
EHR-S vendors to achieve interoperability of clinical and public health systems as follows:
In Wisconsin:
1. The WDHFS is planning to use the FRAD in the Wisconsin HIE demonstration project in
the spring of 2009.
2. The WDHFS is requesting to develop educational materials (tutorial and presentation) on
the user role in guiding HIT projects to be presented at the HIE stakeholder meetings in
Wisconsin. This presentation may help facilitate user involvement in guiding the
development of Wisconsin HIEs.
At the Integrating the Healthcare Enterprise - 2008-2009 Profile Development Cycle:
1. Develop the Diabetes Content Profile Proposal for Glycemic Control Use Case.
2. Develop a Content Profile Proposal on standardizing queries to EHR-S on patient-level
information for diabetes care management and on population-level information for
diabetes population-based surveillance. This may include separate Content Profiles
proposals for the two new use cases under the diabetes care management guidelines such
as cardiovascular care and quality of care reporting.
53
Attachment 1: Wisconsin Essential Diabetes Mellitus Care Guidelines56
56
Wisconsin Essential Diabetes Mellitus Care Guidelines. 2008. URL:
http://dhs.wisconsin.gov/health/diabetes/PDFs/GLIntro.pdf
54
Attachment 2: Organizations – Endorsers of the Wisconsin Diabetes Strategic Plan
As of November 200757
Advanced Healthcare, S.C.
The Alliance
American Diabetes Association, Wisconsin
American Heart Association
Aspirus Diabetes Education Center
Aurora Health Care Southern Lakes, Inc.
Beloit Area Community Health Center
Bloomer Medical Center-Mayo Health System
Children's Hospital of Wisconsin Diabetes Program
City of Milwaukee Health Department
Covenant Healthcare - Angel of Hope Clinic
Dean Health Plan, Inc.
Diabetes Clinical Quality Coordinating Committee
Family Health Center of Marshfield, Inc.
Froedtert
Great Lakes Inter-Tribal Council
Group Health Cooperative of Southcentral Wisconsin
Gundersen Lutheran Health Plan
Humana - Wisconsin
Juvenile Diabetes Research Foundation - Western Wisconsin
Kenosha Community Health Center, Inc.
Lake Superior Community Health Center
Lakeview Lutheran Church/Oakwood Lutheran Home
Latino Health Organization, Inc.
Managed Health Services
Marshfield Clinic
Marquette University School of Dentistry
Medical College of Wisconsin
Memorial Health Center
Memorial Medical Center
MercyCare Health Plans
MetaStar
National Kidney Foundation of Wisconsin
Network Health Plan
N.E.W. Community Clinic
Northeastern Wisconsin Association of Diabetes Educators
Physicians Plus Insurance Corporation
57
Wisconsin Diabetes Strategic Plan. 2004-2009. Endorsers. URL:
http://dhfs.wisconsin.gov/health/diabetes/strategicplan.HTM Last accessed on February 5, 2008.
55
Prevent Blindness Wisconsin
Price County Health Department
Quad/Graphics, Inc.
Rural Wisconsin Health Cooperative
Security Health Plan of Wisconsin
Sixteenth Street Community Health Center
Thedacare
Unity Health Insurance
University of Wisconsin Medical Foundation
UW-Madison, Department of Population Health Sciences
Vilas County Public Health Department
Washburn County Diabetes Coalition
WEA Trust
West Central Wisconsin Association of Diabetes Educators
Wisconsin Dental Association
Wisconsin Dietetic Association
Wisconsin Geriatric Education Center
Wisconsin Heart Disease and Stroke Prevention Program
Wisconsin Hospital Association
Wisconsin Lions (Multiple District 27) Council of Governors
Wisconsin Office of Rural Health
Wisconsin Optometric Association
Wisconsin Primary Health Care Association
Wisconsin Society of Podiatric Medicine
56
Attachment 3: Diabetes Mellitus Care Data Sources in Population Health Surveillance in Wisconsin58
• Wisconsin Behavioral Risk Factor Survey (BRFS) • Wisconsin Youth Risk Behavior Survey (YRBS) • Wisconsin Inpatient Hospitalization Discharge Database • Wisconsin Emergency Department Visits • Wisconsin Mortality Files • End-stage Renal Disease (ESRD) Network Data • Wisconsin Medicaid Program Data • Wisconsin Medicare Program Data • Wisconsin Census Records and Population Estimates • Wisconsin Birth Records • Wisconsin Family Health Survey • Wisconsin Collaborative Diabetes Quality Improvement Project Data • Wisconsin Diabetes Quality Improvement Project Data from the Section-330 Federally- Qualified Community Health Centers
58
Wisconsin Diabetes Strategic Plan. 2004-2009. Data Sources. URL:
http://dhfs.wisconsin.gov/health/diabetes/strategicplan.HTM Last accessed on February 5, 2008.
57
Attachment 4: IHE Care Management Profile Definitions for Actors and Transactions
ACTOR DEFINITIONS
Technical Actors are information systems or components of information systems that produce, manage, or act on information associated with operational activities in the enterprise.
Content Creator is responsible for the creation of content and transmission to a Content Consumer. Content Consumer is responsible for viewing, import, or other processing of content created by a
Content Creator Actor. Clinical Data Consumer makes use of clinical patient data. Clinical Data Source (e.g., EHR-S, registry) maintains patient information about vital signs, problem
and allergies, results from diagnostic tests (e.g., Lab, Imaging, or other test results), medications, immunizations or historical or planned visits and procedures.
Guideline Manager is responsible for managing the guidelines used to create care plans, and for
communicating those guidelines to other systems. Care Manager is responsible for supporting the management of the care of patients with respect to a
specific health condition. It gathers information about the care provided and current health status of the patient. A Care Manager actor may be designed for management of a single condition, such as management of Diabetes, or may be a general purpose system supporting management of multiple conditions.
TRANSACTION DEFINITIONS
Query Existing Data (QED) transaction requests information about recent patient information, used to obtain vital signs measurements, problems and allergies, diagnostic results, medications, immunizations, or procedures or visits relevant for a patient. The query may request information about some or all of the above topics, or may request information on a specific topic, or one entered for a specific encounter or date range.
Guideline Notification transaction reports the content of new and/or updated guidelines to interested
parties. The purpose of this transaction is to alert systems that need to act on clinical guidelines of the availability of new guidelines.
Request Guideline Data transaction supports the capability of systems to query for the contents of
an identified guideline. Care Management Data Query transaction supports the capability of systems responsible for
monitoring the health status and care provided to one or more patients to request that information from systems that may have this information.
V3 Care Management Update transaction supports the capability for systems that have information
about the health status and care provided to one or more patients to share that information with external systems that need to monitor that information using profiles of HL7 V3 Care Record standard messages.
V2 Care Management Update transaction supports the capability for systems that have information
about the health status and care provided to one or more patients to share that information with external systems that need to monitor that information using specific profiles of HL7 V2 standard messages.
