Standards for Public Health Data Exchange: Functional Requirements Standard for Diabetes Care Management and Surveillance

Transcription

1 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-S AB

2 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 healthrelated 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 Phone: (410) Fax: (410)

3 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 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 5 TABLE OF CONTENTS EXECUTIVE SUMMARY... 8 CURRENT ENVIRONMENT PROBLEMS WITH HEALTH INFORMATION TECHNOLOGY IN CHRONIC DISEASE CARE MANAGEMENT, SURVEILLANCE, AND PREVENTION SOLVING PROBLEMS OF INFORMATION SYSTEMS NON-INTEROPERABILITY EFFORTS TO DATE WORKING WITH USERS WORKING WITH VENDORS PROJECT GOAL, APPROACH, PARTNERS, AND METHODOLOGY 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 HEALTH INFORMATION EXCHANGES AND DIABETES CARE MANAGEMENT IN WISCONSIN GOALS OF HEALTH INFORMATION EXCHANGES BETWEEN CLINICAL AND PUBLIC HEALTH INFORMATION SYSTEMS IN DIABETES CARE MANAGEMENT: GLYCEMIC CONTROL ACTORS PARTICIPANTS IN HEALTH INFORMATION EXCHANGES: GLYCEMIC CONTROL FUNCTIONS NEEDS OF CLINICIANS AND PUBLIC HEALTH PRACTITIONERS IN HEALTH INFORMATION EXCHANGES: GLYCEMIC CONTROL NON-FUNCTIONAL REQUIREMENTS DATA SOURCES GLYCEMIC CONTROL USE CASE HEALTH INFORMATION EXCHANGE ARCHITECTURE INFORMING THE DEVELOPMENT OF INTEROPERABLE HEALTH INFORMATION EXCHANGES: IHE CARE MANAGEMENT TECHNICAL FRAMEWORK** PROBLEM OVERVIEW TECHNICAL ACTORS SCOPE DIABETES PATIENT CARE MANAGEMENT EXAMPLE PRE-CONDITIONS AND POST-CONDITIONS TRANSACTION / OPTIONS / GROUPING CODED TERMINOLOGIES PROCESS FLOW RESULTS WORKING WITH USERS: FRAD FOR DIABETES CARE MANAGEMENT AND SURVEILLANCE IN WISCONSIN WORKING WITH VENDORS: IHE CARE MANAGEMENT TECHNICAL FRAMEWORK DISCUSSION WORKING WITH USERS FACILITATING THE DEVELOPMENT OF HEALTH INFORMATION EXCHANGES IN WISCONSIN WORKING WITH VENDORS CONCLUSIONS AND NEXT STEPS ATTACHMENT 1: WISCONSIN ESSENTIAL DIABETES MELLITUS CARE GUIDELINES ATTACHMENT 2: ORGANIZATIONS ENDORSERS OF THE WISCONSIN DIABETES STRATEGIC PLAN ATTACHMENT 3: DIABETES MELLITUS CARE DATA SOURCES IN POPULATION HEALTH SURVEILLANCE IN WISCONSIN ATTACHMENT 4: IHE CARE MANAGEMENT PROFILE DEFINITIONS FOR ACTORS AND TRANSACTIONS... 57

6 6 TABLE OF TABLES Table 1 - HbA1c Levels Table 2 - Diabetes Mellitus Care and Surveillance: Glycemic Control Use Case Data Set Table 3 - Diabetes Mellitus Care: Glycemic Control Use Case Description for HIE Table 4 - Transaction by Technical Actor Table 5 - Transaction Options by Technical Actor Table 6 - Examples of Clinical and Public Health Registry Functions Table 7 - Diabetes Mellitus Care Data Set for the Wisconsin Diabetes Surveillance... 48

7 7 TABLE OF FIGURES Figure 1 - UML Use Case Diagram: Glycemic Control Figure 2 - UML Use Case Diagram: Glycemic Control First Patient Encounter Figure 3 - UML Use Case Diagram: Glycemic Control Second Patient Encounter Figure 4 - Glycemic Control: Workflow/Dataflow Diagram Figure 5 - High Level Architecture for Wisconsin Health Information Exchanges Figure 6 - Care Management Health Information Exchange Architecture Overview Figure 7 - Care Management Process Flow Figure 8 - Care Management Technical Actor Diagram Figure 9 - Care Management Process Flow... 43

