Assure Health Information Technology Standards for Early Hearing Detection and Intervention (EHDI):

Transcription

1 Assure Health Information Technology Standards for Early Hearing Detection and Intervention (EHDI): Clinical Document Architecture (CDA) State EHDI Pilot Project Project Report 2013 Baltimore, Maryland

2 2 The Public Health Data Standards Consortium (PHDSC, The Consortium) is a national nonprofit membership-based organization of federal, state and local health agencies, professional associations, academia, public and private sector organizations, international members, and individuals. 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 data in order to improve individual and community health. To fulfill its mission the Consortium: Identifies priorities for new national standards for population health data; Promotes integrating health-related information systems to meet the needs of public and private organizations, agencies and individuals; Participates in national and international efforts to standardize health-related information; Represents public health interests in standards development organizations, data content committees and standards harmonization entities; and Educates the public health community about health information technology standards and the health information technology community about public health. 111 South Calvert Street Baltimore, MD Phone: (410) Fax: (866)

3 3 DISCLAIMER This document was developed under the Cooperative Agreement with the Centers for Disease Control and Prevention (CDC), Assuring HIT Standards for Public Health, Grant No.: 5U38HM The material in this document has not been subject to agency review and approval for publication as a Centers for Disease Control and Prevention (CDC) report. Mention of trade names, products, or services, does not convey, and should not be interpreted as conveying official CDC approval, endorsement, or recommendation.

4 4 CONTRIBUTING ORGANIZATIONS AND ACKNOWLEDGEMENTS Centers for Disease Control and Prevention (CDC) Mr. John Eichwald, Early Hearing Detection and Intervention (EHDI) Program, National Center on Birth Defects and Developmental Disabilities (NCBDDD), Project Officer. Public Health Data Standards Consortium (PHDSC, The Consortium) Dr. Anna Orlova, PHDSC s Executive Director and Visiting Associate Professor, Johns Hopkins School of Medicine, Principal Investigator. PHDSC Project Team: Ms. Sarah Quaynor, mpactsys, LLC, Project Manager Ms. Lori Reed-Fourquet, ehealthsign, Technical Manager; Ms. Lisa Nelson, Life Over Time Solutions, Data Modeler; Ms. Maiko Minami, HLN Consulting, LLC, Project Coordinator; and Ms. Alla Fridman, Project Financial Manager;. State of North Dakota Team North Dakota Early Hearing Detection and Intervention Program (ND EHDI), State of North Dakota Ms. Jerusha Olthoff, Program, Principal Investigator; Mr. Thomas Orluck, Database Specialist, Minot State University Sanford Health, North Dakota Mr. Scott Egeberg, Information Systems Interface Analyst; Mr. Kent Blanchard, Application Support Manager Trinity Health Minot, North Dakota Ms. Renae Johnson, RN Clinic - Nurse Manager State of Oregon Team Oregon Health Authority Center for Prevention and Health Promotion Ms. Heather Morrow-Almeida, Interim EHDI Coordinator; Ms. Dina Dickerson, Senior Informaticist; Mr. ChiaHua Yu, Public Health Informaticist; Ms. Meuy Swafford, EHDI Data Quality Coordinator, Mr. Trong Nguyen, System Administrator/Informatics Specialist Epic Mr. John Stamm, Configuration Advisor Oregon Health & Science University (OHSU) Hospital, Oregon Mr. Doug Clauder, Interface Engineer; Mr. Tom Drury, Interface Team Manager; Mr. Malcolm Chun, Provider Epic EMR Specialist; Ms. Karen Alexander, Clinical Workflow Analyst; Mr. Bud Garrison, Director of Clinical Informatics; Ms. Heather Durham, Audiologist; Orion Health Mr. John Dunn, Sales Director; Mr. Drew Ivan, Rhapsody Product Manager OZ Systems Dr. Terese Finitzo, Chief Executive Officer; Dr. Ken Pool, Chief Operating Officer; Ms. Lura Daussat, Program Coordinator; Dr. Matt Oefinger, Chief Technology Officer; Mr. Steve Montgomery, Vice- President of Operations; Mr. Nitin Kunte, Director of Research and Development Contributor Mr. Andrew McCaffrey, Computer Scientist, National Institute of Standards and Technology (NIST)

5 5 Table of Contents Executive Summary... 7 Background... 9 Interoperability Standards for EHDI... 9 Scope Purpose Document Organization Methodology Phases, Contributors, Activities and Timeline Recruitment Incentives Participants and Observers Process and Documentation CDA Pilot Project Design Use Case: Business Requirements, Workflow and Data Flow EHDI Reporting/Data Exchange Content and Data Harmonization Functional Requirements for Information Systems, Data Exchange Architecture and Selected Standards Functional Requirements CDA-Based Document Exchange Architecture and Interoperability Standards EHDI Reporting/Data Exchange Architecture and Selected Standards Resources on Vendors' Capabilities to Support EHDI CDA Pilot Projects CDA Pilot Project Implementation North Dakota (ND) EHDI CDA Pilot Project EHDI Reporting in North Dakota Project Statement Actors Use Case Data Requirements Interoperability Standards and Data Exchange Architecture Development Efforts Testing Oregon EHDI CDA Pilot Project EHDI Reporting in Oregon Project Statement Actors Use Case Data Requirements Interoperability Standards and Data Exchange Architecture Development Efforts Testing Lessons Learned Level of Effort Successes, Challenges and Recommendations Appendix A: CDA Pilot Project: Call for Participation Appendix B: CDA Pilot Project: State-Specific Newborn Hearing Screening Report Forms Appendix C: PHDSC Pilot Resources for Vendor System Certifications Appendix D: Pilot Participant Technical Readiness Assessment... 64

6 6 TABLE OF TABLES Table 1 EHDI CDA Pilot Project: Development Phases, Task, Activities and Timeline by Contributor Category Table 2 EHDI Reporting/Data Exchange Use Case Table 3 EHCP and NHS Outcome Report Data Table 4 North Dakota EHDI CDA Pilot Project Participants Table 5 North Dakota CDA Pilot Project: Standards and Development Efforts Table 7 North Dakota EHDI CDA Pilot Project: Test Plan Table 8 Oregon EHDI CDA Pilot Project Participants Table 9 Oregon EHDI CDA Pilot Project: Standards and Development Efforts Table 10 Oregon EHDI CDA Pilot Project: Work Plan Table 11 Oregon EHDI CDA Pilot Project: Test Plan Table 12 EHDI CDA Pilot Project: Level of Effort by Site and Project Team Role Table 14 Result Matrix For Integration Profile: Retrieve Form for Data Capture Table 15 Technical Assessment Checklist TABLE OF FIGURES Figure 1 EHDI Reporting/Data Exchange Use Case Workflow Figure 2 MDHT Methodology for CDA-Based Models Figure 3 IHE Early Hearing Care Plan (EHCP) Model in MDHT Figure 4 CDA Newborn Hearing Screening (NHS) Outcome Report Figure 5 EHDI Reporting/Data Exchange Architecture: Content Creators and Content Consumers Figure 6 North Dakota EHDI CDA Pilot Project: Use Case and Data Flow Figure 7 North Dakota Early Hearing Care Plan Document Figure 10 Oregon EHDI CDA Pilot Project: Use Case and Data Flow Figure 11 Oregon EHDI Information System NHS Web Screen Figure 12 Oregon CDA Newborn Hearing Screening Outcome Report Figure 13 Oregon EHDI CDA Pilot Project: Settings, Systems, Standards and Actor Roles Figure 14 Oregon EHDI CDA Pilot Project Architecture Figure 15 North Dakota Hearing Screening Reporting Form Figure 16 Oregon Newborn Hearing Screening Facility Reporting Form... 60

7 7 Section 1 Executive Summary The Health Level Seven (HL7) Clinical Document Architecture (CDA) Release 2 (R2) standard 1 was named in the Meaningful Use of Electronic Health Records systems (EHR-S) for data exchanges between clinical systems. 2,3 In August 2011, the Surveillance Implementation Guide Power Team of the Health Information Technology (HIT) Standards Federal Advisory Committee published a report raising a strategic issue regarding the need for a uniform CDAbased specification for public health reporting. 4 In September 2011, the HIT Standards Committee recommended the use of the HL7 CDA standard as a future direction for electronic public health reporting and data exchanges between clinical and public health information systems (PH-IS). 5 In May 2012, the Public Health Data Standards Consortium (PHDSC), with support from the Centers for Disease Control and Prevention (CDC), had successfully completed CDA for Public Health pilot projects for reporting cases of communicable diseases from clinical EHR-Ss to public health information systems (PH-ISs) in three jurisdictions: tuberculosis in the State of Delaware; and pertussis in the State of New York and San Diego County. 6 The Early Hearing Detection and Intervention (EHDI) CDA pilot projects were built on the methodology for deployment of the standards-based interoperable HIT solutions for public health reporting developed in the 2012 communicable diseases CDA pilot projects. During August 2012 through May 2013, PHDSC conducted two pilot projects to demonstrate the feasibility of using the HL7 CDA standard for electronic data reporting from birthing facility EHR- S to public health EHDI information systems (EHDI-IS) and from EHDI-IS to pediatrician's EHR- S thus enabling the deployment of standards-based interoperable HIT solutions to support activities of the state EHDI programs. The EHDI CDA pilot projects were conducted with participation of State EHDI programs in two jurisdictions: North Dakota and Oregon (Participants). Representatives from State EHDI programs in eleven jurisdictions (Florida, Maryland, Massachusetts, Michigan, Minnesota, Missouri, Ohio, Oklahoma, Pennsylvania, Rhode Island, South Carolina, Texas and Washington) participated as Observers and contributed to the project design. During September 1 Health Level Seven (HL7). Clinical Document Architecture (CDA) Standard. Release 2. URL: 2 US Department of Health and Human Services Washington (DC): Office of the National Coordinator for Health Information Technology (US); July 13, Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology. Regulation Identification Number 0991-AB58. 3 Medicare & Medicaid EHR Incentive Program, Meaningful Use Stage 1 Requirements Overview. Centers for Medicare and Medicaid Services Web site. Guidance/Legislation/EHRIncentivePrograms/downloads/MU_Stage1_ReqOverview.pdf. Accessed May 18, Health Information Technology Standards Committee: Surveillance Implementation Guide Power Team (Power Team) Final Report. URL: 5 Health IT Standards Federal Advisory Committee. Recommendations from the Public Health Surveillance Summer Camp. September 28, URL: &cached=true# Public Health Data Standards Consortium (PHDSC). CDA for Public Health Pilot project. Project Report Public Health Data Standards Consortium Web site. Accessed February 28, 2013.

8 through March 2013, PHDSC worked with Participants and Observers on the design of the pilot project. During March through May 2013, the PHDSC Technical Assistance Team assisted Participants and their public health and EHR vendors to implement the pilot projects. With the objectives of the EHDI CDA pilot projects successfully met, State EHDI programs in the other jurisdictions as well as other public health programs may use our experience and lessons learned in electronically exchanging their data with EHR-Ss using interoperable standard-based IT solutions. Aimed at advancing public health capabilities for electronic data exchanges using CDA standards, this project helped align State PH-ISs with the interoperable standards-based IT solutions used by EHR-S vendors and Health Information Exchanges (HIEs). This project advances the development and use of interoperability HIT standards in public health and expands the capabilities for electronic public health data exchanges with clinical information systems. We believe that this project will help to develop a national model for deploying interoperability standards in public health.

9 9 Section 2 Background Interoperability Standards for EHDI The HL7 CDA R2 standard 7 was named in the MU of EHR technology for data exchanges between clinical systems. 8 In September 2011, the Health IT Standards Federal Advisory Committee recommended the use of the HL7 CDA standard as a future direction for electronic data exchanges between clinical and public health information systems for public health reporting. 9 The HL7 CDA R2 standard allows representation of clinical information in a structured format (CDA templates) that is similar or identical to the paper forms traditionally used for public health reporting. In September 2011, the Quality, Research, and Public Health Committee (QRPH) of the Integrating the Healthcare Enterprise (IHE) published the Early Hearing Care Plan (EHCP) Content Profile (i.e., interoperability standard). 10 The Profile describes an Early Hearing Care Plan content, based on CDA R2 standard. EHCP is created by a state public health EHDI program jurisdictionally responsible for the newborn hearing screening and short-term care follow-up for children with hearing loss. 11 EHCP includes the outcomes of the newborn hearing screening, conducted at the birthing facility, risk indicators for hearing loss and the follow-up instructions for pediatric primary care physicians of a newborn to properly manage audiology care in newborns and young children. The EHCP data elements were modeled in a set of modular definitions (sections or CDA templates) reusable across various clinical and public health forms and documentation (e.g., newborn hearing screening outcome reports, referrals, etc.) and conformant with design patterns established for EHR-Ss and interoperable data exchanges. The IHE EHCP Content Profile defines the templates (required and optional) and indicates how the templates are organized into documents, sections, and specific data elements (entries) to construct EHDI report instances. The IHE EHCP standard was tested at the North American IHE Connectathon in 2012 and Based on the testing outcomes, the standards had been updated. The EHCP has also been included as a specific use case in the overarching Care Plan Content Profile standard that is currently under development by the IHE Patient Care Coordination Committee. The updated 7 Health Level Seven (HL7). Clinical Document Architecture (CDA) Standard. Release 2. URL: 8 US Department of Health and Human Services Washington (DC): Office of the National Coordinator for Health Information Technology (US); July 13, Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology. Regulation Identification Number 0991-AB58. 9 Health IT Standards Federal Advisory Committee. Recommendations from the Public Health Surveillance Summer Camp. September 28, URL: &cached=true# Integrating the Healthcare Enterprise (IHE). Early Hearing Care Plan (EHCP). Published September Accessed December, Joint Committee on Infant Hearing (JCIH) Web site. Accessed July 18, Integrating the Healthcare Enterprise (IHE). Connectathon 2012 and Integrating the Healthcare Enterprise. Accessed February 28, 2013.

10 EHCP model is currently available from the open source Model Driven Health Tool (MDHT) CDA document repository. 13 Using the CDA-based EHCP standard, the project team built a CDA-based Newborn Hearing Screening (NHS) Outcome Report for reporting of the hearing test results from the birthing facility EHR-S to the State EHDI program. This was aimed at accommodating the data reporting mechanisms currently used by state EHDI information systems, such as (1) receiving the NHS Outcome Reports from the birthing facilities to populate the EHDI-IS; and/or (2) automated processing of the newborn hearing screening results from a hearing screening device, and the demographics from the birthing facility clinical EHR-S by the EHDI-IS to generate the EHCP. Scope With support from the CDC, PHDSC has conducted two pilot projects to demonstrate electronic data exchange between clinical EHR systems and EHDI program information systems using the HL7 CDA standard and the IHE QRPH EHCP Content profile standard. The EHDI CDA pilot projects were conducted in two jurisdictions: North Dakota and Oregon as follows: I. In Oregon we piloted the reporting the jurisdictionally-defined NHS Outcome Report generated by the birthing facility EHR-S to State EHDI-IS; and II. In North Dakota we demonstrated the creation of a jurisdiction-specific EHCP by the State EHDI-IS based on the newborn hearing screening results from the birthing facility's EHR-S; and reporting of the EHCP to the pediatrician EHR-S to care for the newborn. Purpose The purpose of the EHDI CDA pilot project was to demonstrate the feasibility of using the HL7 CDA R2 standard for electronic communication of data from birthing facility EHR-S to public health EHDI-IS and from EHDI-IS to pediatrician EHR-S thus enabling the deployment of standards-based interoperable HIT solutions to support activities of the state EHDI programs. Aimed at advancing public health capabilities for electronic data exchanges using CDA standards, this project helped align state EHDI information systems with the interoperable standards-based IT solutions used by EHR vendors and HIEs. We believe that together with the 2012 PHDSC CDA pilot projects for communicable diseases, the EHDI CDA pilot project may serve as a national model for deploying interoperability standards in public health. Document Organization This report provides the description of the overall project methodology, site-specific narratives with project-related documentation, and lessons learned through the process of planning, designing and implementing the two pilot projects. The Appendices contain the Call for Participation used for recruiting pilot project participants (Appendix A); forms for reporting of EHDI data in North Dakota and Oregon (Appendix B); resources for researching vendor system 13 Open Health Tools Model Driven Health Tool (MDHT) Project. Open Health Tools Web site. Accessed June 12, 2013.

11 certifications for supporting standards-based interoperable HIT solutions (Appendix C); and a technical readiness assessment checklist for pilot participants (Appendix D). 11

12 12 Section 3 Methodology The EHDI CDA pilot projects were built on the methodology for deployment of the CDA-based interoperable HIT solutions for public health reporting developed in the 2012 PHDSC communicable diseases CDA pilot projects for reporting cases of communicable diseases from clinical EHR-Ss to public health information systems in three jurisdictions: CDA Tuberculosis Case Report in the State of Delaware; and CDA Pertussis Case Reports in the State of New York and San Diego County. 6 Specific activities focused on the following objectives: 1. Assess existing documentation on state EHDI reporting. 2. Assess existing interoperability standards applicable for EHDI reporting and data exchange between healthcare providers and State EHDI programs. 3. Design and implement pilot projects on the deployment of the standard-based HIT solutions in two states. 4. Develop technical documentation required for these pilot projects. 5. Gather data from the pilot projects to provide recommendations on how CDA may be used for public health case reporting. Sections that follow describe the project methodology and outcomes. Phases, Contributors, Activities and Timeline The CDA pilot project included the following six phases: 1. Planning: During the planning phase, the PHDSC project team drafted the Call for Participation (Appendix A) and distributed information about the project to recruit project participants. Working with recruited State EHDI programs, the PHDSC team defined the project scope and objectives, high-level use case, pilot project tasks, expected outcomes, schedule, and deliverables. 2. Recruitment: The PHDSC project team published the Call for Participation via the PHDSC listserv and the listserv of 50 State EHDI programs provided by CDC, to recruit pilot project participants from state EHDI programs as follows. The Call for Participation invited state EHDI programs to join the project as Participants or Observers. Upon receiving completed applications, the PHDSC project team conducted technical assessments with 5 State EHDI programs interested in becoming pilot project Participants, and selected 2 programs (North Dakota and Oregon) to participate in the pilot project. The selection of these programs was based on the technical readiness of their EHDI-ISs and their clinical partners to carry out project activities. The remaining three EHDI programs continued to participate in the project together with Observers. 3. Design: The PHDSC project team collaborated with the Participants (State EHDI program staff, their IT team and clinical partners) to document the jurisdiction-specific requirements for EHDI data exchanges for the design and expected outcomes of the pilot project for each Participant. This included specifying (a) jurisdiction-specific guidelines for NHS and short-term care follow-up; 14,15 (b) paper forms used for data 14 North Dakota Early Hearing Detection and Intervention Program Web site. Accessed February 12, Early Hearing Detection and Intervention (EHDI) Newborn Hearing Screening Protocol. Oregon Department of Human Services Web site. Accessed July 18, 2013.

13 13 collection, if any, or data requirements for the automated data collection (Appendix B); (c) capabilities of existing EHDI-IS used by the state EHDI programs and EHR-S used by their clinical partners; (d) interoperability standards applicable to support data exchanges between EHDI-IS and EHR-S; and (e) any design constraints. The Work Plan had been developed for each Participant with the project tasks, point of contacts and timeline (see CDA Pilot Project Implementation section for details). Participants amd PHDSC team met via bi-weekly web-conferences to track the fulfillment of the Work Plan. Observers contributed to the review and critique of the pilot project design and recieved updates on the project progress via monthly web-conferences. 4. Implementation: Participants' technical teams implemented the jurisdiction-specific design for the pilot, with the technical assistance from the PHDSC project team. This included creating jurisdiction-specific CDA-based documents (NHS Outcome Report for OR and EHCP for ND), and implementing the information exchange with partner systems using the selected interoperability standards. 5. Testing: Using the Test Plan developed for each jurisdiction (see CDA Pilot Project Implementation section for details) the PHDSC project team conducted the test demonstration with the Participants' teams and documented that all the expected outcomes were successfully met, the generated artifacts (screenshots, codes) were correctly generated and met all standards' constraints and requirements. 6. Reporting: The PHDSC project team drafted the report to document the overall project methodology and pilot project design and outcomes by Participants. The State teams reviewed the draft report. They also contributed to the section describing Participants' experience and lessons learned from the project by responding to the post-pilot survey. Each EHDI CDA pilot project was conducted by a team that included 3 categories of contributors - facilitator, user and developer - as follows: 1- PHDSC team (facilitator and technical assistance); 2-State EHDI staff and clinicians team (users); and 3 - HIT vendors (developers). Specifically, they included individuals in a specific role who were responsible for the following project tasks (by member category): I. Facilitator: PHDSC Project Team/Technical Assistance Team responsible for the initial project planning, recruitment, technical assistance throughout the project, development of the project documentation and final report. The PHDSC project team included: o Project Director, responsible for the overall project oversight, contracting and reporting o Project Manager, responsible for the overall management of project activities and the development of the project documentation o Data Modeler, responsible for developing jurisdiction-specific CDA instances of the EHDI reports o Technical Manager, responsible for managing the technical assistance provided to the state vendors to implement and test CDA-based EHDI reporting and data exchange o Project Coordinator, responsible for coordinating and facilitating teams' calls, maintaining project documentation, and managing project wiki pages II. User: State EHDI Staff and Clinicians (representatives from State EHDI programs and healthcare facilities involved in the project), responsible for defining the jurisdictionspecific reporting/data exchange use case and data requirements for the jurisdictionspecific NHS Outcome Report, and the EHCP III. Developer: EHR-Ss, EHDI-ISs and HIEs vendors, responsible for implementing the CDA-based reporting of NHS Outcome Report from the birthing facility EHR-S to state

14 14 EHDI-IS (Oregon pilot project); and generating the EHCP from the NHS data and reporting the EHCP from EHDI-IS to pediatrician's EHR-S (North Dakota pilot project). Table 1 describes specific activities and tasks (what, who, how) by project phase, project contributor, and timeline. Table 1 EHDI CDA Pilot Project: Development Phases, Task, Activities and Timeline by Contributor Category Planning Phase Task/Activity Timeline Recruitment Design PHDSC Project Team Tasks (Facilitator) Assemble project team Define project scope Develop communication materials Define communication channels and target audiences Develop project management infrastructure (listservs, wiki pages, web-conference support infrastructure) Conduct web-conferences during the project period for Participants and Observers Manage pilot implementation timelines and deliverables across sites PHDSC Project Team Tasks (Facilitator) Disseminate recruitment letter (Call for Participation) Collect responses Conduct technical readiness assessment of the Participants' candidates Select Participants Assemble the Pilot Project Participants/Observers Groups EHDI Staff and Clinician Tasks (User) Select use case for reporting/data exchange Identify partners (EHDI staff, clinicians, vendors) Define jurisdiction-specific workflow in a use case based on the jurisdiction-specific guidelines Define jurisdiction-specific data requirements for the NHS Outcome Report and the EHCP Define high-level architecture for data reporting Vendors Tasks (Developer) Analyze use case and data requirements Confirm capabilities of the information system to send-receive NHS Outcome Report or EHCP Confirm data reporting schema Select and deploy standards to support data reporting/exchange Define pilot implementation timeline and deliverables PHDSC Project Team Tasks (Facilitator) Assist in the development of the site-specific pilot project designs as follows: Document the site-specific use case (workflow and data flow) Document site-specific data requirements for the NHS June August 2012 August October 2012 November March 2013

15 15 Phase Task/Activity Timeline Outcome Report and EHCP Harmonize site-specific data requirements with the CDA data model; develop site/report-specific CDA instances Develop site-specific schemas for data reporting Assist vendor in selecting/deploying standards for data reporting Develop site-specific Work Plan, Test Plan and testing documentation Implementation Testing Reporting Vendors Tasks (Developer) Deploy CDA-based data reporting/exchange PHDSC Project Team Tasks (Facilitator) Assist vendor in deploying CDA-based data reporting EHDI Staff and Clinician Tasks (User) Validate a set of tests Vendors Tasks (Developer) Complete a set of tests Complete testing documentation PHDSC Project Team Tasks(Facilitator) Test CDA-based deployment for data reporting/exchange Review vendors testing documentation PHDSC Project Team Tasks (Facilitator) Develop project report Conduct follow-up survey with Users and Developers EHDI Staff and Clinician Tasks (User) Review project report Complete survey Vendor Tasks (Developer) Review project report Complete survey April-May 2013 May 2013 June - August 2013

16 16 Recruitment In August-September 2012, we distributed a Call for Participation 16 (Appendix A) to recruit State EHDI programs and their EHR vendors and EHDI-IS vendors interested to implement the CDAbased EHDI reporting/data exchange in their jurisdictions. The Call was distributed via weekly e- mail to the PHDSC listserv of over 300 members as well as the listserv of the 50 State EHDI programs provided by CDC. The Call described two roles that State EHDI programs could choose to engage in the projects, as follows: Participant: State EHDI programs and their EHR-S and public health IT vendors interested in demonstrating the use of CDA standards for reporting/receiving the results of NHS from birthing facilities to EHDI programs or sending EHCP from EHDI-IS to pediatrician's EHR-S. Observer: State EHDI programs and their EHR-S and public health IT vendors interested in contributing to the design and implementation of the pilot project at participating sites. Incentives The incentives for participation in the project for both Participants and Observers included the ability to work with national leaders in HIT interoperability to prepare their programs for the use of CDA standards for EHDI reporting/data exchange. Specific benefits included: For Participants: o Alignment of agency/program-based IT solutions with interoperability standards used by EHR-S and HIE vendors o Becoming a national model for deploying interoperability standards in public health o Technical assistance from the PHDSC Project Team to deploy standard-based interoperable HIT solutions o Funding was provided for Participants to support the implementation of CDA-based EHDI reporting/data exchange. For Observers: o Involvement in guiding the deployment of interoperable IT solutions for EHDI reporting/data exchange o Preparation for transitioning to interoperability standards for electronic EHDI reporting/data exchange in their jurisdictions. Participants and Observers Representatives from eleven public health agencies expressed interest in joining the project. Five of these organizations were interested in a Participant role; after a technical assessment, we selected two jurisdictions (North Dakota and Oregon) to serve this role. The remaining states participated in the Observer role. The breakdown was: 16 PHDSC Call for Participation: Clinical Document Architecture (CDA) Standards for Public Health Pilot Project. URL:

17 17 Participants 1. North Dakota Early Hearing Detection and Intervention Program (ND EHDI) 2. Oregon Health Authority, Center for Prevention and Health Promotion Observers 1. Maryland Department of Health and Mental Hygiene, Office for Genetics and People with Special Health Care Needs, Maryland Infant Hearing Program 2. Massachusetts Department of Public Health, Universal Newborn Hearing Screening Program (UNHSP) 3. Michigan Department of Community Health (MDCH) Early Hearing Detection and Intervention Program (EHDI) Program 4. Rhode Island Hearing Assessment Program (RIHAP), State of Rhode Island Department of Health 5. Florida Department of Health, Newborn Screening Follow-Up Program 6. Missouri Department of Health and Senior Services, Bureau of Genetics and Healthy Childhood, Newborn Hearing Screening Program 7. Ohio Department of Health, Infant Hearing Program 8. Pennsylvania Department of Health, Bureau of Family Health, Newborn Screening and Genetics 9. South Carolina Department of Health and Environmental Control, Early Hearing Detection and Intervention Program 10. Texas Early Hearing Detection and Intervention (TEHDI), Department of State Health Service, 11. Washington State Department of Health, Early Hearing-loss Detection, Diagnosis and Intervention (EHDDI) program Process and Documentation We conducted monthly one-hour web-conferences for Participants and Observers during October through May 2013 to work on the pilot project design, data harmonization and providing project updates. In addition, we also conducted site-specific calls to refine site-specific data, information exchange requirements, and to deploy CDA-based standards and supporting infrastructure standards. In April and May 2013, we conducted testing for CDA-based EHDI reporting/data exchange at the participating sites. Documentation developed during the project, including call information and materials presented at the calls was maintained at the project wiki pages at Pilot. In addition, Participant-specific documentation was maintained at the individual project wiki pages as follows: North Dakota EHDI CDA Pilot Project Wiki (URL: ND) Oregon EHDI CDA Pilot Project Wiki (URL:

18 18 Section 4 CDA Pilot Project Design Use Case: Business Requirements, Workflow and Data Flow Working with Participants and Observers, PHDSC developed the EHDI Reporting/Data Exchange Use Case. The Use Case described the participants (actors) of the reporting process: Business Actors (humans) newborn, mother (caregiver), birthing facility's staff, audiologist, public health program staff, pediatrician; and Technical Actors (information systems) clinical EHR-S, EHDI-IS, and HIE. The Use Case also expressed actions - clinical and public health workflow with specific steps describing the patient - provider interactions, i.e., business requirements. In addition, the Use Case specified specific documentation (forms or other documents) generated during these steps (data flow and data exchange content); and the interactions between the Business Actors (persons), and the Technical Actors (information systems) supporting the workflow and data flow. Lastly, the Use Case specified the scope of data exchanges, i.e., entry conditions (start) and exit conditions (finish) for data reporting/exchange. Table 2 presents the detailed description of the EHDI Reporting/Data Exchange Use Case. This Use Case served as a basis for consensus across Participants and Observers on EHDI reporting/data exchange business requirements and data requirements for the pilot project. This Use Case was successfully demonstrated at the 2013 Health Information Management and Systems Society (HIMSS) Interoperability Showcase, New Orleans, March 2013 by the PHDSC team. This Use Case was aligned with the harmonized Child Health Use Case of the Public Health Reporting Initiative (PHRI), Standards & Interoperability (S&I) Framework of the Office of National Coordinator for HIT (ONC). 17 Participants (Oregon and North Dakota EHDI programs) performed further analysis of the business and data requirements based on their jurisdictional needs and resources to tailor the Use Case to site-specific requirements for the pilot project. As a result, certain steps were excluded from the Use Case, however the overall representation of the actors and actions were preserved across the two sites. This allowed comparability and reuse of information exchange approaches across the sites. The specific implementation of the Use Case at each Participant's site is presented on the Use Case workflow diagram (Figure 1) that depicts two scenarios for data exchanges between Technical Actors (information systems) supporting reporting of the NHS Outcome Report from Birthing Facility's EHR-S to state EHDI-IS (Scenario 1); and generation and transmission of the EHCP from state EHDI-IS to pediatrician's EHR-S (Scenario 2). Scenario 1 was implemented in the Oregon and scenario 2 in the North Dakota EHDI CDA pilot projects, respectively, as described in more detail in Section 5 below. 17 Office of National Coordinator for Health Information Technology (ONC). Standards & Interoperability (S&I) Framework. Public Health reporting Initiative (PHRI), Child Health Use Case. S&I Framework Web site. +Data+%26Terminology+Harmonization+Sub-Workgroup?responseToken= f13bef267b62f16edcea Accessed June 18, 2013.

19 19 Table 2 EHDI Reporting/Data Exchange Use Case Use Case Name: EHDI Reporting/Data Exchange Business Actors Newborn, Mother (caregiver), Birthing Facility's Staff, Hospital (Audiology) staff, EHDI (Stakeholders) Program Staff, Health Information Exchange Staff Technical Actors Birthing Facility EHR-S (Systems) Public Health EHDI-IS Health Information Exchange Service Flow of Events Data Exchange Content 1. Newborn is delivered. Demographics, Antepartum 2. Physician conducts initial physical exam Record, Prenatal Record, Labor & Delivery Record, Postpartum Record, Newborn EHR 3. Newborn is due for hearing test. Mother (caregiver) consents to the hearing test (consent may be optional) Consent 4. Physician orders a hearing test (may be standing order) Test Order or Standing Order 5. Hospital staff conducts hearing test Hearing Test Results 6. Birthing facility staff records results/enters hearing test results a. Enters hearing test result data directly into EHR-S or b. Demographic data and hearing test results from hearing screening device are electronically transferred to the EHDI- IS 7. Newborn Hearing Screening (NHS) Outcome Report is sent electronically from EHR-S to EHDI-IS directly or via HIE Hearing Test Results NHS Outcome Report 8. EHDI-IS receives Notification of Report Availability Notification of Report Availability 9. EHDI program staff reviews the Report and uploads it into EHDI-IS NHS Outcome Report 10. EHDI-IS sends Acknowledgement of Receipt of the Report to EHR-S directly or via HIE 11. EHDI-IS generates the Early Hearing Care Plan (EHCP) from imported demographic data and hearing screening results and sends it to pediatrician's EHR-S directly or via HIE Acknowledgement of Receipt Early Hearing Care Plan 12. Pediatrician's EHR-S receives Notification of EHCP Availability Notification of EHCP Availability 13. Pediatrician reviews the EHCP and uploads it into EHR-S Early Hearing Care Plan 14. EHR-S sends Acknowledgement of Receipt of the EHCP to EHDI-IS directly or via HIE Pre-conditions Post-conditions Preferred Timing Birthing Facility's EHR-S, HIE, EHDI-IS EHDI-IS; Pediatrician's EHR-S Jurisdictionally-defined, e.g., daily updates Acknowledgement of Receipt

20 20 Figure 1 EHDI Reporting/Data Exchange Use Case Workflow Scenario 1 Birthing Facility's EHR-S sends and EHDI-IS receives NHS Outcome Report via HIE or directly (Use Case Steps 7-10) Scenario 2 EHDI-IS is integrated with the Birthing Facility's EHR-S to enter/receive NHS results data from the testing device. Based on the NHS result data, EHDI-IS generates and sends Early Hearing Care Plan to Pediatrician's EHR-S directly or via HIE (Use Case Steps 11-14).

21 21 EHDI Reporting/Data Exchange Content and Data Harmonization The EHDI documents used for the EHDI CDA pilot project included: 1. Newborn Hearing Screening Outcome Report - NHS Outcome Report and 2. Early Hearing Care Plan - EHCP. The CDA templates for both documents had been developed based on the IHE Early Hearing Care Plan Content Profile (an interoperability standard). 18 IHE published the EHCP content model from the Profile in the open source Open Health Tools Model-Driven Health Tool. As stated earlier. MDHT allows the creation of computable models of CDA templates. It also serve as a library of the CDA-based document models that re-use common CDA templates (sections/entries, e.g., patient demographic, social history, medical summary and other) across different documents. More information is provided below about MDHT, and how it was applied during this project. The NHS Outcome Report was modeled as a subset of the EHCP model from the Procedures and Results sections that are relevant to the representation of the newborn hearing screening outcomes. Table 3 below presents the data requirements for each document type. Table 3 EHCP and NHS Outcome Report Data CDA Section Section Description EHCP NHS Outcome Report Header Contains patient demographic information and details Yes Yes Risk Indicators for Hearing Loss Contains a review of systems, family /social history, and/or physical examination details, as well as any necessary assessments of functional status or risks. Yes No Active Problems Provides diagnoses based on assessments, diagnostic results, and other information received from other providers. This is a list of conditions associated with the newborn that will inform the assessment of risk (e.g., baby has birth defect). Yes No Physical Exam Includes aspects of the physical exam related to hearing screening or risk indicators for hearing loss. Yes No Review of Systems Contains a narrative description of the responses the patient gave to a set of routine questions on the functions of each anatomic body system. Yes No Care Plan Describes the appointments, referrals, treatments, diagnostic orders, and interventions necessary to conform to the jurisdiction public health authority directed guidelines under the plan. This includes resources to perform these procedures (e.g. Joint Committee on Infant Hearing Yes No 18 Integrating the Healthcare Enterprise (IHE). Early Hearing Care Plan (EHCP). Published September Integrating the Healthcare Enterprise Web site. Accessed June 18, 2013.

22 22 CDA Section Section Description EHCP NHS Outcome Report (JCIH) guidelines 11, task lists, and instructions to the provider for follow-up care expressed as jurisdictionally defined free-text, and possibly coded values if available. Procedures and Interventions Documents that hearing screening procedure was performed. If the procedure is not performed, the reason is indicated. Yes Yes Hearing Screening Coded Results Contains a narrative (free-text) description of the patient s relevant studies (e.g., hearing screening results) as well as the hearing screening method. When the screening results are not available, the reasons the results are not available are provided. Yes Yes Model Driven Health Tools - MDHT 13 - is an open source application to promote interoperability in the development of a shared electronic repository of CDA templates for clinical documents and now public health reports and documents. It promotes shared artifacts between related healthcare standards, and supports the work to develop customized CDA-based document specifications for specific needs, e.g., jurisdiction-specific instances of public health reports built from the re-usable CDA templates. In 2012, PHDSC used MDHT to develop public health case reports for 15 communicable diseases. 6 Two of these conditions (tuberculosis (TB) and pertussis) were used for the CDA for Public Health pilot projects that served as prototypes for the current project. The jurisdiction-specific instances for the Delaware TB Case Report as well as the New York State and San Diego County Pertussis Case Reports had been developed in MDHT from the conditionspecific case report models for the CDA pilot projects in these jurisdictions. MDHT can be used to develop CDA models that can be reused to develop additional CDA models within the tool. In addition, there are gateway technology products that have implemented interfaces (e.g., Mirth) using the MDHT CDA models to parse and generate CDA-based documents from the EHR-S HL7 Continuity Care Document (CCD) 19 standard content. MDHT generates CDA-based documents in the Extensible Markup Language (XML) format 20 thus translating human readable data from the paper-based forms modeled in MDHT into machine-readable format. Figure 2 presents the MDHT methodology for instance document generation that integrates the design of the CDA-based document models from the human readable content, generation of the XML formats of these models, testing/validation of the formats, and their publication in the MDHT library. 19 Health level Seven (HL7) Continuity Care Document (CCD) Standard. Health Level Seven (HL7) Web site. Accessed August 14, Extensible Markup Language (XML). World Wide Web Consortium (W3C) Web site. Accessed July 19, 2013.

23 23 Figure 2 MDHT Methodology for CDA-Based Models 21 Figure 3 provides an example of the CDA-based IHE EHCP modeled in MDHT, and Figure 4 shows the CDA-based NHS Outcome Report model in MDHT derived from the EHCP model. To generate the NHS Outcome Report model shown in Figure 4, we used data elements from the ND and OR EHDI programs forms presented in the Appendix B. Please note that demographic data are contained in the header of the CDA (not shown in the Figures 3 and 4). Figure 3 IHE Early Hearing Care Plan (EHCP) Model in MDHT 21 Office of National Coordination for Health Information Technology (ONC). Standard and Interoperability (S&I) Framework. Accessed June 18, 2013.

24 24 Figure 4 CDA Newborn Hearing Screening (NHS) Outcome Report Once the CDA report/document model has been created, MDHT can automatically develop any of the following related artifacts: Generate CDA Report/Document Content Specifications a Content Profile (in IHE terms) or Implementation Guide (in HL7 terms) that describes how to implement HL7 CDA R2 standard to represent specific data content (data set or form) a great advantage for the currently lengthy manual process that is prone to errors from incorrect data modeling, coding and typos. Generate CDA Documents Samples/Instances the model can generate sample CDA documents for testing of the model and implementation support. Generate Conformance/Validation Tools the model can be used to generate tools within MDHT to verify that any CDA instances created from the model (e.g., jurisdiction-specific reports) are conformant to the model constraints. Currently. there are many projects in progress with the goal of continuing to use and improve the functionality, effectiveness, and applicability of MDHT for various use cases. The Office of the National Coordinator for Health Information Technology (ONC) adopted MDHT for the Standards & Interoperability (S&I) Framework initiative to support data content standardization. 22 This EHDI CDA pilot project contributed to the MDHT CDA document library by developing the NHS Outcome Report model that can be used by various EHDI programs to create their jurisdiction specific instances of these reports, thus enabling data comparability across programs. Through this pilot project EHDI programs join the list of on-going projects to use MDHT including projects from ONC S&I Framework, Center for Medicaid and Medicare Services (CMS). 23 Our experience in using MDHT may be useful for other public health programs interested in developing standardsbased CDA documents for interoperable health information exchanges for public health reporting and data exchanges. 22 Office of National Coordination for Health Information Technology (ONC). Standard and Interoperability (S&I) Framework. URL: 23 Open Health Tools Model Driven Health Tools Project for CDA. URL:

25 25 Functional Requirements for Information Systems, Data Exchange Architecture and Selected Standards Functional Requirements The participating Technical Actors in the EHDI Use Case (Table 2) should be able to support EHDI workflow, data flow and content via the following functional requirements. Please note that each State implemented subsets of these requirements: Birthing Facility's EHR-S Requirements Generate EHR for a newborn Collect, store, manage data on newborn hearing screening Generate NHS Outcome Report for a newborn Send NHS Outcome Report to State EHDI-IS Receive the Acknowledgement of Receipt from State EHDI-IS State EHDI-IS Requirements Generate EHDI record for a newborn Receive NHS Outcome Report from birthing facility's EHR-S Upload, store, manage NHS data for a newborn Generate EHCP Send EHCP to pediatrician's EHR-S Receive Notification of Document Availability from HIE Receive the Acknowledgement of Receipt from EHR-S Pediatrician's EHR-S Requirements Receive EHCP from state EHDI-IS Receive Notification of Document Availability from HIE Send Acknowledgement of Receipt of EHCP to State EHDI-IS Upload, store, and manage EHCP data for a newborn. Pediatrician's EHR-S Requirements Receive NHS Outcome Report and EHCP documents from EHR-S and State EHDI-IS Send Notification of Document Availability to EHDI-IS and EHR-S Receive and transmit the Acknowledgement of Receipt to EHR-S and State EHDI-IS. CDA-Based Document Exchange Architecture and Interoperability Standards Participating Technical Actors in the EHDI Use Case play roles of Content Creators (senders) and Content Consumers (receivers) for the data exchange in the data exchange architecture shown on Figure This high-level data exchange architecture is deployed in the IHE Content Profiles. Please note that thehe role of Content Updater was out of scope for this pilot project. 24 IHE Patient Care Coordination Technical Framework Supplement. Early Hearing Detection and Intervention Workflow Definition (EHDI- WD). Integrating the Healthcare Enterprise Web site. Acessed June 3, 2012.

26 26 Figure 5 EHDI Reporting/Data Exchange Architecture: Content Creators and Content Consumers 25 The same Technical Actor can play various roles in the data exchange. For example, the Birthing Facility's EHR-S is Content Creator for the NHS Outcome Report and Content Consumer for the Acknowledgement of Receipt; the EHDI-IS is Content Consumer for the NHS Outcome Report and Content Creator for the Acknowledgement of Receipt; (Figure 1; Workflow Scenario 1). The State EHDI-IS is Content Creator for EHCP and Content Consumer for the Acknowledgement of Receipt; and Pediatrician's EHR-S is Content Consumer for EHCP and a Content Creator for the Acknowledgement of Receipt (Figure 1; Workflow Scenario 2). The following two categories of interoperability standards are used in CDA-based data exchanges: I. Data Content Standards and II. Data Exchange (Transport) Standards. For content standards, HL7 CDA Implementation Guides and IHE Content Profiles are used which define data content for the electronic exchanges. For example, for the EHDI Reporting/Data Exchange Use Case (NHS Outcome Report and EHCP), we selected HL7 CCD standard and IHE EHCP Content Profile standard based on the HL7 CDA R2 standard. For data exchange standards to support Technical Actors' functions of transmitting (sending/receiving) the content (see arrows between actors on Figures 1 and 5), three models for data transmissions /document exchange or sharing are available for CDA-based data exchanges. Each model is based on the implementation of specific transport standard as follows: 1. Cross Document Sharing Model - XDS Model The IHE Cross-Enterprise Document Sharing (XDS) 26 interoperability standard allows the exchange of CDA documents published by senders (Content Creators) in a common document repository (XDS Document Registry). This Registry is shared by organizations that belong to an HIE and have agreed to share data using a common set of policies and data agreements. In the XDS model, the sender publishes the CDA document (form) into the XDS Document Registry 25 IHE Patient Care Coordination Technical Framework Supplement. Early Hearing Detection and Intervention Workflow Definition (EHDI- WD). Integrating the Healthcare Enterprise Web site. Acessed June 3, IHE Cross-Enterprise Document Sharing (XDS). Integrating the Healthcare Enterprise Web site. Accessed August 19, 2012.

27 27 using the IHE Document Metadata Subscription (D-SUB) 27 standard. The Receiver (Content Consumer) receives a Notification of Document Availability using the IHE Notification of Availability (NAV) 28 standard. The Receiver (Content Consumer) retrieves the document using the IHE DSUB 27 standard. 2. Direct Push Model - Direct Model This model is based on Direct (known as ONC Direct Project) which is a standard transport specification that allows participants to send authenticated, encrypted health information directly to a known and trusted recipient over the Internet via secure Direct uses secure to send documents (reports, forms) as attachments. It is a service that can be provided by an HIE, or directly used between trusted senders and receivers. This approach is based on the IHE Cross-Enterprise Document Reliable Interchange (XDR) 30 or Cross-Enterprise Document Media Interchange (XDM) 31 standards. 3. Retrieve Form for Data Capture (RFD) Infrastructure Model - RFD Model The IHE Retrieve Form for Data Capture (RFD) 32 standard enables a service from an HIE (or public health agency) to allow senders to populate pre-defined CDA-based forms when senders cannot or do not want to generate such forms from their systems. Sender (e.g., Birthing Facility EHR-S) can retrieve a form from the Form Manager (e.g., HIE) and populate it with data from its system serving in the role of a Form Filler. This electronic form originally defined by users' data requirements allows users (clinicians) to enter additional data required by receiver that has not yet been pre-populated from the EHR-S. The form data that includes pre-populated and manually added data are then placed by the Form Manager into the CDA-based document structure. The Form Manager then transmits the form to the Form Receiver (e.g., State EHDI- IS). EHDI Reporting/Data Exchange Architecture and Selected Standards The following interoperability standards and architecture options can support EHDI data reporting and exchanges. For the content standards for the EHDI Reporting/Data Exchange Use Case (NHS Outcome Report and EHCP), we used HL7 CCD standard and the IHE EHCP Content Profile based on the HL7 CDA R2 standard as described above. For data exchange standards to support EHDI Technical Actors' functions of transmitting (sending/receiving) the CDA-based content we selected Model 2 (Direct Model) and Model 3 (RFD Model) as described below by EHDI data reporting/exchange scenario. 27 IHE Document Metadata Subscription (DSUB). Integrating the Healthcare Enterprise Web site. Accessed July 18, IHE Notification of Availability (NAV). Integrating the Healthcare Enterprise Web site. Accessed July 18, ONC Direct Project Web site. Accessed July 18, IHE Cross-Enterprise Document Reliable Interchange (XDR). Integrating the Healthcare Enterprise Web site. Accessed August 19, Cross-Enterprise Document Media Interchange (XDM). Integrating the Healthcare Enterprise Web site. Accessed August 19, IHE Retrieve Form for Data Capture (RFD). Accessed August 2012

28 28 Scenario 1: Report NHS Outcome Report from Birthing Facility's EHR to State EHDI-IS Option 1: EHR-S (Content Creator/Sender) generates CDA NHS Outcome Report specified by the IHE EHCP Content Profile standard and sends the Report to EHDI-IS (Content Consumer, Receiver) directly, or through an HIE interface using a secure exchange protocol (secure , ONC Direct, or IHE XDR). Option 2: EHR-S (Content Creator/Sender) pre-populates electronic NHS Outcome Report form provided by the Form Manager (HIE or Public Health service) that in turn sends it to the EHDI-IS (Content Consumer/ Receiver). The Form Manager allows for additional data entry as needed. The IHE Retrieve Form for Data Capture (RFD) Integration Profile 33 interoperability standard is used to support the Form Manager/Filler/Receiver capabilities of the participating systems. The Form Manager sends the CDA-based NHS Outcome Report (1) to the EHDI-IS directly or (2) via HIE using secure exchange (ONC Direct or IHE XDR) or (3) using the Form Receiver capabilities from the IHE RFD standard. Scenario 2: Generate and Transmit EHCP from State EHDI-IS to Pediatrician's EHR-S Option 3. Once the EHDI-IS has received the NHS Outcome Report through Option 1 or Option 2 above, it generates a CDA-based EHCP specified by the IHE EHCP Content Profile standard. The EHDI-IS (Content Creator/Sender) sends the EHCP to the Pediatrician's EHR-S using a secure exchange protocol (ONC Direct or IHE XDR). Resources on Vendors' Capabilities to Support EHDI CDA Pilot Projects PHDSC strives to remain a neutral entity, bringing diverse interests together to promote the development and testing of interoperable standards for HIT products used in clinical-public health information exchanges. Information about vendor system capabilities to support particular IHE interoperability standards (data content standards and/or data exchange/transport standards) can be found in the IHE Connectathon database 34 of Testing Integration Statements for vendors that successfully tested a particular standard. As an example, Appendix C provides the list of vendors that successfully tested the IHE RFD Integration Profile. 33 IHE Retrieve Form for Data Capture (RFD) Integration Profile. Integrating the Healthcare Enterprise Web site. Accessed August 19, IHE Connectathon Results. Integrating the Healthcare Enterprise Web site. Accessed February 2013.

29 29 Section 5 CDA Pilot Project Implementation Sections that follow describe CDA EHDI pilot project implementations by participating sites. North Dakota (ND) EHDI CDA Pilot Project EHDI Reporting in North Dakota According to the ND EHDI guidelines 35, all birthing facilities in North Dakota offer newborn hearing screening prior to discharge and report NHS outcome data to ND EHDI program by entering data into the ND EHDI-IS web-portal or use an online/fax-back form (Appendix B). Project Statement Enable electronic transmission of Early Hearing Care Plan for a newborn from State EHDI program to pediatrician by deploying standards-based HIT solutions. Actors Actors participating in the pilot project and HIT products deployed are listed in Table 4. Table 4 North Dakota EHDI CDA Pilot Project Participants Actor Type Business Actors Technical Actors (Stakeholders) Product Vendor Role Sanford Health (Birthing Facility) Epic 2010 Epic EHR-S (NA) Sanford Health (Pediatrician) Epic 2010 Epic EHR-S (Content Consumer, Document Recipient) Trinity Health (Pediatrician) Cerner EHR Millennium 2007 Cerner EHR-S (Content Consumer, Document Recipient)) ND EHDI Program OZ escreener Plus (esp ) OZ Systems EHDI-IS (Content Creator, Document Source) Use Case The ND EHDI CDA pilot project was focused on implementation of Scenario 2: Generate and Transmit EHCP from EHDI-IS to Pediatrician's EHR-S (Figure 1, Scenario 2; and Use Case Steps 11-14). It included: a. generating the CDA-based Early Hearing Care Plan, EHCP, by the State EHDI-IS using 35 North Dakota Early Hearing Detection and Intervention Program Web site. Accessed February 12, 2013.

30 30 newborn demographic data received from the birthing facility s EHR-S, and hearing screening results transmitted from a device b. transmitting the EHCP from the State EHDI-IS to the Pediatrician s EHR-S and c. receiving EHCP by Pediatrician s EHR-S. Figure 6 presents the ND EHDI CDA pilot project use case and data flow. ASCII Demographics NHS data CDA-based EHCP 1. Birthing facility EHR-S sends demographic information on a newborn. Hearing screening results are electronically transmitted from a device. 2. ND EHDI-IS generates EHCP and sends it to Pediatrician EHR-S and to Birthing Facility EHR-S 3. Pediatrician EHR-S receives EHCP from ND EHDI-IS Figure 6 North Dakota EHDI CDA Pilot Project: Use Case and Data Flow Data Requirements With input from the ND EHDI program staff, the PHDSC project team built the CDA-based Early Hearing Care Plan document instance using test patient data for demographic information on patient, provider and EHDI program staff. The ND EHCP instance was built based on the IHE EHCP model. Figure 7 presents a human-readable view of the demographic portion of the ND CDA EHCP. The complete lists of data for the IHE EHCP, as well as the North Dakota-specific data requirements for the ND CDA EHCP are available in the North Dakota Data Mapping and Definitions document at the project wiki pages. 36 Please note that this document also contains the data mapping table between North Dakota hearing screening reporting data requirements and birthing facility's and pediatrician's EHR-Ss data. 36 Public Health Data Standards Consortium (PHDSC). Early Hearing Detection and Intervention (EHDI) Clinical Document Architecture (CDA) Pilot Project. North Dakota Data Mapping and Definitions. May Index xlsx. Accessed May 12, 2013.

31 31 Figure 7 North Dakota Early Hearing Care Plan Document Interoperability Standards and Data Exchange Architecture Figure 8 presents settings; systems and their role in the electronic data communication; and interoperability standards for the ND EHDI CDA Pilot project. We use terms from the IHE interoperability standards documentation (Content Creator/Content Consumer for IHE EHCP standard; and Document Source/Document Recipient for IHE XDR standard) for the roles that systems played in the pilot project to send and receive the EHCP. The ND EHDI-IS played the role of Content Creator to generate the CDA-based EHCP (IHE EHCP standard) (Step 2) from newborn demographic and hearing screening results data that were received as ASCII files from the birthing facility EHR-S (Step 1). ND EHDI-IS (Document Source) than transmitted the EHCP to the Pediatrician EHR-S, (Content Consumer and Document Recipient) (Step 3) via secure (IHE XDR standard).

32 32 Step-1 Setting: Birthing Facility IT Product: EPIC Report Content: Demographics, NHS data Standard: ASCII Actor: NA Step-2 Setting: ND EHDI program IT Product: OZ esp Report Content: EHCP Standard: HL7 CDA, IHE EHCP, IHE XDR Actor: Content Creator Document Source Step-3 Setting: Pediatrician IT Product: Epic 2010, Cerner Report Content: EHCP Standard: HL7 CDA, IHE EHCP, IHE XDR Actor: Content Consumer Document Recipient Figure 8 North Dakota EHDI CDA Pilot Project: Settings, Systems, Standards, and Actor Roles Figure 9 provides a detailed technical view of pilot project architecture. Birthing Facility EHR-S Sanford Health (Epic) Hearing Device ASCII Files Newborn Demographics Hearing Screening Results State Public Health North Dakota EHDI -IS Public Health Communica on Server (OZ) esp (OZ) CDA-based EHCP IHE EHCP Standard IHE XDR Standard Pediatrician EHR-S Trinity Health (Cerner) Test Harness (Epic) Content Creator EHCP CDA Document Content Consumer Document Source XDR Transaction Document Recipient Figure 9 North Dakota EHDI CDA Pilot Project Architecture Please note that to generate the EHCP, the newborn demographic data from the Birthing Facility EHR-S and the hearing screening results from the hearing test device were transferred to the ND EHDI-S through ASCII files. We anticipate that in future, the demographic data will be transferred

33 33 using IHE Newborn Admission Notification Information (NANI) standard 37. NANI uses HL7 version 2 (v2) messages to communicate basic patient admission data on a newborn to a State EHDI program. In addition, data from the hearing device will be transferred using the IHE Patient Care Device (PCD) 01 transaction 38, which uses HL7 v2 message syntax and coding requirements to transmit device data between systems. Development Efforts New development was needed to send and receive an Early Hearing Care Plan in North Dakota. In this pilot project, we used existing connectivity between OZ Systems (ND EHDI-IS vendor) and Sanford Health birthing facility EHR-S (Epic). IHE EHCP standard was successfully tested by OZ Systems at IHE Connectathon in 2012 to generate the EHCP and demonstrated at the HIMSS Interoperability Showcase 2012 and New development was needed for sending/receiving EHCP to pediatrician EHR-S using IHE XDR standard. With support from the PHDSC Technical Assistance Team, the North Dakota team successfully completed the pilot project. Table 5 summarizes the development efforts in the pilot project by system. Table 5 North Dakota CDA Pilot Project: Standards and Development Efforts Vendor/IT IHE Connectathon Tested / New Standard Actor (Role) Products Development Epic ASCII export of patient demographics Content Creator Existing connectivity between Sanford Health birthing facility and ND EHDI-IS Natus, ABaer Transmission of hearing screening results data Content Creator Existing connectivity with ND EHDI-IS OZ Systems, Content Creator IHE Connectathon Tested IHE EHCP esp OZ Systems, esp IHE XDR Content Creator, Document Source New Development Epic Content New Development IHE EHCP Consumer, IHE XDR Document Recipient Cerner Content New Development IHE EHCP Consumer, IHE XDR Document Recipient The PHDSC project management team created a Work Plan for each site describing specific tasks and project deliverables. Table 6 presents the Work Plan for the North Dakota project. 37 Integrating the Healthcare Enterprise (IHE). Quality, Research and Public Health Technical Framework Supplement. Newborn Admission Notification Information (NANI) Content Profile. URL: 38 Integrating the Healthcare Enterprise (IHE). Patient Care Device Technical Framework Supplement, Volume 2, Section 3 PCD-O1 Transaction. URL

34 34 Table 6 North Dakota EHDI CDA Pilot Project: Work Plan Task # Activity Duration 1. Project Management 1.1 Participate in informational/educational calls Oct.-Nov Participate in the technical readiness assessment November Recruit facilities and their vendors Dec Jan Review and provide feedback and updates for project documents Dec May Participate in project calls February-May Participate in the follow-up survey June Review project report July Functional and Data Requirements 2.1 Gather user requirements for the pilot project January Develop use case February-March Conduct data mapping between Sanford Birthing Facility s EHR-S and the ND EHCP 3. Pilot Project Design / Implementation March Design data communication architecture February-March Develop import ASCII Flat File with newborn demographic data from Sanford Birthing Facility EHR-S into ND EHDI-IS Develop import ASCII Flat File with NHS readings from the hearing device into ND EHDI-IS Parse ASCII Flat File with newborn demographics and NHS data in the ND EHDI-IS to develop ND CDA EHCP document Create & validate ND CDA EHCP document in ND EHDI-IS (Content Creator) Build IHE XDR transaction from ND EHDI-IS (Document Source) to Pediatrician EHR-S (Document Recipient) Transmit ND CDA EHCP document to Pediatrician EHR-S (Document Recipient) via IHE XDR with sample data. Pediatrician EHR-S (Content Consumer)displays the ND CDA EHCP. 4. Testing Test implementation of generating EHCP(live test with Birth Facility EHR-S and EHDI-IS), a. send ASCII Files with demographics and NHS data March 2013 March 2013 March 2013 March 2013 March 2013 March 2013 April 2013

35 35 Task # Activity Duration receive these files by ND EHDI-IS b. generate ND CDA EHCP by ND EHDI IS (Content Creator) Test implementation of sending ND CDA EHCP (live test with ND EHDI-IS and Pediatrician EHR) a. send EHCP from EHDI-IS (Document Source), to Pediatrician EHR-S b. receive EHCP by Pediatrician EHR-S (Content Consumer, Document Recipient) c. display EHCP by Pediatrician EHR-S Provide screenshots for the test report as a proof of successful testing conducted in 4,1 and 4.2 April 2013 April 2013 Testing The EHDI CDA Pilot Project used CDA validations tools from the National Institute of Standardization (NIST). The NIST CDA validation tools 39 were used to verify conformance to the HL7 CDA R2 standard, and to validate the corresponding CDA-based documents implementations for both pilot projects. The PHDSC project team also provided a Test Plan for each Participant to verify conformance with standard specifications used in the pilot project and confirm functionality supports EHDI data exchange between providers and public health programs within the scope of the selected use case. Table 7 presents the Test Plan for the North Dakota EHDI CDA Pilot Project. The PHDSC testing team conducted the tests. Documentation for the ND Test Report for the CDA EHDI Pilot Project, including screenshots, logs, and CDA Case Report XML files in both raw and rendered formats is available from the PHDSC project wiki pages at Table 7 North Dakota EHDI CDA Pilot Project: Test Plan Supporting Test Documentation Date Test Steps 1. Using mapping criteria identified by the ND EHDI team in sample data, test NHS source data availability in birthing facility EHR-S and provide screenshots (human readable and native file format) 2. Compare selected vocabulary values in EHR-S to verify they are those required by ND EHDI program Screenshots 4/4/13 Screenshots Tester Comments Test patient data are available in birthing facility EHR-S 4/4/13 Data are the same as required by ND EHDI program 39 National Institute of Standards and Technology (NIST). CDA Validation Tools. NIST Web site. Accessed March 31, 2013.

36 36 Test Steps 3. Verify that demographic data are sent by birthing facility EHR-S, and hearing screening results data are sent from hearing screening device to EHDI-IS 4. Verify that test data are received by EHDI-IS 5. Verify the CDA EHCP document can be generated from test data 6. Verify that human readable and machine readable content required for the EHCP is present 7. Verify that the generated EHCP document passed NIST CDA R2 Validation Tool for errors. (Any errors generated by the NIST Tool reflect an unsuccessful test for this step. Any warnings identified by the NIST Tool (e.g. where there is a constraint of SHOULD not met by the tested document) must be noted.) 8. Verify using IHE validation tool that EHCP document generated in conformance to the IHE EHCP standards. IHE EHCP validator URL: (Any errors generated by the IHE validation Tool reflect an unsuccessful test for this step. Any warnings identified by the IHE validation Tool (e.g. where there is a constraint of SHOULD not met by the tested document) must be noted.) 9. Verify the transmission of the EHCP document from EHDI-IS to Pediatrician EHR-S (Review a screen capture log file from the sender and/or receiver providing evidence that the transaction was successfully sent to the recipient. Verify that the transaction is successful through witness of the interactive transaction and through review of the log file evidence.) 10. Verify the EHCP document receipt by the Pediatrician EHR-S (Review log file evidence that the EHCP Supporting Documentation Logs, screenshots Logs Screenshot Screenshot EHCP XML Rendered EHCP EHCP XML Screenshots NIST validation messages EHCP XML Screenshots IHE validation messages Logs Screenshots of log files Logs, Screenshots of log files Test Date Tester Comments 4/4/13 Test patient data are available in EHDI-IS 4/4/13 Test patient data are available in EHDI-IS 4/4/13 EHCP is generated from test data 4/4/13 Required content is present 4/4/13 No errors from validation 4/4/13 No errors from validation 5/23/13 Secure sent by EHDI-IS with EHCP XML file and stylesheet for rendering XML in human-readable form 5/23/13 Secure sent by EHDI-IS with EHCP XML file and stylesheet

37 37 Test Steps document content is successfully received by the Pediatrician EHR-S. Verify that the transaction is successful through witness of the interactive transaction and through review of the log file evidence.) Supporting Documentation Test Date Tester Comments is received by Pediatrician s EHR-S for rendering XML in human-readable form

38 38 Oregon EHDI CDA Pilot Project EHDI Reporting in Oregon According to the Oregon EHDI guidelines, 40 all birthing facilities in Oregon offer newborn hearing screening prior to discharge and report NHS outcome data to OR EHDI program within one month of the birth of the newborn. Only birth facilities with 200+ births per year are required to perform newborn hearing screening and report results to the EHDI program. Reporting is mandated within 10 days of the screening. Currently, data are nearly entirely collected through the Oregon Vital Events Registry System (OVERS) hearing screening module. Project Statement Enable electronic transmission of Newborn Hearing Screening Outcome Report for a newborn from birthing facility to State EHDI program by deploying standards-based HIT solutions. Actors Actors participating in the pilot project and HIT products deployed are listed in Table 8. Business Actors (Stakeholders) Birthing Facility Health Information Exchange Table 8 Oregon EHDI CDA Pilot Project Participants Actor Type Technical Actors Product Vendor Role Epic 2012 Epic (Test Harness) EHR-S (Content Creator) Epic 2012 Epic (Test Harness) Form Filler OZ Forms OZ Systems HIE Infrastructure (Form Manager) OZ Forms OZ Systems HIE Infrastructure (Form Receiver) OZ Forms OZ Systems HIE Infrastructure (Content Creator) OZ Forms OZ Systems HIE Infrastructure (Document Source) OZ Forms OZ Systems HIE Infrastructure (Form Repository) Oregon EHDI Program Staff Rhapsody Orion Public Health Communication Router (Document Recipient) Filemaker Database Homegrown EHDI-IS (Content Consumer) 40 Early Hearing Detection and Intervention (EHDI) Newborn Hearing Screening Protocol. Oregon Department of Human Services Web site. Accessed July 18, 2013.

39 39 Use Case The OR EHDI CDA Pilot Project was focused on the implementation of the EHDI reporting Scenario 1: Birthing Facility's EHR-S sends and EHDI-IS receives NHS Outcome Report directly or via HIE infrastructure (Use Case Steps 7-10). It included: a. populating the NHS Outcome form with data reported in CCD from birthing facility EHR-S (Epic) utilizing Form Manager services provided by HIE (OZ) b. entering additional data on the NHS Outcome form via EHR-S by hospital staff acting as the Form Filler as needed c. submitting the completed NHS Outcome form to the HIE Form Receiver d. mapping the NHS Outcome form into a CDA-based NHS Outcome Report structure from the pre-populated and entered data by the HIE Form Manager e. generating the NHS Outcome Report by the HIE Form Manager and storing the Report in the HIE Form Repository f. submitting the NHS Outcome Report from the Form Repository to the State EHDI-IS g. State EHDI-IS receives the NHS Outcome Report Figure 10 presents the OR EHDI CDA pilot project use case and data flow.. Figure 10 Oregon EHDI CDA Pilot Project: Use Case and Data Flow Data Requirements Figure 11 presents Oregon s EHDI NHS Report web-based form used for collection of NHS data. With input from the OR EHDI program staff, the PHDSC project team built the CDA-based NHS Outcome Report document instance using test data for demographic information on patient, provider and EHDI program staff. Oregon s CDA-based NHS Outcome Report instance was built from the NHS section of the IHE EHCP model. The complete list of data requirements for the CDA NHS Outcome Report Model, as well as the Oregon instance of the CDA NHS Outcome Report, is available from the Data Element Index on the PHDSC project wiki pages

40 40 ( Pilot#Data_Mapping_of_Pilot_Sites_with_NHS_Data_Model). Figure 11 Oregon EHDI Information System NHS Web Screen

41 41 Figure 12 presents a human-readable view of the Oregon CDA NHS Outcome Report for a test patient. In addition to the newborn demographic information, the report also includes sections for reporting the procedures and interventions, and hearing screening coded results. Figure 12 Oregon CDA Newborn Hearing Screening Outcome Report

42 42 Interoperability Standards and Data Exchange Architecture Figure 13 presents settings; systems and their role in the data communication; and interoperability standards for the OR EHDI CDA pilot project. We use terms from the Integrating IHE interoperability standards documentation (Content Creator/Content Consumer for IHE EHCP standard; Form Filler, Form Manager and Form Receiver for IHE RFD standard; and Document Source/Document Recipient for IHE XDR standard) for the roles that systems played in the pilot project to generate, send and receive the NHS Outcome Report. Step-1 Setting: Birthing Facility IT Product: Epic 2012 EHR (Test Harness) Report Content: Patient demographic information, NHS results Standards: HL7 CCD, IHE RFD Actor: Content Creator Form Filler Step-2 Setting: HIE IT Product: OZ Form Manager Report Content: NHS Outcome Report Standards: HL7 CDA, IHE EHCP, IHE RFD, IHE XDR Actor: Form Manager Form Receiver Content Creator Document Source Step-3 Setting: Oregon EHDI IT Product: Orion Rhapsody, Filemaker DB Report Content: NHS Outcome Report Standards: HL7 CDA, IHE EHCP, IHE XDR Actor: Content Consumer Document Recipient Figure 13 Oregon EHDI CDA Pilot Project: Settings, Systems, Standards and Actor Roles The birthing facility EHR-S played the role of Content Creator and Form Filler providing EHR data in the HL7 CCD standard to pre-populate the NHS Outcome form provided by the HIE Form Manager with newborn demographic and hearing screening results data. (Steps 1-2). In addition, as a Form Filler, the EHR-S allowed additional data to be entered manually into the NHS Outcome Form via the interface between the EHR-S and HIE based on Oregon's EHDI data requirements (Steps 1-2). The Form Manager capabilities to provided the NHS Outcome Form for data population/entry to the EHR-S (Form Filler) can be delivered by the HIE or public health entity. In this pilot project, we worked under the assumption that an HIE would provide these capabilities. However, we did not work with any specific HIE in Oregon (Step 2). In addition to the Form Manager role, the HIE also served the roles of a Form Receiver, a Content Creator, and a Document Source. When manual data entry on the Form was completed via the EHR-S, the Form Manager used its content to generate the CDA NHS Outcome Report, i.e., serving as a Content Creator. Once created, the NHS Outcome Report was stored in the HIE Form Repository (Step 2). The resulting CDA NHS Outcome Report document can be securely transmitted from HIE through the Oregon Public Health Communication Router to Oregon EHDI-IS using the IHE XDR standard. However in this project, we used secure FTP (sftp) for the Report transmission. In this transaction,

43 43 the HIE served as the Document Source.(Step 2). Oregon Public Health Communication Router (Document Recipient) received the CDA NHS Outcome Report document and then parsed the report and added the content to the EHDI-IS database.(content Consumer) (Step 3). Figure 14 provides a detailed technical view of the pilot project architecture. Figure 14 Oregon EHDI CDA Pilot Project Architecture Development Efforts Participating EHR-S and HIE vendors had previously participated in industry-based standards testing and/or demonstrations, such as IHE Connecthathon and/or HIMSS Interoperability Showcases 2012 and 2013 for the IHE RFD and XDR standards. the new developementoz Systems Implementation of the CDA NHS Outcome Report document was a new development for this pilot project. Table 5 summarizes the development efforts in the pilot project by system.

44 44 Table 9 Oregon EHDI CDA Pilot Project: Standards and Development Efforts IHE Connectathon Tested / New Vendor Standard Actor (Role) Development Epic, Test CCD Content Creator IHE Connectathon Tested Harness RFD Form Filler IHE Connectathon Tested OZ Systems RFD Forms Manager IHE Connectathon Tested OZ Systems RFD Form Receiver IHE Connectathon Tested OZ Systems NHS Outcome Report Content Creator New Development OZ Systems XDR* Document Source Connectathon Tested XDR* Document Recipient Connectathon Tested Orion NHS Outcome Content Consumer New Development Report Homegrown NHS Outcome Content Consumer New Development (Filemaker DB) Report *Due to time and budget constraints, sftp was used in lieu of XDR to exchange the CDA NHS Outcome Report Table 10 presents the Work Plan for the Oregon EHDI CDA Pilot Project that described specific tasks and timeline by participating entities. Table 10 Oregon EHDI CDA Pilot Project: Work Plan Task # Activity Duration 1. Project Management 1.1 Participate in informational/educational calls Oct.-Nov Participate in the technical readiness assessment November Recruit facilities and their vendors Dec Jan Review and provide feedback and updates for project documents Dec May Participate in project calls February-May Participate in the follow-up survey June Review project report July Functional and Data Requirements 2.1 Gather user requirements for the pilot project January Develop use case February-March Conduct data mapping between OHSU Birthing Facility s EHR-S and the OR NHS Outcome Report Review CDA NHS Outcome Report Model built from the IHE EHCP standard March 2013 March 2013

45 45 Task # Activity Duration 2.5 Conduct gap analysis of OR NHS data content versus NHS CDA Model for the development of the OR instance of NHS Outcome Report in MDHT 3. Pilot Project Design / Implementation March Design data communication architecture February-March Develop communication between birthing facility EHR-S and HIE Form Manager (Form Filler - Form Manager) Provide sample CCD from the birthing facility EHR-S for prepopulation of the NHS Outcome Report Form (demographics) Conduct data mapping between EHR-S CCD and NHS Outcome Report Form for the Form Manager Built and validate the NHS Outcome Report Form in the Form Manager Create CDA NHS Outcome Report after Form Filler (birthing facility EHR-S) has populated the Form Upgrade Orion Rhapsody version to v5.4 and verify that licenses are in place for one additional communication point Configure document sharing model based on the IHE XDR standard between Document Source (HIE) and Document Recipient (EHDI-IS) via Public Health Communication Router. Receive, parse and upload the CDA NHS Outcome Report document into EHDI-IS database (Document Recipient, Content Consumer) 4. Testing Test the CDA NHS Outcome Report Form using NIST Validation Tools and MDHT Validation Tools Test full implementation: live test with Form Filler (birthing facility EHR-S); Form Manager/Receiver, Content Creator, Document Source (HIE); and Document Recipient (Public Health Communication Router), Content Consumer (EHDI- IS) Provide screenshots for the test report as a proof of successful testing conducted in 4,1 and 4.2 February 2013 March 2013 April 2013 April 2013 April 2013 April 2013 April 2013 April 2013 March 2013 May-June 2013 May-June 2013

46 46 Testing For the OR EHDI CDA Pilot Project we used the NIST CDA validation tools 41 to verify conformance to the HL7 CDA R2 standard and CDA NHS Outcome Report implementation. Table 11 presents the test plan for the project that includes steps to verify that the implementation for the OR EHDI CDA Pilot Project conforms to standards' specifications and supports functionality for NHS reporting between birthing facility EHR-S and EHDI-IS within the scope of the selected use case. The Test Report for the OR EHDI CDA Pilot Project including screenshots, log files, and CDA Case Report XML files in both raw and rendered formats is available at the PHDSC project wiki pages at Table 11 Oregon EHDI CDA Pilot Project: Test Plan Test Steps Supporting Test Documentation Date Tester Comments 1. EHR-S provides data on newborn demographics hearing 5/28/13 results 1.1. Verify that all data required for NHS reporting is available in EHR-S 2. Implement the NHS Outcome Report Form in the Form Manager 2.1. Verify that all jurisdiction-specific data requirements are represented in the Form for data capture 2.2. Review Form layout and content with relationship to the data requirements spreadsheet 2.3. Verifies that all features, e.g., drop-down, specified by the users are constrained to projectidentified vocabularies where applicable 3. Test the Form with the EHR-S Form Filler using the HL7 CCD to pre-populate the NHS Outcome Report Form 3.1 Verify that Form Manager provides formid to EHR-s for NHS Outcome Report Form 3.2 Verify that EHR-S Form Filler requests Form from the Form Manager using the formid for the NHS Outcome Report Form 3.3 Verify that the EHR-S Form Filler is able to display the Form and allow data entry into all fields in the Form Screenshot 5/28/13 5/28/13 Screenshot 5/28/13 Screenshot 5/28/13 Test patient data are available in EHR-S Retested 6/6/13 Data are the same as required by OR EHDI program Data are the same as required by OR EHDI program Screenshot 5/28/13 Retested 6/6/13 Communication of end point Screenshot (configuration file, URL showing formid) 5/28/13 Retested 6/6/13 5/28/13 5/28/13 Screenshot 5/28/13 Retested 6/6/13 41 National Institute of Standards and Technology (NIST). CDA Validation Tools. URL:

47 47 Test Steps 3.3 Verify that when an EHR-S Form Filler requests a Form from the Form Manager using a formid that is not known to the Form Manager, that the Form Manager returns an HTTP response code 404 (not found) 3.4 Verify that EHR-S Form Filler submits the Form, and that the Form is sent to the Form Receiver. 3.5 Verify that steps can be repeated using different clinical values for a second test patient. 4. Using the mapping defined in the NHS Data Element index spreadsheet, present to the EHR- S Form Filler the pre-populated NHS Outcome Report Form allowing the user (clinician) to enter additional data not already provided by the EHR-S 4.1. Verify that EHR-S Form Filler provides a CCD when retrieving the form (transaction from RFD profile is "Retrieve form"). Supporting Documentation Test Date Screenshot 5/28/13 Log file Screenshot of log 5/28/13 6/6/13 Tester Comments 5/28/13 Retested 6/6/13 Also verify that the CCD contains data for pre-population with defined content by requesting a copy of the EHR-S- generated document sent to the Form Manager Verify using defined prepopulation rules from the Data Element Index spreadsheet, that the Form surfaced in the EHR-S has each field pre-populated by providing EHR-generated CCD EHR pre-populated Form 4.3. Verify that Form is populated using vocabularies defined by the users 4.4. Verify that the Form is populated reflecting any additional NHS content constraints 4.5 Verify that the Form cannot be submitted without all required fields populated XML 5/28/13 Retested 6/6/13 Screenshot, Document XML 5/28/13 Retested 6/6/13 Screenshot 5/28/13 Retested 6/6/13 Screenshot 5/28/13 Retested 6/6/13 Screenshot 5/28/13 Retested 6/6/ Verify that those fields which have Screenshot 5/28/13 Retested 6/6/13

48 48 Test Steps to be manually filled on the Form with content constrained by the NHS Outcome Report Model are available for data entry 5. Using the Form Manager, Transform Data from the NHS Outcome Report Form into the CDA-based Document Specified by the PHDSC EHDI Modeling Team at the Project Wiki URL: HDI-Pilot-OR 5.1 Verify that CDA NHS Outcome Report is generated by Form Manager 5.2. Using screenshots captured during the Form filling process, verify that all content from the Form is present in the CDA NHS Outcome Report 5.3 Verify the CDA NHS Outcome Report (generated in step 5.1) using NIST CDA R2 Validation tool for errors. (Any errors generated by the NIST Tool reflect an unsuccessful test for this step. Any warnings identified by the NIST Tool must be noted.) 5.4 Verifies using MDHT that the CDA NHS Outcome Report (generated in step 5.1) is in conformance to the CDA NHS Outcome Report Model. (Any errors generated by the MDHT Tool reflect an unsuccessful test for this step. Any warnings identified by the MDHT Tool (e.g., where there is a constraint of SHOULD not met by the tested document) must be noted.) 6. Send the CDA NHS Outcome Report to the State Public Health Using secure sftp protocol 6.1 Verify that the CDA NHS Outcome Report was successfully sent from Document Source (Form Receiver) to Document Recipient (Public Health Communication Router) using Transport Layer Security (TLS) Supporting Documentation Screenshots NHS Outcome Report XML and stylesheet Screenshots, xml document NHS Outcome Report XML NHS xml Log file, Screenshot of log file Test Date Tester Comments 5/28/13 Retested 6/6/13 5/28/13 5/28/13 5/28/13 5/28/13 5/28/13 5/28/13 Retested 6/6/13 CDA NHS Outcome Report is generated from test data Retested 6/6/13 Retested 6/6/13 No errors from validation Retested 6/6/13 No errors from validation Retested 6/6/13 Secure FTP sent by Document Source with CDA NHS Outcome Report XML file

49 49 Test Steps including a screen capture log file from the sender and receiver providing evidence that the transaction was successfully sent to the recipient. Supporting Documentation Test Date Tester Comments Also verify that the transaction is successful through witness of the interactive transaction and through review of the log file evidence. 7. Import the CDA Newborn Hearing Screening Report document into the EHDI-IS 7.1 Verify the transaction of importing the CDA NHS Outcome Report into EHDI-IS by providing screenshot or log evidence that the NHS content was successfully received by the EHDI-IS. Also verify that the transaction is successful through witness of the interactive transaction and through review of the log file evidence. Log file of transaction, Screenshots of imported data in system 5/28/13 5/28/13 Retested 6/6/13 Secure FTP sent by Document Source with NHS XML file is received by EHDI-IS

50 50 Section 6 Lessons Learned The EHDI CDA pilot projects in North Dakota and Oregon were the second endeavor to implement CDA-based standards for public health reporting and data exchanges between clinical and public health information systems following the communicable disease reporting pilot projects conducted by PHDSC in in Delaware, New York State and San-Diego County. As in the first pilot projects, we conducted a brief survey of the Participants to describe their opinions about successes and challenges of the project. We also asked them to document the level of effort spent or desired for successful project completion. Level of Effort Table 12 presents the level of effort by role on the project. Table 12 EHDI CDA Pilot Project: Level of Effort by Site and Project Team Role Title Role Description Hours Spent on the Project Desired Hours Needed for the Project North Dakota Team Public Health and Clinicians Data Manager Provided data management expertise Project Director EHR-S IT Interface Analyst EHR-S End User, Nurse Manager Provided leadership and coordination for the project from an EHDI program perspective Provided technical expertise for the healthcare facility Provided viewing confirmation of EHCP 2 5 received by the healthcare facility Sub-Total 163 Technology Team Public Health Provided technical expertise for EHDI- 10 Informatics Specialist IS operation Director of Provided technical support for CDA 20 Interoperability transport from EHDI-IS to EHCP recipient (Pediatrician EHR-S) EHR-S Interface Provided technical expertise for EHCP 40 Specialist to be received by the EHR-S vendor Sub-Total 70 Vendor Tasks Developed and tested CDA-based application 60 Developed the EHCP CDA interface 15 Developed the EHCP Style Sheet 5

51 51 Title Role Description Hours Spent on the Project Testing of Implementation 10 Sub-Total 90 Total 323 Oregon Public Health and Clinician Users Senior Public Health Informaticist Audiologist EHDI-IS Data Manager EHDI Coordinator Clinical Workflow Analyst Senior Public Health Informaticist Public Health Informaticist Public Health Informatics Specialist Electronic Laboratory Reporting Director of Interoperability EHR Interface Specialist Interface Engineer Provided oversight of internal team and 30 work effort for project milestones Provided subject matter expertise for 21 NHS data reporting Provided data management expertise 31 for consuming data from EHR-S into EHDI-IS Provided leadership and coordination 25 for the project from an EHDI program perspective Sub-Total 107 Technical Team Tasks Provided subject matter expertise for defining NHS data in the EHR-S Provided oversight of internal team and work effort for project milestones Created data maps and deployed IHE RFD tools for EHDI-IS data consumption Provided technical expertise for EHDI- IS data consumption Provided technical support for CDA transport from Orion Rhapsody server Desired Hours Needed for the Project Provided technical expertise for 40 connectivity between EHR-S, HIE and EHDI-IS Sub-Total 311 Vendor and Interface Tasks Provided technical guidance to the project team (Note: most of hours spent on MDHT configuration and implementation, which was not core project goal) Configuration Advisor Provided advice and example for OHSU on how to configure RFD within EHR-S 24 16

52 52 Title Role Description Hours Spent on the Project Infrastructure Vendor Developed the Form Manager 14 application Infrastructure Vendor Developed the CDA NHS Outcome 40 Report Infrastructure Vendor Tested implementation 40 Sub-Total 238 Total 656 GRAND TOTAL 979 Desired Hours Needed for the Project Successes, Challenges and Recommendations We continue to observe growing interest from the public health community for learning about CDA standards for public health reporting. An awareness in building interoperable clinical-public health IT solutions using CDA for EHDI data exchanges was demonstrated as five jurisdictions expressed interest to serve as a pilot project sites. With two jurisdictions selected for the project based on their technical readiness, eleven State EHDI programs continued participation throughout the project as Observers. The EHDI CDA pilot projects exposed State EHDI program staff to the interoperable standardsbased IT solutions available for or used by clinical settings and HIEs that need to be adopted by public health information system to enable electronic data exchanges with clinical systems. This project also expand the scope and content of CDA-based public health data exchanges with clinicians that before included only communicable diseases (pertussis and tuberculosis) reporting. We believe that together with the 2012 PHDSC communicable disease pilot projects, these EHDI pilot projects will serve as a national model for deploying interoperability standards in public health. Below are several quotes about the state teams experience about the project: I did not have a huge role in this project, but found all participants that I interacted with to be very friendly and helpful. I am glad I was able to participate. Vendor had a working RFD implementation for Birth Certificates. We had good support from them. Leveraging Vendor's existing CCD was a good idea that seemed to work well. The pilot solution should be usable by all Vendor's customers without much implementation effort. The metadata mapping effort happened early in the project and appeared to be well understood. Vendors seemed to be well prepared and capable. As we are in the very early stages in attempting to deploy standard-based solutions, we documented recommendations from the project Participants (Table 13) for the future, to make those projects sustainable and successfully repeatable models for implementation of interoperability standards in public health.

53 53 Table 13 EHDI CDA Pilot Projects: Recommendations Recommendations for Future Projects Achieving Project Goals Leverage successes and lessons learned to provide clear expectations to drive the next set of projects. Involve stakeholders in the early planning process. Delineate the project outcomes for the following stakeholders: (1) public health program, (2) health department and (3) vendor. Work with public health programs to obtain their vendor commitment earlier in the project to get vendor s input in the project design and implementation. While conducting the technical assessment to determine level of readiness of pilot participants, provide user guide describing the pilot process with a checklist of requirements for participation. Sample technical assessment table is provided in Appendix D. In the readiness assessment, verify that no system upgrades are in progress that will prevent state teams from actively participating in pilot project. During technical assessment and project planning phase, verify that technical solutions (information systems, Gateway products, etc.) used by state program for information exchange are capable of supporting standards being demonstrated. Improve directions and definitions of expectations from the state participants and their vendors. Engage state representatives in the CDA-based data modeling activities from the onset of the project to assure that CDA report model meets the jurisdiction-specific needs During the design phase, solicit input and commitment from vendors for feasibility and scope definition while transitioning from a conceptual framework to the development schema. Pilot project participants must be able to acquire the required licenses to support web services and other technology supporting the information exchange. Provide training resources adequate to inform the average HL7 Interface Developer with foundational knowledge about XML, CDA development and implementation, HL7 Object Identifiers (OIDs), and web services related to the IHE document sharing standards. Pilot project participants should work with the most current standards so that their implementations require no additional changes after the pilot. Determine jurisdictional and organizational use cases and workflows that require custom solutions and clearly communicate and document design elements that may be different based on the use case. For Public Health Programs Discuss functional requirements at onset of the project. Obtain vendors commitment in the early design phase to engage them earlier in the project. Provide state team with training resources on the underlying standards early in the project, e.g. use of CDA documents, IHE interoperability standards, etc. Start working on receiving and/or importing of sample CDA documents into Public Health Information System earlier on in the process to improve system readiness for the CDA document consumption.

54 54 Provide detailed information about benefits versus costs for reporting architecture design to be implemented. Provide support and information to state project teams to aid in the recruitment of participating partners (vendors, healthcare providers, laboratories, etc.). Set clear expectations that this is a pilot project and not production testing Understand any additional financial outlays for purchase and maintenance of additional vendors products, and any workarounds that may be implemented during the project timeline. Configuration of the standards (e.g. IHE standards) may require familiarity with the standards specifications and additional paid technical support from vendor organization. Acquire all necessary state approvals for security and privacy access for information exchange (e.g. sharing data through a registry) once the design of the reporting architecture is in place to allow enough time for any custom solutions to be put in place. Understand IT policy regarding acceptable solutions for traversing the state firewall. Time must be allotted for custom development of software to cross the firewall if that is the preferred solution. Software geared toward electronic data interchange can greatly accelerate the implementation process. However, familiarity with the requirements of the software and appropriate licensing is necessary. The recipient IT department should be ready to assist with the setup and deployment of web services. In particular, policies surrounding security and firewall issues should be flexible to allow for system testing with external partners. A test web server and sandbox environment is necessary to test permissions and data exchanges across the firewall for testing purposes without compromising enterprise security. Project timeline must be matched with team expertise to allow state teams to appropriately add members with necessary skills as needed, and to determine areas needing subject matter expertise. Verify that public health program internal IT department is able to provide support for software for duration of the pilot. Verify that vendor software will have access to appropriate technical support for duration of the pilot. For Vendors Submit a call-for-participation specifically targeted at vendors to recruit and engage them earlier in the process. Engage vendors in the IHE Connectathon testing prior to recruiting them in the project to reduce time in learning the standard and developing the application. Set clear expectations that this is a pilot project and not production testing. Determine vendor requirements to participate in the project, and communicate level of support available from project team. Vendors who have previously demonstrated the relevant standards make the effort more streamlined. Configuration and test time may be lower when working with vendors that have worked together before. For Standard Developers and Implementers

55 55 During the design of the NHS Outcome Report Form, it was determined that the jurisdictional requirement exceeded what can be captured by the standard for recording multiple races. CDA only allows the capture of one race in the header of the document. However, it is possible to include additional races in the Social History Section. Consideration should be given to evaluate adding the Social History Section to the NHS Outcome Report CDA model. Develop a clear standards requirements checklist for all standards used for pilot (e.g. IHE XDR, IHE security requirements such as audit trail and node authentification (ATNA), interactions with a certificate authority, web service server, etc.). At project onset, determine and communicate required baseline IHE workflow for security and document sharing for pilot exchanges. Provide basic standards resources to all pilot project participants; knowledge of XML and HL7 CDA standards is very helpful, however additional information and training is necessary for relevant IHE profiles (e.g. RFD, XDR, IHE security & privacy), and MDHT. Provide a resource of sample standards implementations that pilot participants can use to learn from. Project Management and Support Improve project management activities and streamline communications. Establish a central communicator to communicate site team needs to the PHDSC team during core working hours (9am-3pm). Improve information representation and the content in the project wiki and assist with posting site-specific documentation. Conduct knowledge sharing sessions with site teams to share updates, feedback and lessons learned across state project participants. Compressed timeframes are difficult to accomplish within the confines of state government process and red tape. There may be a need to extend the project timeline. Improve project timeline management to apportion the workload evenly throughout the project. Discuss funding arrangements and contract requirements from the start when Call for Participation is complete and participants have been selected. Determine industry events that may impact project timeline at start of project. Consider impact on timeline of state participants familiarity and use of existing standards to be piloted, and avoid overly ambitious and aggressive timelines.

56 56 Appendix A: CDA Pilot Project: Call for Participation Call for Participation Early Hearing Detection and Intervention (EHDI) Interoperability using Clinical Document Architecture (CDA) Standard: CDA EHDI Pilot Project Reply by September 15, 2012 to Ms. Maiko Minami at The Public Health Data Standards Consortium (PHDSC) in partnership with the Centers for Disease Control and Prevention (CDC) Early Hearing Detection and Intervention (EHDI) Data Committee and with the support from CDC are seeking state health departments interested in participating in the design and implementation of two pilot projects to demonstrate electronic data exchange between clinical Electronic Health Record (EHR) Systems and public health EHDI information systems using the Health Level Seven (HL7) Clinical Document Architecture (CDA) standard. The HL7 CDA standard was specified for EHR Systems in the Meaningful Use of Health Information Technology (HIT) Stage 1 regulation. The HIT Standard Federal Advisory Committee has recommended the use of the HL7 CDA standard as a future direction for electronic data exchanges between clinical and public health information systems for public health reporting. 42 The pilot projects will be focused on reporting of: Newborn hearing screening results from the birthing facility s EHR to the State EHDI Program, or EHDI quality measure from EHR to Public Health. We are looking for pilot project participants from public health agencies and HIT vendor community, both clinical EHR vendors and Public Health HIT vendors. Roles & Responsibilities: You can participate in the CDA EHDI Pilot Project in either of the two roles as follows: Participant: Two (2) State EHDI programs and their EHR and public health IT vendors interested in demonstrating electronic EHDI data reporting from a birthing facility to a State EHDI Program using the CDA standard. The pilot demonstration includes implementation within the public health department to receive EHDI data using the CDA standard by March Health IT Standards Federal Advisory Committee. Recommendations from the Public Health Surveillance Summer Camp. September 28, URL: 811

57 57 Observer: State EHDI programs and their EHR and public health IT vendors interested in contributing to the design and implementation of the pilot project at the participating sites. Time Commitment. Both Participants and Observers will be asked to participate in 1-hour weekly conference calls of the EHDI Interoperability Advisory Team starting October 8, 2012 through December 2013 to design and implement the two pilot projects. Representatives from Participant programs will be asked to attend the IHE Connectathon Conference, January 28, 2013, Chicago, IL and the HIMSS Interoperability Showcase, March 3-7, 2013, New Orleans, LA as docents for the EHDI demonstrations (travel support will be provided). Participants will work with the PHDSC Technical Assistance Group (TAG) during November- December 2012 to implement the pilot project at their sites. Resources. Technical assistance to implement the pilot project will be provided to the Participants by the PHDSC TAG. Funding is available for Participants to support the implementation of the pilot project. Benefits for Participation: Both Participants and Observers will work with national leaders in HIT interoperability to prepare for the use of CDA standards for public health data exchanges with clinical information systems. Specific benefits include: For Participants: o align state-based IT solutions with interoperability standards used by EHR vendors and Health Information Exchanges (HIE) o become a national model for deploying interoperability standards in public health For Observers: o help guiding the development of interoperable IT solutions for public health reporting o prepare for transition to interoperability standards for public health reporting in your jurisdiction All responders will be invited to participate as Observers in the EHDI Interoperability Advisory Team. The selection of Participants for the two pilot projects will be conducted by the EHDI Interoperability Advisory Team among interested responders based on their interest to serve in this role and technical capacities. Please respond by September 15, 2012 by completing the Response Form below. Please send the completed form to Ms. Maiko Minami at maiko@hln.com, PHDSC Project Coordinator. Please send questions regarding this announcement to Ms. Maiko Minami at maiko@hln.com We look forward to your participation in the CDA EHDI Pilot Project.

58 58 Participate in CDA EHDI Pilot Project to Deploy Interoperable HIT Solutions! Early Hearing Detection and Intervention (EHDI) Interoperability using Clinical Document Architecture (CDA) Standard: CDA EHDI Pilot Project Please Reply by September 15, 2012 to Ms. Maiko Minami at Contact Information Organization Name: Address: Contact Name: Contact Phone: Address: Response Form Interested in Participating in the CDA EHDI Pilot Project in the following role (check what applies): Participant Observer Not Sure but interested in joining the EHDI Interoperability Advisory Team Supporting Information: EMR(s) product/version that may be used: Local HIE gateway product/version that may be used (if applicable): Public Health product/version (s) that may be used: Describe other supporting considerations that would distinguish your participation from other responders:

59 59 Appendix B: CDA Pilot Project: State-Specific Newborn Hearing Screening Report Forms Figure 15 North Dakota Hearing Screening Reporting Form

60 Figure 16 Oregon Newborn Hearing Screening Facility Reporting Form 60