Public Health Reporting Initiative September 19, 2012

Agenda TopicTime Allotted Welcome / Agenda Overview – Lindsay Brown4:00 - 4:05 HL7 Thoughts4:05 – 4:15 Consensus Update & Review – Lindsay Brown4:15 – 4:30 Data Harmonization Update – Nikolay Lipskiy4:30 – 4:35 Stage 3 Sprint Update – Seth Foldy4:35 – 4:40 Federal Health Information Model Presentation – Galen Mulrooney4:40 – 5:00 Adjourn5:00

HL7 Working Group Meeting Thoughts and impressions from members who attended?

Consensus Update Consensus Statement: The general consensus of the Public Health Reporting Initiative is that the Use Case and Functional Requirements documents are complete and correct in their representation of a provider-initiated report from an EHR system to a public health agency system (within the constraints of the scope of the Initiative). Votes Received: – 8 yes – 2 no, with comments Votes received from the following organizations: FDA PHDSC Oregon Health Authority FHA Registry Widgets iConnect Consulting CDC – NCHS (x2), NIOSH, OSELS

Consensus Review – NCHS CommentResolutionAcceptance Suggest providing some clarification in the introduction paragraph to the user stories to indicate that these stories represent current process and proposed future flows. Readers may misinterpret the stories as representing current processes. This distinction is noted in Appendix A in the user story names. For example, in the Chronic Disease #1, it indicates 'future flow for NCHS'. Add to introductory section in both documents the following statement "Some of the user stories submitted for this initiative represent current workflow and information flows, but others represent a proposed future state." 9/12/12 - Yes

Consensus Review – iConnect Consulting CommentResolutionAcceptance Use Case document: page 6/ last sentence in first paragraph: delete 'to create' after 'pharmacy, etc.)': (e.g demographic, clinical, laboratory, pharmacy, etc).. and send a report... Sentence would read: “In the context of this UC, the reporting process is facilitated by the healthcare provider’s EHR and assumes that the EHR system contains or is used to create all relevant information (e.g., demographic, clinical, laboratory, pharmacy, etc.) to send a report to a public health agency.” Yes – 9/19/19 page 18/ rd sentence: add 'is' in front of 'determined': When an adverse event occurs and.. determined... Sentence would read: “When an adverse event occurs and is determined to meet appropriate reporting criteria …” Yes – 9/19/19 page 20/32 - bottom of page delete lone table header page Insert page break. Yes – 9/19/19 23/ first paragraph, last sentence: add 'and/' in front of 'or':...requirements and may vary from condition-to-condition.. or jurisdiction- to-jurisdiction. Sentence would read: “The public health reporting criteria are based on specific jurisdictional or public health agency requirements and may vary from condition-to- condition and/or jurisdiction-to-jurisdiction. Yes – 9/19/19

CommentResolutionAcceptance Functional Requirements document: page 22/26 – last sentence before 6.0 remove second period at the end Remove. Yes – 9/19/19 page 24/26 - table first row (reporting criteria) column description - 4th row: add 't' to 'definitions': definitions and add space after the comma Update formatting. Yes – 9/19/19 It is my assumption, that the data elements document referenced in the Functional Requirements document will be voted on separately. Otherwise, I cannot approve the Functional Requirements document until that task has been completed. Add footnote to document that reads “data elements not yet finalized or consensus approved”. Note: footnote will be removed once data elements are consensus approved. Yes – 9/19/19 Consensus Review – iConnect Consulting (continued) Riki Merrick indicated vote is now a “Yes” from iConnect Consulting on 9/19/12