8 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, URL: 2 Department of Health and Human Services (HHS), The ONC Coordinated Federal Health IT Plan June 3, URL: 3 Using Computerized Registries in Chronic Disease Care. First Consulting Group. California Healthcare Foundation URL:

9 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 Program 4 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 Document 7 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 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: 5 Integrating the Healthcare Enterprise (IHE). URL: 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: Last accessed on February 5, Bruegge B. and Dutoit A.H. Object-Oriented Software Engineering. Pearson Prentice Hall. Upper Saddle River, NJ. 2nd edition:

10 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 Framework 8 for interoperable EHR-S-based HIT applications. The Framework serves as a standardized umbrella technical specification for the development of the IHE Integration Profiles 9 and Content Profiles 10 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 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-Ss 15 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: 12 Bodenheimer T. et al. Improving Primary Care for patients with Chronic Illness: The Chronic Care Model, Part 2. JAMA, 2002: 288(15): Institute of Medicine. Crossing the Quality Chasm. National Academy P, Washington DC, Using Computerized Registries in Chronic Disease Care. First Consulting Group. California Healthcare Foundation URL: 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:

12 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 June 3, URL:

13 13 Working with Users Solving Problems of Information Systems Non- Interoperability Efforts to Date 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 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; URL:< %20December%205-6%202006%20-%20Final%20Report.pdf. 20 Health Information Technology Standards Panel (HITSP). [cited 29 Mar 2008]; Available from: 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:

14 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; p. URL: 23 Requirement Management. Leffingwell D, Editor, URL: 24 Bruegge B. and Dutoit A.H. Object-Oriented Software Engineering. Pearson Prentice Hall. Upper Saddle River, NJ. 2nd Edition

15 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: PHDSC_Public_Health_White_Paper_ pdf 26 Centers for Disease Control and Prevention (CDC). Diabetes Data and Trends. URL 27 Wisconsin Department of Health and Family Services; URL:

16 16 The PHDSC FRAD development methodology 28 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: Last accessed on February 5, Wisconsin Essential Diabetes Mellitus Care Guidelines URL Wisconsin Diabetes Surveillance Report. URL: Last accessed February 13, Wisconsin Diabetes Surveillance Report. URL: Last accessed February 13, 2008.

17 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 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 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, 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 ehealth 33 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 URL: Last accessed on February 5, 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:

