Query Health Technical Approach Primer Operations Workgroup

1. Query Health Technical Approach PrimerOperations Workgroup

2. Table of Contents • Goal of the Query Health Technical Approach • Key Actors • The Query Lifecycle • Query Health Specifications & Standards • Query Envelope • HQMF • QRDA • OWG Focus • Glossary

3. Goal of the Query Health Technical Approach • The goal of the technical approach document is to identify the technical requirements necessary at each step of the query process. • Technical Approach must promote interoperability. • Requestors want the ability to make queries and receive results in a standardized way. • Responders want the ability to use whatever technologies they want and implement it in whatever they want. • Both must have a common understanding of data element definitions(e.g., is sex expressed as ‘sex’ or ‘gender’?)

4. Key Actors

5. Our Example This document will focus on a query sent by a Requesting Organization (New York State Department of Health) and sent to a Responding Organization (Beth Israel Hospital).

6. The Query Lifecycle

7. Origins of the Technical Approach • The Query Health Technical Approach was created by the Query Health Technical Workgroup. • The Technical Workgroup examined three of the best approaches from the Summer Concert Series. • hQuery • i2b2 • PoPMedNet • The Technical Workgroup took the most relevant aspects from each of these three approaches to craft a custom Technical Approach for Query Health. • The following slides will explain the Technical Approach step by step. First, the step and the key actors will be highlighted on the graphic. Next, a slide will explain what happens during that step.

8. Lens through which to view the Technical Approach • As we go through the Technical Approach, view it through the lens of a “Risk Assessment”: • What is the privacy implication of this step? • What is a security risk association with this step? • What policies are in play here?

9. Step 1: Create Query Occurs within the Department of Health

10. Step 1: Create Query • The New York State Department of Health must create a query using one of three possible ‘Query Builders’: • hQuery • i2b2 • HQMF • These builders were chosen so that requestors do not have to be technical experts to create a query. Instead, they can create queries using common clinical language in a user-friendly interface. Occurs within the Department of Health

11. Step 2: Query is sent to PopMedNet Portal Occurs within the Department of Health

12. Step 2: Query is sent to PopMedNet Portal • The query is sent in the format of Modified HQMF* to the PopMedNet Portal. • PopMedNet has a user-friendly web-based portal, where queries are submitted. • *HQMF is a standard for representing health quality measures as an electronic document. The Query Health initiative is making modifications to the standard to suit the needs of Query Health. Occurs within the Department of Health

13. Step 3: PMN Portal sends Query to PMN Data Client Query Transported from Department of Health to Beth Israel Hospital

14. Step 3: PMN Portal sends Query to PMN Data Client The PopMedNetPortal sends the query, via Query Envelope, to the PopMedNet Data Client. • The Query Envelope is designed to be query and content agnostic and ensure enforcement of privacy and security requirements. • The PopMedNet Data Client is the counterpart of the PopMedNet Portal where queries are received by (Beth Israel Hospital). Query Transported from Department of Health to Beth Israel Hospital

15. Step 4: PMN Data Client sends Query to Procedural Translator Occurs within Beth Israel Hospital

16. Step 4: PMN Data Client sends Query to Procedural Translator PMN Data Client sends the Query to the Procedural Translator which creates specific directions on how to run the query. The Procedural Translator takes the message in HQMF (declarative language) and translates it to JavaScript or SQL(procedural languages). Note: In this step, Responding Organizations, like Beth Israel, have the right to reject any query. Occurs within Beth Israel Hospital

17. Step 5: Procedural Translator sends Query to Execution Engines Occurs within Beth Israel Hospital

18. Step 5: Procedural Translator sends Query to Execution Engines The Procedural Translator sends the query to the Execution Engines. • They query is now in JavaScript or SQL (procedural languages) • The Execution Engines run the queries while matching the concepts (e.g. “diabetes” and/or codes (e.g. an ICD 9 code) to the Data Sources using the CIM(CEDD). • Clinical Information Model (CIM)/Clinical Elements Data Dictionary (CEDD) is a dictionary that is an ‘overlay’ on the Data Source. It is a translation tool. • Example: A query may ask for the number of people taking a particular medication. The system will use the CIM/CEDD as a reference to identify the number of patients who have that medication listed in their ‘active medications list.’ • All of this occurs behind Beth Israel’s firewall, thus maintaining patient privacy and security of data. E Occurs within Beth Israel Hospital

19. Step 6: Execution Engines send results to QRDA Translator Occurs within Beth Israel Hospital

20. Step 6: Execution Engines send results to QRDA Translator The Execution Engines take the results, which are still in JavaScript or SQL and send them to the QRDA Translator, to be changed to QRDA. • QRDA is a document format that will provide a standard structure with which to report results. • Remember: The Department of Health does not necessarily understand the coding language of Beth Israel Hospital (JavaScrip or SQL). • Therefore results must be translated in a standard way before they can be sent back to the Department of Health. • The standard selected by the Technical Workgroup for expressing query results is QRDA Category III*. *QRDA Category III was selected because it allows for returning aggregate or summary level results. Occurs within Beth Israel Hospital

21. Step 7: QRDA Translator sends results back to PMN Data Client Occurs within Beth Israel Hospital

22. Step 7: QRDA Translator sends results back to PMN Data Client The QRDA Translator sends the results back to the PopMedNet Data Client, which routes them back to the PopMedNet Portal. • The PopMedNet Data Client is the last stop at Beth Israel before the results are sent back to the Department of Health. Occurs within Beth Israel Hospital

23. Step 8: PMN Data Client sends results back to PMN Portal Query Transported from Beth Israel Hospital to Department of Health

24. Step 8: PMN Data Client sends results back to PMN Portal The PopMedNet Data Client sends the results, now in QRDA, back to the Department of Health through the PopMedNet Portal using the Query Envelope. • The Query results are now in the hands of the Department of Health. • Reminder: The Query Envelope is designed to be query and content agnostic and ensure enforcement of privacy and security requirements. Query Transported from Beth Israel Hospital to Department of Health

25. Step 9: PMN Portal sends the results to the Results Viewer Occurs within the Department of Health

26. Step 9: PMN Portal sends the results to the Results Viewer The PopMedNet Portal now sends the results to the Results Viewer, a specific interface designed for reviewing query results. Now an individual at the Department of Health can review the results. The lifecycle of the query is now complete. Occurs within the Department of Health

27. Summary: Query Health Specifications and Standards Query Health must standardize how queries are asked, how they are returned, and how the information travels between parties.

28. Query Envelope • PopMedNet Query Envelope – essentially wraps metadata around data and protects it with a data/security layer • Metadata is essentially data that describes data • It offers integration among different systems; designed to have some flexibility • Designed to be query and content agnostic

29. What does the Query Envelop mean to the Operations WG? • The Query Envelope contains supporting metadata that ensures enforcement of privacy and security requirements defined in the Query Health Policy Sandbox (e.g., Small Cells, Author, Verifier) • What metadata needs to be a part of the package? • Author? • Reviewer? • Time for completion? • Instructions? • Encryption? • What else? • What security implications do you see during the data exchange?

30. HQMF – Health Quality Measures Format • Under HHS direction, NQF was tasked with retooling 113 endorsed quality measures from a paper-based format to an eMeasure format. • HQMF is a standard for representing health quality measures as an electronic document that is machine readable. • A health quality measure encoded in the HQMF format is referred to as an “eMeasure”. • eMeasuresmay be understood by providers to guide optimal care, and to guide collection of Electronic Health Record (EHR) and other data, which is then assembled into quality reports • HQMF Targets the following groups: • Healthcare Providers • EHR Vendors • Physicians and Clinicians • Quality Improvement Reporting Agencies

31. What does HQMF mean to the OWG? • Query Format • Best Practice research regarding the most applicable eMeasures to Query Health • Best Practice research focused on how quality measures are captured by responding organizations • Oversight of the types of queries submitted as well as determined usage of query results • Who can submit queries? • What kinds of queries are out of bounds? • What health insurance questions cannot be asked? • What private sensitive information cannot be queried? • Are there groups or vulnerable populations that have cultural, religious restrictions regarding data exchange? • What about the exchange of highly sensitive information, such as someone’s HIV status?

32. QRDA – Quality Reporting Document Architecture • Quality Reporting Document Architecture (QRDA) is a document format that will provide a standard structure with which to report quality measures. • Conforms to the requirements of the Health Level Seven (HL7) Clinical Document Architecture Release 2.0 (CDA). • Emerging Standard but not widely implemented • If a result cannot be expressed in QRDA, the Reference Implementation will provide other options based on MIME Types • MIME: Multi-purpose Internet Mail Extensions- a specification for sending messages over the internet

33. What does QRDA mean to the OWG? • Results Format • Policy and Security implications focused on de-identification of results • Who can review results? • Could the OWG define the needed Governance body? • How can organizations enforce the principle that all data is de-identified? • What quality checks are in place as query results are produced to verify the queries are correct and meet the determined security and privacy guidelines?

34. Operations Workgroup Focus • The focus of the Operations Workgroup should be on a Risk Analysis • What stands out to you as a risk with this technical approach? • Examples: • What would be a problem when trying to implement this on a large scale? • Where do we need policies in place?

35. Glossary

36. Glossary

37. Glossary Note: In some cases, the terms listed in the Glossary may have more than one meaning. These definitions are intended to provide context solely for the Technical Approach Primer.