Consensus Review - NIOSH Comment – NIOSHResolutionAcceptance Use Case: To page 5, following the sentence beginning with “Future Use Cases that could be developed include..”, add: “As additional public health stakeholders become engaged in Standards and Interoperability Framework activities, use cases for domains not represented in this effort (e.g., injury) should be developed and incorporated into future public health reporting documents.” Add statement. Yes – 9/19/12 Use Case: To page 15, under “11.1 User Story”, after the sentence beginning with “These user stories have been generalized..”, add: “PHRI acknowledges that not all domains were represented in this recent process, and that future efforts are needed to ensure that public health reporting standards also reflect the requirements of significant missing domains (e.g., injury). Remove “User Stories are representative” sentence in beginning of section. Yes – 9/19/12 Functional Requirements: On page 3, strike the word “representative” from the sentence beginning “The PHRI use case was derived using a representative sample..” In that sentence, the meaning of the word “representative” is unclear and may suggest a process of selection among candidate domains or scenarios. As an alternative, the sentence could be re-written : “The PHRI use case was derived from current public health reporting scenarios submitted by participating public health domains.” Agree – update functional requirements document to be consistent with Use Case. Yes – 9/19/12 NIOSH votes ‘no’ in acknowledgment of the absence of public health reporting of injuries and related acute health conditions from the Use Case. Public health reporting of injuries encompasses unintentional and intentional trauma, acute poisonings, and “medical misadventures” i.e., injuries arising from medical procedures. These outcomes may be either occupational or non-occupational in nature. While injury stakeholders (including occupational health) did not submit user stories describing the reporting of injuries for the PHRI process, public health reporting of injuries is within the scope of the Initiative. Generally, the Use Case document should note this limitation and suggest that future use case development by non-represented domains is appropriate. To communicate to the public health community that this initiative aims to represent the full range of public health reporting, injury should be mentioned specifically as a missing domain.

Review Schedule Task Elements finalized by Data Mapping Group Implementation Guidance reviewed by Stage 3 Sprint Group CDA Implementation Guide Section2.5.1 Implementation Guide Section Develop preliminary ToC(s)N/A8/30/12 Table of Contents “Week 1” Data Elements8/30/129/6/12 – 9/13/12 Section 3 – Section levelSection 3 – HL7 Segments Patient Information 3.12 Patient Contact Information 3.11 Payer Information 3.13 Provider Information 3.15 Social History 3.17 Family History 3.7 Procedure 3.14 “Week 2” Data Elements9/6/129/13/12 – 9/20/12 Section 3 – Section LevelSection 3 – HL7 Segments Encounter Order / Diagnostic Test 3.10 Facility 3.6 Result 3.16 Specimen 3.18 “Week 3” Data Elements9/13/129/20/12 – 9/27/12 Section 3 – Section LevelSection 3 – HL7 Segments Vital Sign Indicators 3.19 Allergy/Adverse Event 3.1 Medication 3.9 Employment Information 3.3 Immunization 3.8 Outstanding Topics & Draft Review9/20/129/27/12 – 10/4/12 All “Parking Lot” Issues Health Problems (Diagnosis + Problem List) 3.2 Proposed new objects: Exposure, Risk Factors, Care Plan, Physical Exam TBD Other section review (e.g., Intro)9/27/12 – 10/4/12 Implementation Guide(s) Final Draft for Common Core 10/4/12 All Report Type Guidance TBD

Updates Data Harmonization – Finalizing remaining data elements and identifying ‘parking lot’ items this week Sprint Team – Reviewing draft implementation guidance for the first sections of the CDA and draft documents

Federal Health Information Model Presenter: Galen Mulrooney The Federal Health Information Model (FHIM) is an effort to create a logical information model, complete with terminology bindings, for use by Federal Health Architecture (FHA) partner agencies in their respective Enterprise Architecture programs. The FHIM models provide a common set of standards-aligned semantics which can be used in conjunction with Model-to-Model transformations to generate implementable artifacts. The Public Health Reporting Initiative is leveraging the FHIM both to define those data elements that are needed for public health reporting (especially those which are common across different reporting domains) and to accelerate implementations by providing usable software components to developers. For more information on the FHIM, and to view the FHIM itself, please see: FHIM fact sheet available on the wiki: doc doc

Other topics / Discussion Other topic for discussion? Questions?