Demonstrating Collect once, Use Many Assimilating Public Health Secondary Data Use Requirements into an Existing Domain Analysis Model

Demonstrating Collect once, Use Many Assimilating Public Health Secondary Data Use Requirements into an Existing Domain Analysis Model Cynthia Barton, RN 1, Crystal Kallem, RHIA 2, Patricia Van Dyke, RN 3, Donald Mon, PhD 2, Rachel Richesson, PhD 4 1 Duke University School of Nursing, Durham, NC; 2 American Health Information Management Association, Chicago, IL; 3 Delta Dental Plans Association, Portland, OR; 4 Division of Bioinformatics and Biostatistics, University of South Florida, College of Medicine, Department of Pediatrics, Tampa, FL Abstract The healthcare industry has an increasing need for clinical data content standards to support patient care and data re-use in areas such as research, quality and public health. The Diabetes Data Strategy (Diabe-DS) project was formed in 2009 by the HL7 EHR Working Group to demonstrate a repeatable process that identifies disease-specific Common Data Elements (CDEs) for clinical care and secondary use. The Diabe-DS project previously developed a set of important CDEs and supporting data models for clinical care, quality and research uses of diabetes data. This paper will describe the process for identifying the data elements and activities required for public health use of clinical data, and mapping them to Diabe-DS CDEs, use case and data models. The result is a model for consideration which provides data needed in the immediate clinical environment of care, and supports the use of data for multiple uses. Introduction The healthcare industry has an increasing need for clinical data to support both patient care and data re-use. The areas of disease surveillance, population health, quality measurement and clinical research have a need to define and harmonize clinical data content standards (e.g., Common Data Elements, Domain Analysis Models) which can support both patient care and secondary data uses. The notion of meaningful secondary use as a means to improve the quality, safety, and efficiency of healthcare is an important theme in current national information infrastructure discussions. 1 Central to any discussion of meaningful secondary use are the topics of interoperability and data standards. The Diabetes Data Strategy (Diabe-DS) proof-of-concept project was formed in 2009 by the Health Level Seven International (HL7) EHR Working Group with the objective to demonstrate a repeatable process that identifies disease-specific Common Data Elements (CDEs) for clinical care and secondary use. This project provides a framework for the collect once, use many times paradigm for a national health information strategy. The process will inform other domain specific groups wanting to develop content standards for clinical documentation that can support multiple uses, such as research, quality measurement, public health, reimbursement and others. The Diabe-DS (Diabetes Data Strategy) project focuses on Type 1 Diabetes (T1D) assessment in an ambulatory setting. This project is a pilot demonstration to show how data re-use might work and to develop a method to inform subsequent content standards efforts. The Diabe-DS project team has created a set of common data elements, a comprehensive suite of use cases, and UML models that can be used by application developers to support applications for T1D data collection that address multiple data uses. In addition, the team has identified relationships between these models and other standard models, such as the Healthcare Information Technology Standards Panel (HITSP) medication model 2 (used in developing data interoperability use cases for the US Office of the National Coordinator). Diabe-DS began by examining clinical data elements that could be used to support the secondary uses of research and quality measurement. The purpose of this work is to present the process used to incorporate the public health requirements (as another secondary use) into the Diabe-DS project. This paper will first discuss public health data requirements and uses for the data in relation to diabetes. Subsequently, the following processes will be described: the process of writing a public health use case and incorporating the use case into the already created suite of use cases, identifying the data elements needed, and mapping the data elements to the use case and the existing Diabe-DS domain analysis model. 98