19 19 The Wisconsin Essential Diabetes Mellitus Care Guidelines 35 (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 Project 37 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 measures 38 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 EHRbased 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 URL: 36 The National Committee for Quality Assurance (NCQA). URL: 37 The Wisconsin Collaborative Diabetes Quality Improvement Project, URL: 38 Health Plan Employer Data and Information Set (HEDIS). URL: Last accessed on February 8, 2008.

20 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% mg/dl ( mmol/l) Persons with Diabetes Average < 8% < 200 mg/dl (11 mmol/l) Poor 9-15% mg/dl (11-28 mmol/l) 39 American College of Endocrinology (ACE) Consensus Statement on Guidelines for Glycemic Control. Endocrine Practice (1): 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: 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: 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: National Committee for Quality Assurance (NCQA). Healthcare Effectiveness Data and Information Set (HEDIS). URL:

21 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 both 44. 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 URL:

22 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 populationbased 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 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 Electronic Health Record System Laboratory Information Management System Provider/Setting Demographic Patient Demographic Visit/Encounter Data HbA1c Order Claims HbA1c Results Individual Patient Clinical Data IHE PX PDQ 45 HITSP CE IS HL7 CDA 2 47 HITSP BIO IS HITSP BIO IS 02 X HITSP EHR-Lab IS 01 IHE-Lab Integrating the Healthcare Enterprise (IHE). Patient Demographic Query Profile. URL: f 46 Health Information Technology Standards Panel (HITSP). Consumer Empowerment (CE) Interoperability Specification (IS). HITSP CE IS 03. URL: 47 Health Level Seven (HL7). Clinical Document Architecture (CDA). Version 2. URL; 48 Health Information Technology Standards Panel (HITSP). Biosurveillance (BIO) Interoperability Specification (IS). HITSP BIO IS 03. URL: 49 Accredited Standard Committee (ASC). X12. URL: 50 Health Information Technology Standards Panel (HITSP). Electronic Health Record-Laboratory (EHR-Lab) Interoperability Specification (IS). HITSP BIO IS 01. URL:

24 24 EHR-S, LIMS Behavioral Risk Factor Survey (BRFS) EHRS, BRFS American Diabetes Association (ADA) Agency for Healthcare Research and Quality (AHRQ) Aggregate Diabetes Surveillance Data: Current Status of Diabetes Care Aggregate Diabetes Surveillance Data: Trends in Diabetes Care Aggregate Diabetes Surveillance Reports Economic Costs of Diabetes HEDIS: Diabetes Care Population Health Data Self Reported Responses on Frequency of HbA1c Test Percent of Patients Self-Reported Having in the Past Year HbA1c Tested Seen a Provider 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 Costs Direct (Medical Care) Indirect (Lost Productivity) 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 Business Actors (Personnel) Glycemic Control A. Healthcare Provider Federally Qualified Health Centers (2 clinics) University of Wisconsin Family Medicine (1 clinic) Physician Nurse Medical assistant Clerk

25 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 Electronic Health Record Systems Laboratory Information Management Systems (Information Wisconsin Public Health Information Network Systems) Patient s Personal Health Record (PHR), Phone Flow of Events Data Categories by Events 1 st Patient visits Healthcare Provider (1 st Encounter) 1 st Encounter Encounter Clerk conducts registration, obtains patient consent(s), and starts the Demographic data encounter in EHR-S 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 Nurse receives order via EHR-S, draws blood specimen, sends specimen to the Laboratory Laboratory LIMS receives test order from EHR-S Laboratory Personnel processes the specimen (receives/logsin/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 Lab order data Lab result data 2 nd Encounter EHR-S uploads 1 st encounter data including HbA1c results into PHR Physician communicates HbA1c results to Patient and a need for a follow-up visit via phone Clerk schedules the appointment in EHR-S EHR-S sends appointment information to PHR and via phone Encounter data Outreach report Appointment Schedule Patient visits Healthcare Provider (2 nd Encounter) 2 nd Encounter Clerk conducts registration and starts the 2 nd encounter in EHR-S Nurse obtains vital signs and enters data into EHR-S Physician conducts exam and enters exam data into EHR-S Physician and Patient develop care management plan Provider records plan into EHR-S EHR-S uploads 2 nd encounter data including HbA1c results into PHR Authorized Public Health Officer retrieves anonymized HbA1c test result data from EHR-S or LIMS for surveillance purposes via WI- PHIN WI Diabetes Program staff gathers additional HbA1c data from other data sources Demographic data Vital signs data Exam data Care plan data Encounter data Diabetes Care Performance Measures and Surveillance Reports

26 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 Exit Condition Patient visits Provider; Provider orders HbA1c test 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 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 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 29 Figure 4 presents the Workflow/Dataflow diagram for the Glycemic Control use case for the 1 st 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 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 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 Framework 51 that is under development through the IHE development cycle. The Profile development will be completed in the Fall of 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 URL:

32 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 33 Figure 6 - Care Management Health Information Exchange Architecture Overview Guideline Development Organization Health Information Exchange Service Provider HIE Self- PHR

34 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 selfmanagement plan as described above in section 2. o Alternative: Patients may enroll themselves in a disease management program including self-management plan.

35 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 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 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 decisionmaking. 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 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 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 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 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 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 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 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 43

44 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 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 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 URL:

45 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 46 Table 6 - Examples of Clinical and Public Health Registry Functions Elements of Chronic Care Management Embed evidence-based clinical guidelines into daily clinical practice Facilitate individual patient care planning Provide timely reminders for providers and patients Ensure regular follow-up by the care team Share information with patients and providers to coordinate care Identify relevant population for care Registry Functions Basic Clinical Registries 53 Incorporate care guidelines for primary care into reports and displays for care team Incorporate information about care management guidelines into reports and displays for care team Incorporate care guidelines for primary care with input from relevant specialists Provide condition-specific view of current patient status and progress Track desired intervals for next visit, test, or contact based on care guidelines Allow clinicians to record patientspecific interval for next visit or intervention Include information about due date for visit and other interventions in patient reports and displays 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 outreach or exception lists for each physician or care team Provide access to patient information to all members of care team Record patient self-management plan for subsequent access by care team 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 Advanced Incorporate information about decision criteria for patient care Include prompts recommending changes in patient care plan using guideline-based algorithms and patient-specific information 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 notifications to physicians or care team when patients are seen in emergency department Recommend changes in patient care plan using guideline-based algorithms and patient-specific information Send notifications to physicians or care team regarding patient due to visit, test, or contact Send phone/ notifications to patients regarding due dates for visit, test, or contact Provide telephone call lists and/or mailing labels and patient reminder letters for follow-up Display next appointment data for patients on outreach or exceptions lists Provide access to patient information to others involved in care (e.g., specialists, emergency room care team, etc.) Provide patient with the record of care plan and self-management plan 53 Using Computerized Registries in Chronic Disease Care. First Consulting Group. California Healthcare Foundation URL:

47 47 Monitor performance of practice team and care system Monitor status of care within a jurisdiction Monitor disease-related hospitalizations within a jurisdiction Survey disease prevalence, trends, risk factors, etc. within a jurisdiction 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 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.) 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 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 48 Table 7 - Diabetes Mellitus Care Data Set for the Wisconsin Diabetes Surveillance 54 Data Source Data Category Data Type/Element Related Standard Individual Patient Clinical Data Pt s Demographics IHE PX PDQ HITSP CE IS 03 Outpatient Electronic Health Record System (EHRS) Laboratory Information Management System (LIMS) Behavioral Risk Factor Survey (BRFS) Provider s Demographics Visit/Encounter Data CDA 2 HITSP BIO IS 02 Lab Orders HITSP BIO IS 02 Claims X Lab Results HITSP EHR-Lab IS 01 IHE-Lab Population Health Data Aggregate Diabetes Self Reported Responses on Surveillance Data: Frequency of HbA1c Test Current Status of Time Respondent had Last Dilated Diabetes Care 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 Aggregate Diabetes Surveillance Data: Trends in Diabetes Care Aggregate Diabetes Surveillance Data: Surveillance Reports 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 Smoker 55 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 Immunization Registry 54 Wisconsin Diabetes Surveillance Report. URL: Last accessed February 13, Current Smoker data type added based on review of this report conducted by Minnesota Department of Health.

49 49 WI Inpatient Hospital Discharge Database United States Renal Data System (USRDS) Wisconsin Vital Records American Diabetes Association (ADA) Agency for Healthcare Research and Quality (AHRQ) Aggregate Diabetes Surveillance Data: Diabetes-Related Hospitalizations Aggregate Diabetes Surveillance Data: Diabetes-Related Hospitalizations Aggregate Diabetes Surveillance Data: Diabetes-Related Hospitalizations Economic Costs of Diabetes HEDIS: Comprehensive Diabetes Care Measures 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 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 End-Stage Renal Disease Age-Adjusted Prevalence Rate by o Year o Age group Age-Adjusted Incidence Rate by o Year o Age group Diabetes Mortality Number Age-Adjusted Mortality Rate Costs Direct (Medical Care) Indirect (Lost Productivity)

50 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 EHRbased 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 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 realtime, (2) automate generation of the Program s diabetes surveillance reports, and (3) make the

51 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 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 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 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 53 Attachment 1: Wisconsin Essential Diabetes Mellitus Care Guidelines Wisconsin Essential Diabetes Mellitus Care Guidelines URL: