1. Query Health Distributed Population Queries Implementation Group Meeting September 27, 2011

2. Participation Instructions for WebEx Please Note: This session will be recorded Lines are open so please mute your line to avoid “Music on Hold” 1.Select the “Q&A” button in the WebEx toolbar. 2.Select “All Panelists” in the Q&A box. 3.Type your question and hit send. 4.We’ll call on you to state your comment / question.

3. Agenda Summary of Last Meeting & Reminders WG updates Clinical Technical Business Charter – 2 nd Call for consensus Discussion Forums Security / Privacy Tiger Team – Recap Meaningful Use Working Group Open discussion / Next Steps

4. Query Health Scope and Approach Practice drives standards 1.Rough consensus 2.Running code (open source) 3.Pilot 4.Specifications 5.Standards HIT Policy Committee: Policy Guideposts

5. Query Health Where We are

6. Query Health Calendar Implementation Group Tuesdays 1:30pm-3:00pm EDT Technical Work Group Wednesdays 11am-12pm EDT Clinical Work Group Wednesdays 12pm-1pm EDT Business Work Group Thursdays 11am-12pm EDT First Face to Face Meeting October 18-19

7. Query Health Who’s participating (As of 9/27) 95+ Participating Organizations – Public Health Agencies – Health IT Vendors – Health Information Exchanges – Academic Partners – Health Systems – Patient Advocacy Organizations

8. Recap of Last Meeting Reviewed Query Health Scope, Approach, Timeline, and Organization Reviewed the objectives of each working group Clinical – Use Cases, User Stories, Clinical Information Models Technical – Architectural principles, technical standards / specifications, design of pilot implementations Business – best practices for privacy, data use, network partner coordination Discussed Policy Sandbox and presentation to HITPC

9. Action Items DescriptionOwnerStatusDue DateNotes Review changes to the charter and provide comments for consensus by 9/29/2011 Working Group Participants Closed.9/29/2011Please provide updated votes and comments Call for Consensus pageCall for Consensus Register and arrange for travel for the October Face to Face meeting Working Group Participants Open9/29/2011 Choose leaders for each of the Work Groups Working Group Participants Open9/29/2011 To be discussed at each WG meeting week of 9/26

10. Clinical Working Group Update from 9/21 Meeting

11. Presented & Discussed Community User Story proposals –Expanded Analysis User Story (Presented by Kim Nolen & Lindsey Hoggle)Expanded Analysis User Story –Updated Generic Population Measures User Story (Presented by Michael Buck)Generic Population Measures User Story Recap: Proposed User Stories Key Topics Covered/Discussed User Story NameLeads & ContributorsExpected Presentation Date Link Example User Story – Case Control, Statin Efficacy Working Group Participants9/21/2011Example User Story – Case Control, Vaccine Efficacy Example User Story – Case Control, Vaccine Efficacy Working Group Participants9/21/2011Example User Story – Case Control, Statin Efficacy Expanded Analysis User StoryKim Nolen (Lead), Lindsay Hoggle9/21/2011Expanded Analysis User Story Generic Population Measures User Story Michael Buck, Susan Campbell9/14/2011Reportable Disease Reporting User Story Consumer Perspective User Story Eva Powell9/14/2011Consumer Perspective User Story All Hazards User StoryTaha Kass-Hout9/28/2011TBD Hypothesis Generation User Story David McCallie9/28/2011TBD

12. Decisions The Working Group members decided it would be best to have the Generic User Story be included as part of the Use Case supplemented by 1-2 additional User Stories. Work Assignments/Next Steps Develop, refine and provide comments using the wiki discussion tab for the following: –Proposed User Stories Example User Story – Case Control, Vaccine Efficacy Example User Story – Case Control, Statin Efficacy Generic Population Measures User Story Consumer Perspective User Story Expanded Analysis User Story All Hazards User Story Hypothesis Generation User Story Sentinel user story The Working Group will prioritize and select the remaining 1-2 User Stories during the 9/28 meeting based on; –National Priorities –Leveraging existing research and public health network infrastructure Review and comment on draft Functional RequirementsFunctional Requirements Key Decisions & Next Steps

13. Query Health Technical WG Update 9/27/2011

14. Technical WG Update Two major discussion topics Abstract Model discussion - Sean Nolan Scan of Existing standards discussion – Srinivas Velamuri

15. Abstract Model Discussion

16. Query Network Community of participants that agree to interact with each other. There will be many networks; requestors and responders may participate in multiple networks. Authorized Requestors Participating Responders Query

17. Query Lifecycle 1.Requestor optionally uses a composer to create a query and submits it to their dedicated agent. 2.Agent submits the query over the Internet to each participating responder’s gateway and awaits responses. 3.At each participating responder, the standard gateway passes the request to a site-specific adapter. 4.The adapter calculates site results for their site and returns them to the gateway. 5.The gateway returns site results to the appropriate agent. 6.The agent returns site results to the aggregator that combines site results into combined results 7.The aggregator makes interim and final results available to the requestor. Agent Gateway Adapter Composer Aggregator Clinical Data Clinical Data Authorized Requestor 1 2 3 4 5 6 7 Responder “1”Responder “N” …

18. Query Envelope Query Requestor identifier Query identifier (unique within requestor space) Freeform notes for responders Query type and version (List of) Query Items – Item name/tag (unique within request) – Item request payload Response Responder identifier Response identifier (unique within responder space) Requestor identifier Query identifier Freeform notes for requestors (List of) Response Items – Item name/tag – Item status – Item response payload

19. Query Payload Query Health supports multiple “query types” traveling over the same transport and envelope Types are identified by a name and version –E.g., “MU Stage 1 EP/1.0” Each type implies –Query syntax –Clinical information model –Response format

20. Existing Standards Discussion

21. Update from Discussions Standards Examined QRDA QRDA Category I – Single Patient Quality Report QRDA Category II – Multi-Patient Quality Report QRDA Category III – Aggregate or Summary Level Quality Report HQMF or eMeasures – Health Quality Measures represented in Electronic Format To determine if either of these two standards can be used to represent Queries and/or Results Payload

22. Summary of QRDA and HQMF Summary from the WG Discussion: Query Health will have to support different types of queries including dynamic queries and a variety of result formats Given the generic use cases and purposes that Query Health standards and protocols will be used for, the WG thinks that QRDA and HQMF are too constrained as they currently exist.

23. Technical WG – Next Steps Will be working towards WG approval of the Abstract model and bring it to the Implementation Group Sign up for developing and refining the various artifacts at the following links and present at the next WG meeting: Abstract Model Discussion Link - http://wiki.siframework.org/Query+Health+Abstract+Model+and+Terminology http://wiki.siframework.org/Query+Health+Abstract+Model+and+Terminology Patterns Summary Discussion Link - http://wiki.siframework.org/Summer+Concert+Series+Patterns+and+Summar y http://wiki.siframework.org/Summer+Concert+Series+Patterns+and+Summar y Existing Standards Discussion Link - http://wiki.siframework.org/Query+Health+- +Existing+Standards+and+Models+Landscape http://wiki.siframework.org/Query+Health+- +Existing+Standards+and+Models+Landscape

24. QRDA Category I Sample

25. QRDA Category II Sample

26. QRDA Category III Sample

27. HQMF Sample

28. HQMF Sample Cont’d

29. Business Working Group Update from 9/22 Meeting

30. Points of Discussion –Use key secondary uses for domain specific requirements – these have been added to Matrix –Examine privacy and security framework developed for caBIG in work with the University of Michigan –Clarification of plans for pilot(s) and use of Policy Sandbox ONC supported pilots will use the Policy Sandbox Different applications of Query Health tools will conform to the necessary data use agreements and privacy and security regulations as applied to the specific query domain and type Key Topics Covered/Discussed

31. Business Working Group Key Decisions and Next Steps Decisions The WG agreed to focus on developing Business Requirements for the General Use Case using the Business Matrix Work assignments/Next Steps –Enter business requirements for General Query Health Use Case –Schedule time for self-organized calls to develop business requirements next week

32. Project Charter

33. Key assumptions: –Initiative will leverage existing distributed query technology (e.g. those identified from the summer concert series) and NwHIN technology as appropriate –Existing S&I ToC data model as the CIM starting point (with extensions if needed for the selected user story) Key demonstrations –1 or 2 user stories to pilot and test –The broader set of user stories is intended to ensure that the architecture framework is robust and extensible Pilot sites will be selected based on –national priorities –Existing research and health information management infrastructure Scope Clarification & Discussion

34. Project Charter Feedback Endorsement (Yes or No) If No, what can be changed to make it Yes? Yes No  I share the Microsoft and Epic concerns. Clarification of the role of "network partners" should be easy, as I don't think they are a required part of the model.  Deciding on the PHI question may not be so easy. As stated in a comment earlier, I do not think QH should by design exclude the ability to return PHI as part of a query response. Clearly QH must operate within the law, and within the contracts that will exist between query placers and query responders.  Perhaps the charter should specify a range of response restrictions that will be supported, based on the contracted use cases? I believe that i2b2 has this capability, supporting aggregate counts for some users, "limited data sets" for other users, and PHI-containing responses for users who have obtained a waiver from an appropriate IRB. No  Confusing Terminology - "As a result, information requestors will be able to create and securely distribute queries to network data partners who subscribe to the published queries." **Publish/Subscribe** is a well-defined messaging pattern, which doesn't seem to be part of the Query Health intent. Maybe "who support the defined queries" is a better wording.**Publish/Subscribe**  Use of CDR - While EHR systems in this context can be assumed to be defined by HITECH and MU, the same is not true for Clinical Data Repository. Using this term may lead to the understanding that providers need to purchase a specific CDR product in order to be able to provide responses to the queries. Suggest using "Query Health Responder" or "Query Health Data Responder" as the generic term to be used in addition to EHR systems. No  We agree with comments that PHI should be allowed, and to the extent possible, the Project Charter should call for the technical means and policies to assure that PHI is not compromised. Yes No  Agree with both comments from Epic  "network data provider" in the scope section implies an intermediary that may or may not turn out to be relevant... better as a simpler description such as "information requestors will be able to create and securely distribute queries to network data partners who subscribe to the published queries. Network data partners will examine queries and pass them on to data sources. Data sources, such as a provider organizations, will execute the query against a standard clinical information model, and securely return the results of the query to a data network partner, and then subsequently to the requester." Note there are other uses of the "network data provider" term that should also be addressed.  In the Key Assumptions section, we continue to struggle with the limitations being placed on the movement of PHI and the "initial pilot"... we will likely have multiple pilots, and some of them may be between partners that are comfortable sharing PHI. I don't understand why we feel a need to put this into the charter --- I can only see it hurting our ability to deliver the best possible model. Yes with Comments  The wording around whether or not limited PHI such as for public health purposes is to be piloted and permitted is not clear or consistent in the current draft. It needs to be edited for clarity as it looks like we wish to permit it. Yes

35. Open Discussion

36. Identify Working Group leadership Call for consensus on Charter (third time’s the charm!) – Sept 29 Face-to-Face Meeting October 18, 19 –Register –Arrange Travel Next Steps