Background Diabetes Data Standards and Diabe-DS Diabetes is a prevalent disease with high morbidity and growing incidence worldwide. A lack of domain standards for diabetes data collection exists in clinical, research, and public health settings. 3,4 This same lack of standards prevents the collect once, use many approach to diabetes data collection on both a personal and a national scale. Data standards for the uniform collection of diabetes data will support the various secondary uses that can improve our understanding of the disease, and identify new treatments and best practices that will improve the health and quality of life for millions. The early work of the Diabe-DS team explored locally developed EHR entry interfaces for diabetes clinics and saw little commonality. Similarly, the review of research data collection forms used in a spectrum of multi-site diabetes investigations showed little standardization of diabetes specific data elements. The National Quality Forum 5 (NQF), in collaboration with quality measure stewards, has expressed multiple diabetes quality measures for use in the electronic environment. 6 The NQF has done significant work to express the data requirements for these quality measures in a way that enables the extraction of clinical data from EHRs. Specifically, the quality measures are translated into multiple data elements that represent the units of clinical data collection. The Diabe-DS project leveraged this work, and selected two measures (Diabetes Care HbA1c Control and Diabetic Foot Exam) to demonstrate the harmonization of clinical and quality data elements to a single standard that would support both functions. Rather than risk creating different diabetes-specific data elements for each secondary purpose (e.g., quality, research, public health), the Diabe-DS group is attempting to harmonize data capture requirements across various secondary uses. The Diabe-DS project was designed to be a proof-of-concept focused on creating a narrow set of artifacts, processes and methodologies applied to a similarly narrow context: the collection of pediatric T1D assessment data in an outpatient clinic setting (patient care) that can support related clinical research, quality measurement and population health activities (all secondary uses). 7 Within the domain of T1D, the project strives to harmonize the data elements that support these three secondary uses. This includes a set of data elements that are required for various secondary uses and mappings or relationships to the data as would be captured in electronic medical records. Additionally, the team developed a comprehensive suite of use cases that address the primary data collection as well as each of the secondary uses. These use cases illustrate the uniform collection of a set of data elements, and their subsequent re-use in multiple (secondary use) scenarios. An intentional and continuous theme throughout the Diabe-DS work is the requisite to leverage any previous work, including existing UML models for patient care, such as the medication model from HITSP. 2 Common data elements A Common Data Element, or CDE, is a question or unit of data collection that is represented uniformly across one or more applications and which has value across multiple settings or contexts. A common ISO definition of a data element is used which includes the name of the data element, the values and the definition. In HL7, a primary developer of EHR data standards, CDEs are related to a specific Domain Analysis Model (DAM), which is required to support the development of HL7-based messages in a particular disease or application area. The premise of HL7 is that CDEs should inform the development of a model constructed from the information units, communication requirements and clinical workflows of a domain. HL7 considers Domain Analysis Models to be conceptual representations of these tasks and information units against which software can be defined and evaluated. Both CDEs and DAMs are considered part of clinical data content standards in HL7. DAM development is a component of the HL7 Healthcare Development Framework. 8 Typically common data elements refer to a disease domain or therapeutic area, such as Tuberculosis or Cardiovascular care. The Diabe-DS project constrains the notion of common in CDEs even further, and collects data elements that are common to both primary (clinical documentation) and one or more secondary uses within the Type 1 Diabetes domain. The specification of common data capture requirements to support T1D care and data re-use includes narrative use cases that describe the primary data capture at the clinical encounters and the secondary uses, in addition to clearly defined data elements and the data models that relate them. Although there are many domain-specific CDE projects (both in and outside of HL7 organization) there are few published methods to guide these efforts. The Pre-op Anesthesia core dataset project 9 and the National Cancer Institute s Early Detection Research Network 10 have presented their experience identifying and vetting data 99

elements within a medical domain. The Tuberculosis and Cardiovascular HL7 DAM 11,12 projects were both intended to be informative demonstrations of developing domain-specific content standards and supporting artifacts (activity diagram, UML models) required by HL7 to support various messaging applications. They provide guidance for the number of communications, type of correspondence and other means to engage a clinical community in the process of identifying CDEs. However, the authors are not aware of other projects or methods that focus on harmonizing data elements across primary and secondary uses, or that focus on the development (and harmonization) of supporting data models and narrative use cases. The Diabe-DS project has presented its approach, 7,13 and this paper focuses on the specific problem of adding a new secondary use to existing multi-use models. Public health represents an important secondary use for clinical data and the incorporation of public health uses in the Diabe-DS collect once, use many times scenario was critical to the success of the project. Public Health In order to identify the data needs of public health for Type 1 Diabetes it was necessary to gain a better understanding of the public health domain, including objectives, activities and data requirements for public health - e.g., how it uses the data it receives from clinicians, and the problems related to data usage within the domain of public health itself. The public health community has been actively pursuing standards that further its mission and that recognize public health as part of a bigger system of interoperable data. As such, the public health data standards community has previously articulated its mission, specific objectives, and activities as they relate to primary data collection. 4 This widely vetted, clearly articulated, and carefully documented work of public health data requirements collectively facilitated the Diabe-DS project team s work described here. The documents cited in this section informed the expansion of Diabe-DS artifacts to address public health as a secondary use. Public Health has a mission to assure conditions in which people may be healthy. 14 The scope of public health is both population-based and patient-centric, and in order to fulfill its mission health care providers and public health agencies must be able to exchange pertinent health data about both individuals and communities. 4 Many information systems used by public health agencies have been in place since before standards for information exchange existed and are not capable of exchanging data electronically within agency programs, much less with healthcare providers. 3,4 Although limited resources are a persistent challenge, public health agencies are continuously improving capabilities to send, receive and exchange data with clinical practices. Public health information needs must be taken into account during development of data standards in order for them to be able to send, receive and exchange relevant data with EHR systems as the public health systems are upgraded. In order to fulfill the functions of public health, agencies need to receive and analyze data gathered at the patient s point-of-care. Until now, agencies have primarily relied on health care providers to actively submit data to public health departments using specific forms populated by healthcare providers, either with data from their EHR or free text from paper charts. Whether the data is parsed from free text or populated from the EHR it may not be standardized. 3,4 Further, healthcare providers normally do not receive data back from public health agencies that impacts individual patient care. In other words, there generally are not productive information exchanges between healthcare providers and public health, although there is potential for bi-directional data exchanges. Populationbased data aggregated by public health agencies and sent back to providers can assist them in decision making to improve patient care and outcomes. Similarly, the clinical data can be used by public health to identify community resources that are needed to give patients more options for healthy living and disease prevention. 15 Public health s involvement in chronic disease care management, surveillance and prevention is supported with disease-specific registries. These registries contain information about prevalence, trends, and risk factors among a population. The registries are populated with the data sent from clinical settings, mostly via the forms described above. Some may be submitted through web-based portals or collected through surveys. 16 Standardization of the CDEs in disease-specific domains such as T1D will allow multiple healthcare providers and EHR systems to submit standardized data to public health, and enable the development of standardized chronic disease registries. Public health could then use these standardized registries for diabetes care management and surveillance as well as to inform health promotion interventions and guidelines to support clinical practice. 4,17 Additionally, the receipt of current and standardized data from various EHR systems using Diabe-DS data elements could enable public health to develop standard and population-based approaches to monitor the health and services of this population, and to develop interventions that support effective management of the disease. 100

Adding public health requirements to existing data capture specifications The Public Health Data Standards Consortium (PHDSC) has focused for many years on identifying needs and opportunities for interoperability with EHRs and public health. 4,17 This group has been a consensus organization, working to engage many and distributed public health experts to develop a collective sense of purpose and needs and has documented their work very clearly. The PHDSC used a Functional Requirements Analysis Document (FRAD) methodology to identify common data sets and use cases for exchange of diabetes care management and surveillance data between Wisconsin clinical care and public health information systems. 18,19 The same methodology was used for common data sets for interoperability between New York City schools and syndrome surveillance with clinical care records. 20 These were closely examined as was the public health interoperability specification document prepared by the Health Information Technology Standards Panel (HITSP). 21 Earlier disease specific data standardization efforts conducted within the HL7 organization also provide important background for the Diabe-DS project and any domain-specific CDE. These projects were done by disease experts in the domains of Tuberculosis and Cardiovascular Disease and a set of data elements and HL7 domain analysis models were described for each disease area. 11,12 While the methods of these CDE projects were carefully documented and did serve as a good starting point for the Diabe-DS project, these projects represented first run CDE projects and were not concerned with re-using or harmonizing existing data elements (that might overlap with other domains) nor do they have any coverage on harmonizing use cases and data models across multiple secondary uses. This is an important challenge that all CDE projects will face, and one very germane to the Diabe-DS project. From the onset, the Diabe-DS team documented detailed processes, strategic decisions, and examples of specific data elements that were selected, excluded, revised, or harmonized. These examples should inform future disease specific data standards efforts, as well as inform solutions that encourage future re-use and harmonization across disease domains. METHODS The literature was reviewed to identify public health s data needs for T1D which needed to be included in the Diabe- DS CDEs. In order to understand best practice and public health boundaries, the Diabe-DS team reviewed current clinical practice guidelines for T1D, including the ADA Clinical Practice Guidelines for Diabetes Care 22 and the Wisconsin Diabetes Mellitus Care Guidelines. 23 The public health community s defined data requirements and public health secondary use case 17 served as the foundation and starting point for this project. The primary task was to assess and integrate the public health community s consensus data requirements and activities within the framework of the Diabe-DS project. The original PHDSC work was comprehensive, addressed many public health activities, and only addressed clinical data capture for public health needs. For purposes of the Diabe-DS demonstration, a more limited view of a single public health activity was needed, and one that was heavily inspired by previous PHDSC work. A separate use case was developed by the Diabe-DS team to identify the actors and the workflow of Public Health. This allowed the team to conceptualize which of the public health data elements would have overlap with both the clinical care scenario (describing primary data capture) or the previously-defined secondary uses (research and quality). This use case, plus existing Diabe-DS use cases, provided a lens to identify CDEs that were important to public health and the Diabe-DS demonstration project. The public health use case was incorporated into the suite of use cases already written by the Diabe-DS project team. The Diabe-DS project team informed the remainder of the steps for incorporating public health s data needs based upon their current approach to the project. Specifically, the tasks for the project included: 1. Develop a public health use case, using existing PHDSC materials 2. Examine the existing (n=250) T1D CDEs identified by the Diabe-DS project to determine which fit with public health secondary data needs 3. Compile the list of Type 1 Diabetes specific CDEs still needed by public health 4. Develop the definitions and value sets of the CDEs 5. Incorporate the use case into the suite of use cases previously developed by the Diabe-DS Project team 6. Map the CDEs to the use case 7. Work with the data modelers to add the public health data elements to the data models (data models assert relationships between all of the data elements and are informed by other HL7 data models such as the CV and TB DAMs) 101

8. Document the process Diabetes care management is one of the activities addressed by the PHDSC work previously done, so the first order of business was to look at the T1D-specific activities and CDEs that these public health stakeholders had previously identified. (The PHDSC work had previously been explored in depth and vetted through the public health data standards community.) This gave the Diabe-DS project an excellent starting point to harmonize these needs into the existing Diabe-DS suite of use cases. The Wisconsin Functional Requirements Standard for diabetes care management and surveillance prepared by the PHDSC informed this harmonization. A Functional Requirements Analysis Document (FRAD) as used by the PHDSC is a shortened version of the requirements analysis document produced by users and software developers. This document uses the standard functional requirements elicitation methodology and includes the goals of the system, the actors, use cases, functional requirements, data elements and workflow. The Wisconsin FRAD documents the functional requirements for EHR-S information exchange with public health. Since the Wisconsin FRAD focuses on chronic disease care management and surveillance in the disease specific domain of diabetes, this was a good starting point for the process of identifying the CDEs needed for secondary use by Public Health. 18 Identifying the CDEs needed for T1D for public health was an iterative process. The CDEs already identified by the Diabe-DS team were reviewed to see if any of the CDEs identified to date fit with the use cases and data elements identified in the Wisconsin FRAD. The existing Diabe-DS CDEs are maintained on an excel spreadsheet located at: http://wiki.hl7.org/index.php?title=ehr_diabetes_data_strategy. Originally the team felt that some CDEs were too specific (e.g., too atomic) for the Diabe-DS project but found the specificity to be necessary in order to meet the requirements for public health re-use. These data elements e.g. ethnicity and diabetes education were included in the data elements which were eventually presented to the team as necessary for public health. As with other data standards projects (HL7, HITSP), the idea of a use case to guide the work was an important aspect of the Diabetes-DS project. 24 A suite of use cases had already been developed to help refine the scope of the project and describe how the same core data could be used throughout various purposes (e.g., delivery of patient care, research, quality reporting, etc.). The scenarios represented in the use cases include: 1. Patient presents in ambulatory clinic and is diagnosed with T1D 2. Patient is followed by endocrinologist through several visits 3. Patient is seen by diabetic educator 4. Patient is enrolled in a research study 5. Patient data is aggregated and reported for quality measurement A use case was written to describe the flow of data between the clinical care setting and public health. The use case was loosely based on the Wisconsin glycemic control use case developed as part of the Functional Requirements Standard for Diabetes Care Management. 18 The use case was written to cover the following goals of Public Health for diabetes care and management: 1. Monitor prevalence of diabetes in the community and HbA1c testing trends 2. Inform clinical decisions for diabetes care management by providers with community health information and community resources 3. Improve communication between patients and providers and provide patients with educational materials and information on community resources The use case follows the flow of data from the provider s EHR to a public health agency where it is aggregated and sent back to the provider for his use in diabetes care management. The public health use case was initially written independently as a separate document and then incorporated into the suite of use cases previously developed by the Diabetes-DS team. It was through this exercise that documenting care management information such as immunization status and obtaining demographic information which had been omitted from the original provider visit use cases were identified as being necessary to support this additional re-use scenario. These were discussed with the Diabe-DS team during a biweekly conference call and the team agreed they should be part of the use case. The use case was then used to re-examine the data elements in the Diabe-DS master spreadsheet to determine if any additional public health data elements were in the spreadsheet or needed to be added. Additional data elements such as age, county of residence, and race were identified as important to public health for disease surveillance and trends. A total of fifteen additional data elements were added to the spreadsheet. 102

After the data elements were identified, the process of developing definitions and determining permissible value sets for each one of them began. Some of the data elements, such as ethnicity, are widely used but the names and permissible values (value set) are not standardized. A value set is the list of permissible values for a data element. The process for developing or determining the definitions and the value sets included searching for the data elements in several places. The CaBIG website has a CDE browser 24 which aided in writing definitions and in determining the value sets for each CDE. Different permissible values were found depending on which organization had defined the data element and its values. For instance, the value set for the data element smoking might be: Current smoker, smoked but quit within last year, and never smoked. After researching the possible value sets, definitions and data element names, and determining which combination suited the needs for the Diabe-DS project, the data elements for public health - as they relate to the existing set of Diabe-DS elements - were discussed by the Diabe-DS team. When consensus was obtained the data elements were added to the master spreadsheet as new data elements, or mapped to existing or closely related data elements. Next, the data elements were mapped to the use case. Mapping data elements to the use case involved going through the use case and matching all the data elements in the use case with those in the spreadsheet. Any elements identified as missing in the spreadsheet were investigated and vice versa. This was a tedious but necessary step and as part of this harmonization of data elements definitions and value sets were further clarified. Finally, the public health data elements were harmonized with the existing UML models. The modeling process helps to define data relationships at their most granular level and deconstructs data requirements into finite elements which can be understood by more than the patient care community. Results Bringing public health into the Diabe-DS project was challenging. Developing the use case and identifying data elements for public health use of data from a T1D office encounter expanded the total number of data elements in the Diabe-DS project by only fifteen. The focus of the Diabe-DS project is on the intersection of data elements for T1D in public health, research, quality and clinical care. An example of the data elements, the definitions and permissible value sets is found in the table on the left side of Figure 1 which shows several steps of the use case. The arrows illustrate the mapping of a common data element to the use case. To address the functional and data requirements for secondary use of clinical T1D data, a total of 15 new data elements were defined and added to the 250+ existing Diabe-DS data elements. Of the data elements already present, approximately thirty were relevant to public health. Thirteen of the public health data elements which were added to the list had not been previously identified. Two data elements (ethnicity and diabetes education) had been identified previously, but it was felt they were too specific to be included in this early demonstration. Because of their importance to public health surveillance and diabetes care management the consensus of the Diabe-DS team was to add them to the list of CDEs. 103

Figure 1. Relationship between Common Data Elements and the Public Health Secondary Data Use Case. The Diabe-DS team had worked on harmonization of the data elements with clinical, quality and research needs, but not with public health needs. To harmonize the existing data elements with the public health use case required reviewing the existing definitions and the value sets and the public health literature. 3,18 Ensuring that the definitions and permissible values of the existing elements fit with public health s data needs was time consuming. For instance, a data element name might not be a lexical match, but a search of the definitions might produce the needed element with a different name which would satisfy public health s data needs. This required comparing the definitions in the spreadsheet to public health s data needs. In the master spreadsheet there are many CDEs with similar names and similar definitions. A decision had to be made as to whether an existing data element fit public health s needs or if an additional data element was needed. Another difficulty with incorporating public health into the Diabe-DS project was that many of public health s data needs are related to Type 2 Diabetes and the Diabe-DS project is specific to T1D. It was necessary to carefully go through public health s data needs and research which needs also apply to T1D. There is disparity among organizations about data element names, definitions and value sets. For instance, when researching ethnicity, which is important for public health, several names and value sets were found. The data element names included ethnicity, ethnicity group, and ethnicity participant group. The value sets included: (a) White/African American/Asian/Native American/Other; (b) White/Non White; or (c) African American, White, Asian/Pacific Islander, Native American, Biracial/ Multiracial, NR/Unknown, Other. 16 Each time the value set of a data element had multiple names, definitions, and/or value sets research was done to clarify which of these were appropriate for public health s data needs. 104

The public health use case was originally written separately and when incorporating it into the suite of use cases it was necessary to add a step at the beginning. The need for providers to know the criteria for reporting data to public health had not been recognized in any of the existing use cases and this is key to public health s mission. Care management information such as immunization status had also been omitted from the use cases, as had demographic information. Discussion As the use of EHRs becomes more widespread and consistent, the ideal scenario is to have structured, computable, semantically interoperable data collected by the clinicians interacting with the patient. Developing CDEs for disease domains which are standardized across secondary uses will allow clinicians to input only one set of data. Theoretically this lowers the documentation burden on clinicians and allows the discrete data collected in an EHR to be re-used for multiple secondary uses, including public health. Since public health is an important secondary use for healthcare data, it should be a primary consideration for any national health information strategy and data standards activity. Through happenstance the founding Diabe-DS members were interested in research and quality secondary uses. Ideally, public health would have been involved as a major stakeholder at the start of Diabe-DS, but their absence allowed the Diabe-DS effort to address and articulate the incremental addition of additional important secondary uses to a previously defined domain CDEs standard. Theoretically, this approach should address public health data requirements the same as if they were part of the process from the start. So this was a good opportunity to document and reflect on our methods as they might generalize to future CDE and collect once, use many efforts. The purpose of this paper is not to fully describe a process of eliciting public health requirements for data elements in a domain. The purpose was to describe our experience adding a secondary use case to an existing collect once, use many model. This was not a trivial task, but will be necessary for domain-specific data element projects to think about. The most difficult part was reviewing the CDEs which had already been identified as necessary for the disease domain. This included reviewing the definition, values and data element names to ensure the CDE represented the information accurately. For diabetes care management and surveillance, much of public health s focus is on Type 2 diabetes which meant that it was necessary to determine the specific data public health needs for T1D focused surveillance and care management. One objective of this paper is to illustrate that there is a lot of work involved in achieving Collect once, Use many data use. The notion that the same data construct (e.g., diagnosis) could be collected in slightly different ways for different secondary uses obviously seems absurd to many. But to harmonize data elements means harmonizing communities and leveraging relevant work. The Public Health Community had done a thorough analysis of the space, including tasks and data requirements. The work for the Diabe-DS project was greatly enabled by their previous work. For other disease areas, this requirements gathering and use case development will have to be done. We recommend that the secondary use communities develop their requirements and supporting documentation (activities, use cases, etc.) and these then become harmonized in multi-disciplinary groups like Diabe-DS. Even with that work, the need to harmonize multiple disease-specific domains will require much hard work from disease experts and technical experts alike. Disease experts will be needed for their knowledge of the disease domain and technical experts to deal with technical components, data models, and integration of multiple secondary uses. Conclusion: Data standards are a critical component of interoperability and meaningful secondary use. Domain specific data standards efforts such as CDEs - will proliferate as these are sensible approaches to identify standards requirements from various stakeholders. Future domain specific CDE efforts will need to harmonize data elements across secondary uses in their disease area, and with data elements from other disease domains. These efforts can be informed by existing CDEs and use cases, as well as best practice recommendations and lessons learned from our work. Acknowledgements: The authors wish to thank the supporters and members of the Diabe-DS project listed at http://wiki.hl7.org/index.php?title=ehr_diabetes_data_strategy. In particular, we thank Maryanne Quinn, Donna DuLong, Luigi Sisson, Wendy Huang, and Scott Bolte for their significant contributions to the Diabe-DS project. 105

REFERENCES 1. ONC. HIT Standards Committee Draft Transcript; February 24, 2010: Office of the National Coordinator for Health Information Technology. 2010 [Cited 2011 Jun 28]. Available at: http://healthit.hhs.gov/portal/server.pt/gateway/ptargs_0_11673_911061_0_0_18/2010-02- 24_standards_transcript_draft.pdf. 2. Health Information Technology Standards Panel. Medication management. [Internet]. 2011 [Cited 2011 Mar 15]. Available at: http://www.hitsp.org/interoperabilityset_details.aspx?masteris=true&interoperabilityid=54&prefixalpha=1&apre fix=is&prefixnumeric=07 3. Public Health Data Standards Consortium. Pediatric electronic health record: public health perspectives. [Internet]. 2005 [Cited 2011 Mar 15]. Available at: http://www.phdsc.org/health_info/ped-electronic-healthrecord.asp. 4. Public Health Data Standards Consortium. Building a roadmap for health information systems interoperability for public health (Public health uses of electronic health record data). [White Paper]. [Internet]. 2008 [Cited 2011 Mar 3]. Available at: http://www.ihe.net/technical_framework/index.cfm#quality 5. National Quality Forum. [Internet]. 2011 [Cited 2011 Mar 15]. Available at: www.qualityforum.org. 6. National Quality Forum. Electronic quality measures. [Internet]. 2011 [Cited 2011 Mar 15]. Available at: http://www.qualityforum.org/projects/eg/emeasures/electronic_quality_measures.aspx#t=2&s=&p=1%7c 7. Kallem, C., Richesson, R, DuLong, D., Sison, L, Van Dyke, P., and Mon, D. Advancing secondary data uses through data Standards. J AHIMA. April 2011;82(4):38-39. 8. Health Level 7. HL7 healthcare development framework version 1.5[Internet]. 2009 [Cited 2011 Jul 5]. Available at: http://www.hl7.org/v3ballot/html/help/hdf/hdf.htm 9. Ahmadian L, Cornet R, Kalkman C, de Keizer NF. Development of a national core dataset for preoperative assessment. Methods Inf Med. 2009;48(2):155-61 10. Winget, M, Baron, JA, Spitz, MR, et al. Development of common data elements: the experience of and recommendations from the early detection research network. Int J of Med Inform. 2003;70(1):41-48 11. Health Level 7. Cardiology DAM. [Internet] 2008 [Cited 2011 Mar 3]. Available at: http://www.hl7.org/special/committees/cardiology/docs.cfm 12. Health Level 7. Tuberculosis DAM. [Internet]. 2009 [Cited 2011 Mar 3]. Available at: http://wiki.hl7.org/index.php?title=product_tb_dam 13. Richesson, R., et al., A strategy for defining common data elements to support clinical care and secondary use in clinical research, in 2010 AMIA Clinical Research Informatics Summit. 2010; San Francisco. Available at: http://crisummit2010.amia.org/files/symposium2008/100_richesson.pdf. 14. Institute of Medicine. The future of the public s health in the 21 st century. [Internet]. 2002 [Cited 2011 Mar 3]. Available at: http://www.iom.edu/reports/2002/the-future-of-the-publics-health-in-the-21st-century.aspx 15. Public Health Data Standards Consortium. Towards a functional standard on electronic data exchange between clinical care and public health. [Internet]. 2007 [Cited 2011 Mar 3]. Available at: http://www.phdsc.org/health_info/hrsa-panel.asp 16. Office of the National Coordinator. Public health case reporting detailed use case. [Internet]. 2008 [Cited 2011 Mar 3]. Available at: http://healthit.hhs.gov/portal/server.pt?open=512&objid=1202&&pageid=15673&mode=2&in_hi_userid=10732& cached=true 17. Orlova, A., Dunnagan, M., Finitzo, T., et al. An electronic health record-public health (EHR-PH) system prototype for interoperability in 21 st century healthcare systems. AMIA Annu Symp Proc. 2005; 2005:575-579. 18. Public Health Data Standards Consortium. Standards for public health data exchange: functional requirements standard for diabetes care management and surveillance. [Internet]. 2008 [Cited 2011 Mar 3]. Available at: http://www.phdsc.org/health_info/hrsa_2007_diabetes.asp 19. Orlova, A., Reed-Forquet, L. Knowledge representation in chronic care management: example of diabetes care management. [White paper]. 2010 20. Public Health Data Standards Consortium. 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. [Internet]. 2006 [Cited 2011 Mar 15]. Available at: http://www.phdsc.org/about/committees/pdfs/nhin/nyc_school_health_sss_spec_final_103006.pdf 21. HITSP. Public health case reporting interoperability specification. [Internet]. 2008 [Cited 2011 Mar 15]. Available at: 106

http://www.hitsp.org/interoperabilityset_details.aspx?masteris=true&interoperabilityid=364&prefixalpha=1&apr efix=is&prefixnumeric=11 22. American Diabetes Association. Standards of medical care in diabetes-2011. [Position paper]. Diabetes Care, 2010; (34) Supplement 1, pp S11-S61. doi:10.2337/dc11-s01 23. Wisconsin Department of Health Services. Wisconsin diabetes mellitus care guidelines. [Internet]. 2008 [Cited 2011 Mar 11]. Available at: http://www.dhs.wisconsin.gov/health/diabetes/guidelines.htm 24. HITSP Harmonization Framework [Internet]. Health Information Technology Standards Panel. 2009 [Cited 2011 Jul 5]. Available at: http://www.hitsp.org/harmonization.aspx 25. CDE Browser [Internet]. Cancer Data Standards Registry and Repository. 2011 [Cited 2011 Mar 17]. Available at: https://cdebrowser.nci.nih.gov/cdebrowser/ 107