Query+Health+-+Consensus+Approved+Use+Case

include component="page" wikiName="siframework" page="Query Health Header"



**__ Thank you for your participation!! __**As of November 16th, 2011 the Query Health Use Case has been finalized. The document below as well as the text embedded within the Wiki reflect updates that were proposed and agreed upon during the formal Consensus Process. Please contact the Clinical Working Group Lead or Support Lead if you have any remaining questions or concerns.

To access the Final and Approved Microsoft Word version of the Query Health Use Case [|click here]:

To view the Query Health Use Case consensus page please click here.

toc

1.0 Preface and Introduction
To fully realize the benefits of health IT, the Office of the National Coordinator for Health Information Technology (ONC) through the Standards and Interoperability (S&I) Framework is developing Use Cases that define the interoperability requirements for high priority health care data exchange to maximize efficiency, encourage rapid learning and protect patients’ privacy in an interoperable environment. These Use Cases address the requirements of a broad range of Communities of Interests including, patients, providers, vendors, laboratories, standards organizations, public health organizations and Federal agencies.

These Use Cases describe:
 * The operational context for the data exchange
 * The stakeholders with an interest in the Use Case
 * The information flows that must be supported by the data exchange
 * The types of data required in the data exchange

The Use Case is the foundation for identifying and specifying the standards to support the data interoperability and developing reference implementations and tools to ensure consistent and reliable adoption of standards.

=2.0 Overview and Scope= The Query Health Initiative aims to identify the standards and services for distributed population health queries to certified EHRs and other patient data sources, such as HIEs, originating in the routine course of patient care. The intention of this initiative is not to support a single implementation of a query health network but provide the tools and framework for commonly aligned network data partners to form their own query health networks. As a result, information requestors will be able to create and securely distribute queries to data sources directly or via optional network data partners, who serve as intermediaries. The information requestors can distribute queries to data sources, or network data partners, who support the distributed queries; however the data sources ultimately retain control over the decision whether to respond to a query as well as maintain control over the data to be released. Network data partners, when used, may examine queries and pass them on to data sources, and may aggregate and modify the data returned, performing such tasks as masking of provider organization, etc. Data sources, such as provider organizations, will execute the query against a standard Clinical information Model (CIM); securely return the results of the query directly to the requester or via the network data partner. The Initiative will develop models for the technical and financial sustainability as well as best practices for organizations, management and coordination, data use, data sharing; giving consideration to privacy, security and consent requirements. It will also address methods for extensibility of the CIM; specifically those data elements, terminologies, and code sets that enable the queries and results expression.

The Initiative will align with and leverage other initiatives of the S&I Framework (e.g. Transitions of Care); EHR certification criteria; Meaningful Use requirements; and other health IT initiatives. The Initiative will evaluate and leverage where possible existing investments, technology and thought leadership in distributed query, implement the specifications through an open source reference implementation, and evaluate these findings through demonstrations and pilots. The evaluation will help refine these standards.

To support the goals and objectives of this Initiative, the Use Case and its requirements will evaluate and address several outcomes, such as the following (to be refined and further validated by the community):
 * EHRs and other clinical data sources have the capability to transform and map data (or a view of its data) to a common CIM;
 * Network data partners and data sources have the ability to participate with selected information requestors and specific queries;
 * Requestors will have the ability to create and securely deliver “well formed queries” to selected network data partners and/or data sources; and
 * Network data partners are able to examine and to pass the requestor information to the clinical data sources. Such information (depending on the functional requirements) may include confirmation of the query; security information of the requestor; and timeliness of the results being sought.

The Use Case scenarios focus on querying against an extensible common information model and returning a final result set. For the purpose of the ONC pilot, the initiative will prioritize and select a few User Stories, based on national priorities and existing research and public health network infrastructure. Additional User Stories, developed by the community, will be analyzed and evaluated to ensure that the architecture framework, standards and services for distributed queries are robust and extensible.

2.1 In Scope

 * Support one Generic and Expanded Analysis User Story for querying against an extensible common information model and returning a final result set
 * Consideration should be given to requirements for a base CIM which can be expanded by adding pluggable information models to support new, specialized query requirements
 * Disitributing Queries and collecting query responses from multiple provider organizations / data sources

2.2 Out of Scope

 * Data normalization other than MU Stage 1 and anticipated Stage 2 standards for health information exchange and clinical quality measure reporting
 * The Use Case does not prescribe architecture, this will be addressed by the Query Health Technical Working Group

2.3 Background
The Query Health Initiative and the subsequent Query Health Use Case have been selected for inclusion within the S&I Framework because of its strategic alignment to both the Affordable Care Act and Health Information Technology for Economic and Clinical Health Act. The Query Health Initiative will enable population analyses to inform both clinical and payment strategies for policy makers, payers, public health, researchers and other Information Requestors. Similarly, it will enable health systems and practices to assess and manage their operations in alignment with best practices. Essentially, providers will be able to calculate and report quality measures for their populations. From a HITECH perspective, the Query Health Initiative will leverage the standards and policies that enable the Meaningful Use for patient care, health information exchange and quality reporting.

The ONC and the Query Health Support Team have engaged leaders and gained commitment from providers, health IT vendors, states, federal partners, and research community to gain insight and support of this effort. As with each of ONC’s Standards and Interoperability Initiatives, the Query Health Initiative is an Open Government Initiative that will be consensus-based, transparent, and open to all interested parties. The following stakeholder groups will be essential to the success of the Query Health initiative.

Pilot Implementations. ||
 * **Stakeholders** || **Representative Profile** || **Targeted Contributions** ||
 * Providers; Infection Prevention and Control Practitioners || Providers within Health Systems and Hospitals, Physician Groups, Accountable Care Organizations, Academic Medical Centers, and others. || Prioritized User Stories and Functional Requirements.
 * Informaticists/

Research Community / Distributed Query Thought Leaders || Organizations leading distributed query initiatives including Mini-Sentinel, OMOP, hQuery, i2B2, SHARP, Universal Public Health Node, PopMedNet Electronic Support for Public Health, caBIG, and others. || Leadership in definition of CIM, Query Standards, Results Standards. Pilot implementations, Data Sharing Agreements || Support Pilot implementations. Support for definition of SDO independent CIM, ‘Query’, and ‘Return Results’ Standards. || Table 1: Key Stakeholder Groups for the Query Health Initiative.
 * Government Agencies || Federal, State, HIOs, Local agencies and other organizations responsible for population based analysis, reporting, monitoring, and others. || Prioritized User Stories and Functional Requirements. Pilot implementations. ||
 * Standards Community || Clinical Standards Experts. || Support for definition of SDO-independent CIM, ‘Query’, and ‘Return Results’ Standards. ||
 * Health IT Vendors || Mix of acute, ambulatory and analytics vendors – large and small. || Reference Implementation development.
 * Privacy and Security Experts || Consumer/patient and academic experts who represent the public’s interests for privacy and security. || Neutral/non-industry privacy and security experts. ||
 * Patient Advocates || Patient advocates who act as a liaisons between a patient, Health Care Provider(s) and research institutions. || Patient advocacy organizations. ||

2.4 Best Practice Considerations
An S&I Framework Use Case strives to address relevant and timely healthcare issues that will have downstream effects on the US healthcare reform agenda; specifically relevant to healthcare information technology. The Use Case for Query Health, at its most basic level, consists of an information requestor submitting a query to, and receiving results from a distributed network of partners. Findings from the Query Health Summer Concert Series indicated that distributed query networks actually faced business and organizational challenges greater than or equal to the technical challenges.

In order to succeed and become sustainable, Query Health networks will have to find solutions to a wide range of business, regulatory, and operational challenges. The first step in ensuring such success is developing a list of generic and high-level best practice considerations. These best practice considerations are operational requirements and considerations that each specific user story must follow. Each of these should be implemented in a way that is consistent with industry best-practices and accepted standards of practice.

This section sets forth the best practice operational requirements and considerations that should be applied to the Generic User Story. **These requirements will subsequently guide the development of specific and substantive requirements tailored to the Expanded Analysis User Story.**

Key operational requirements and considerations include:
 * **Principles for organization, management and coordination of distributed network of independent organizations**
 * Necessary and appropriate legal agreements among network participants, such as Data Use Agreements, Data Sharing Agreements and Service Agreements
 * Necessary and appropriate policies and procedures to operationalize agreements
 * Governance principles, depending upon participants, data and standards in use


 * **Sustainability**
 * Business and clinical models that create measurable value for all stakeholders and participants
 * Financial models which lower transaction costs for the system as a whole and show Return on Investment (ROI)


 * **Scalability and Performance**
 * Ensure that individual components and operational agreements will be scalable and will meet the appropriate business models

2.5 Regulatory Issues
This Use Case acknowledges the variations in privacy and security policies and requirements for reporting across local, state, tribal, and territorial boundaries, as well as voluntary versus mandatory requirements.

Federal privacy and security rules establish a set of requirements necessary to protect individually identifiable health information from unauthorized use and disclosure, all of which must be met by Query Health Participants. Specifically, networks must:
 * Comply with the laws governing the privacy and security of health information, including but not limited to HIPAA, HITECH, state and local rules
 * Comply with the applicable Fair Information Practices
 * Develop policies and procedures consistent with the Health IT Policy Committee and Health IT Standards Committee recommendations
 * Apply the Policy Sandbox requirements to ONC sponsored pilots

2.6 Communities of Interest
Communities of Interest represent a more detailed listing of stakeholders for use in understanding and articulating the Use Cases and user stories supporting the Query Health Initiative. These Communities of Interest are public and private stakeholders that are directly involved in the business process or are involved in the development and use of interoperable implementation guides and implementation of the solution.

The following list of Communities of Interest and their definitions are for discussion purposes for clinical information exchange:

__NOTE:__ //The S&I Framework’s Use Case Simplification Workgroup is working to refine these definitions so they can be used across all of the S&I Framework initiatives.// Table 2: Communities of Interest
 * **Member of Communities of Interests** || **Working Definition** ||
 * Healthcare Professionals || Healthcare providers with patient care responsibilities, including physicians, advanced practice nurses, physician assistants, nurses, psychologists, emergency care providers, home health providers, definitive care providers, pharmacists, and other licensed and credentialed personnel involved in treating patients. ||
 * Providers || Can include Healthcare system as well as Licensed Individuals; provide services ||
 * Provider Organizations || Organizations that are engaged in or support the delivery of healthcare. These organizations include Hospitals, Ambulatory Centers, Provider Practices, Integrated Delivery Networks, Preferred Provider Organizations, Health Maintenance Organizations, Health Systems, Academic Medical Centers, Long-Term Care Organizations, and Rehabilitation Centers. ||
 * Standards Organizations || Organizations whose purpose is to define, harmonize and integrate standards that will meet clinical and business needs for sharing information among organizations and for system interoperability. ||
 * EHR/EMR/PHR Vendors || Vendors which provide specific EHR/EMR/PHR solutions to manage patient health information to clinicians such as software applications and software services. These suppliers may include developers, providers, resellers, operators, and others who may provide these or similar capabilities. ||
 * Government Agencies || Organizations within the federal government that deliver regulate or provide funding for health, healthcare and healthcare, clinical or biomedical research. ||
 * Health Information Exchanges (HIE)/Health Information Organizations (HIO) || The organizations that mobilize healthcare information electronically across organizations within a region, community or health system. ||
 * Beacon Communities || Selected communities of groups who have received federal funding through the Office of the National Coordinator (ONC) of Health Information Technology to build and strengthen their health information technology (health IT) infrastructure and exchange capabilities to improve care coordination, increase the quality of care, and slow the growth of healthcare spending. ||
 * Health Information Service Providers (HISP) || Entities that serve as a node on the Nationwide Health & Information Network to enable a private, secure and safe alternative method to send and receive sensitive health information. ||
 * Community Health Record Vendors || A Community Health Record (CHR) is an electronic health record that is shared between and among a community of health care providers and payers. Vendors which provide specific CHR solutions to clinicians such as software applications and software services. These suppliers may include developers, providers, resellers, operators, and others who may provide these or similar capabilities. ||
 * Personal Health Records (PHRs) Vendors || Vendors which provide specific PHR solutions to clinicians such as software applications and software services. These suppliers may include developers, providers, resellers, operators, and others who may provide these or similar capabilities. ||
 * Purchaser || Any private or public entity that finances health care delivery or organizes health financing. This includes commercial for-profit health insurers, self-insured employers, non-profit health insurers, state and federal department agencies that oversee Medicaid and Medicare health services delivery. ||
 * Healthcare Analytics Companies/Organizations || Companies or organizations that develop business solutions that allow for the extensive use of health care data for statistical and qualitative analysis as well as explanatory and predictive modeling. ||
 * Research Organizations || Organizations that conduct research activities in certain health, medical, pharmaceutical, or similar fields to address challenges that could benefit a broad group of people. These organizations include academic research organizations such as universities and medical schools, pharmaceutical companies, biomedical device companies, health research foundations, Federal health research agencies, etc. ||
 * Public Health Agency (State/Local) || State or Local health department agencies that oversee and manage public health activities within their respective geographies. ||
 * Health Care Investigators/Advisors || The Health Care Investigators/Advisors investigates practice violations, criminal conduct or non-compliance with licensure law by health care professionals ||
 * Quality Reporting Agency || Designed to improve the outcomes and quality of health care, reduce its costs, address patient safety and medical errors, and broaden access to effective services. For compliance purposes, providers are required to submit a set of quality measures to these agencies. ||

=3.0 Challenge Statement= The nation is reaching a critical mass of Electronic Health Records (EHRs) that comply with data and vocabulary standards. The wide deployment of EHRs creates an opportunity to aggregate health care data to provide a broad range of benefits that can contribute towards improved health of individuals and the population as a whole. A standardized CIM and a common method for querying data sources are critical to enabling and simplifying data aggregation across widely distributed EHR systems.

There are a number of important uses for distributed queries, including quality measures, disease outbreaks, comparative effectiveness analysis, efficacy of drug treatments and monitoring health trends. These are largely supported today by extracting data from source systems and integrating it into a centralized database where queries and analysis are managed. The Query Health Use Case moves away from the centralizing tendency to “bring the data to the questions” to distributed population queries that “bring questions to the data.” Distributed queries provide access to data, for analysis purposes, while maintaining patient privacy and security by keeping protected health information safely behind healthcare organization firewalls. This will reduce the complexity of managing patient consent and authorizations, audit logs and access lists requirements.

The Query Health project will establish requirements for the CIM, distributed queries and results expression, with the objective of giving providers, consumers, researchers and others insight into prevention issues, healthcare research and disease outbreaks. Standards and services for distributed population queries will be selected to enable widespread adoption of the CIM and query capabilities. Use of these standards and services will result in increased speed and reduced transaction costs for stakeholders to analyze and apply information, ultimately reducing the cost of healthcare and improving the health of citizens. = = =4.0 Value Statement= As evidenced by the Query Health Summer Concert Series, distributed queries have been used to support a number of healthcare and health related operations, including quality monitoring, public health surveillance, and clinical research. Approaches to date have relied upon dedicated experts exploring standards and services to best utilize data from distributed systems. The value of the Query Health Initiative will be to lower the barrier using consensus-based standards and specifications to support queries for population based/aggregated data from certified EHRs and other community records. The initiative will provide a standardized CIM to support implementable, high-value user stories, based on available, shareable and standardized information from EHRs and other patient care systems. The initiative will also provide extensible ‘Query’ and ‘Return Results’ standards and services, enabling interoperability between and among information requestors and data sources. Specification of these standards will assist the development and implementation of software and pilots, and will facilitate analysis of results. Use of these standards and services can result in increased speed and reduced transaction costs for healthcare providers to analyze and apply information regarding prevention activities, healthcare research, and disease outbreaks. These benefits can be combined to reduce the overall cost of healthcare and to improve the health of all citizens.

=5.0 Use Case Assumptions= Assumptions are general assertions of requirements that must be met in order for the specific technical information interchange, supporting the distributed queries proposed by Query Health, to be implemented. They generally refer to policy, business and technology requirements.


 * The CIM will use standardized vocabulary and computable data elements (leveraging the CIM from the Transitions of Care Initiative) required for health information exchange for Meaningful Use Stage 1 and anticipated Stage 2
 * The outputs of other S&I Framework Initiatives (Transitions of Care, Laboratory Results Interface, Provider Directory, Direct, etc.) will also be incorporated as part of the design of the Query Health outputs
 * The Use Case does not prescribe architecture, this will be addressed by the Query Health Technical Working Group
 * Addressing /directories, data rights, and rights for execution of services are to be managed “out of band”, not within the defined information interchanges
 * A query health network of information requestor(s), network data partners and providers (data sources) has been established including all necessary agreements outlined in Best Practices in Section 2.4 and to address regulatory issues outlined in Section 2.5
 * 1:1 relationship between each EHR and its CIM
 * The 1:1 relationship between EHR and the Query Health Data Interface is a simplifying assumption that for each EHR one Query Health Data Interface exists for the pilot. It does not suggest a 1:1 relationship exists between the fields in the EHR and the Query Health Data Interface. It is likely that additional fields and data sources (like claims) will be added over time.
 * The CIM will reside as a view of the EHR system data or in a Clinical Data Repository (CDR)
 * Appropriate use and/or disclosure rules will be applied to protected health information, de-identified or limited data sets within the CDR
 * The EHR and CDR should have the ability to maintain a file or audit log of patient level data used for each query response
 * Initial pilots will attempt to use data elements which EHR systemssm are required to include in clinical summaries under Meaningful Use. Such data elements are being modeled in the Transitions of Care CIM
 * Data Extensibility: As new certification and other query requirements evolve (e.g. for MU Stage 2) the base CIM will need to be kept up to date and consistent across the nation while allowing for pluggable information models, across multiple networks to meet new or local needs
 * The Query Health Initiative's architecture will be designed to allow for future phases and include:
 * Patient matching and the ability to de-duplicate
 * Claims data source
 * Capture of historical data through changes in patient information
 * The Technical Working Group will develop the detailed technical requirements to fulfill Use Case Functional and Data Requirements as part of standards and data harmonization process

=6.0 Pre-Conditions=
 * Query Health Network has been established and all participating organizations have signed data use agreements, etc. as laid out in the Best Practices section
 * All organizations in the Query Health Network have implemented the software and hardware that makes them a functional component of the network
 * Information Requestor has appropriate query for the Query Health Network

=7.0 Post Conditions=
 * The Information Requestor receives and processes query results

=8.0 Use Case Actors and Roles= This section describes the Business Actors that are participants in the information exchange requirements for each scenario. A Business Actor is an abstraction that is instantiated as an IT system application that a Stakeholder uses in the exchange of data needed to complete Use Case action(s). Furthermore, the systems perform specific roles in this Use Case as listed below:

__NOTE:__ //A role can be carried out by actors not included in this table; however, for the purposes of this Use Case, we are focusing on the content within the table below. In addition, the same actor may perform a combination of roles. Note also that the term Aggregator is applied to the initial data source function of extracting and totaling data from individual patient records. The term Collector/Combiner is the function in which aggregated results from multiple data sources are totaled and/or summarized across the larger population.//
 * **Business Actor** || **System** || **Role** ||
 * Provider/Provider Organization || Electronic Health Record System || Data Source/Query Responder, Aggregator, Query Request Receiver, Network Data Partner, Information Collector/Combiner ||
 * Intermediary (e.g. HIE, HISP) || Health IT System || Data Source /Aggregator, Query Request Receiver, Network Data Partner, Information Collector/Combiner ||
 * Query & Results Reviewer || Workflow System || Network Data Partner, Results Receiver ||
 * Other Data Sources (e.g registries, reference laboratories, or other specialized data sources) || Registry System || Data Source, Aggregator ||
 * Providers/Payors || Claims System || Information Collector/Combiner, Data Source, Aggregator ||
 * Information Requestor || Health IT System || Query Source, Results Receiver, Information Collector/Combiner ||

Table 3. Actors and Roles

=9.0 Use Case Diagrams=

.

Figure 1. Query Health Use Case Diagram

Figure 2. Query Health Context Diagram

=10.0 User Stories=

10.1 Generic User Story
The purpose of the generic user story is to provide a set of agreed upon business actors, abstract roles, elements, and processes for distributed queries. This generic user story will be used as a starting point and tailored for specific types of queries and responses from the user point of view. The functional requirements based on the user stories will need to take into account the variability of queries and information that may need to be exchanged, and this may be reflected in a richer set of requirements than a single user story may convey.

10.1.1 Generic User Story Actors & Roles
Please refer to section 8.0, table 3, for the Generic User Story business actors and roles.

10.1.2 Generic User Story
As part of Meaningful Use Stage 1 requirements, eligible Providers/Provider Organizations must populate or enter structured clinical data into an EHR (data source) for medications, laboratory orders/results, diagnoses/problem lists, allergies, demographic information, and vital signs. The availability of the data allows the Providers/Provider Organizations to become data sources/aggregators for Query Health. In addition to Provider/Provider Organizations, other possible data sources can be various registries (professional societies', state registries) and payor organizations (based on claims information).

An authorized Information Requestor, the query source, initiates a query for a particular purpose. The query could go directly to a data source, or through an Intermediary, a network data partner. Depending on the purpose of the query, it may be a one-time query, or it may be a request for a periodic update of the results. Upon receiving the query, based on the specific type of query or jurisdiction requirements the Provider/Provider organization may verify that relevant local authorizations are obtained that and any regulatory, privacy, proprietary or similar issues are addressed as generally described in 2.4, 2.5 and 6.0. The Provider/Provider organization, in its role as a data source, extracts the data for each result type requested in the query. The data extraction can occur at different intervals and can either be pre-extracted or extracted real time. An log is created to track the query requests and results. The final Result Set from the Provider/Provider Organizations (data source) is sent back to the Information Requestor (query source).

When the data needs to be aggregated and/or de-identified, additional steps and actors may be involved. For example, a Query and Results reviewer may approve the results for distribution for some types of queries. An Intermediary acting as a network data partner and information data collector/combiner may be needed to aggregate results from multiple data sources or sent to multiple query sources.

10.2 Expanded Analysis for Diabetic Care in an Outpatient Setting
This User Story represents a specific instance of the Generic User Story in which a public health agency distributes queries to providers and their intermediaries to assess the management of diabetes in the outpatient setting.

10.2.1 Expanded Analysis User Story Actors and Roles
__OR__ Health Information Exchange (HIE)/Regional Health Information Organization (RHIO) || Electronic Health Record System/Health IT System || Data Source/Query Responder, Aggregator, Query Request Receiver, Network Data Partner, Information Collector/Combiner || Table 4: Expanded Analysis User Story Actors and Roles
 * **Business Actor** || **System** || **Role** ||
 * Provider/Provider Organization
 * Query & Results Reviewer || Workflow System || Network Data Partner, Query Request Receiver, Results Receiver ||
 * Public Health Agency (i.e. Department of Public Health) || Health IT System || Query Source, Results Receiver, Information Collector/Combiner ||

10.2.2 Expanded Analysis Operational Requirements
This section sets forth the best practice operational requirements and considerations that should be applied to the Expanded Analysis User Story.

Key operational requirements and considerations include:

1. Principles for organization, management and coordination of distributed network of independent organizations
 * Necessary and appropriate legal agreements among network participants, such as Data Use Agreements, Data Sharing Agreements and Service Agreements. These agreements, or combinations thereof, will:
 * Address ONC Policy Sandbox principles (described below) and be drafted under the assumption that the information requestor is a public health agency
 * Address disclosure of de-identified aggregate data at the provider level/HIE and use for follow-up queries or contacts
 * Detail the scope and purpose of, and data types (i.e., counts) involved in, queries; response times; data integrity; and re-identification.
 * Necessary and appropriate policies and procedures to operationalize agreements
 * Governance principles, depending upon the participants, data and standards in use
 * These will build on existing frameworks at pilot networks

2. Sustainability
 * Business and clinical models that create measurable value for all stakeholders and participants
 * Financial models that lower transaction costs for the system as a whole and show Return on Investment (ROI)

3. Scalability and Performance
 * Ensure that individual components and operational agreements will be scalable and perform to meet the appropriate business model
 * Pilots will build on existing networks, participants and agreements

10.2.3 Expanded Analysis Regulatory Issues
Federal privacy and security rules set forth requirements necessary to protect individually identifiable health information from unauthorized use and disclosure, all of which must be met by Query Health Participants. This User Story acknowledges the variations in privacy and security policies and requirements for reporting across local, state, tribal and territorial boundaries, as well as voluntary versus mandatory requirements.

At a minimum, participants must:
 * Comply with the laws governing the privacy and security of health information, including but not limited to HIPAA, HITECH and state and local rules
 * Comply with the full complement of applicable Fair Information Practices
 * Review and consider policies, procedures, and recommendations developed by the Health IT Policy Committee and Health IT Standards Committee
 * Develop best practices and procedures consistent with those developed by ONC
 * Apply Policy Sandbox requirements, including
 * Whether or not to run a particular query, and to release any results, will be under the control of the disclosing entity/data holder.
 * Data being exchanged should either be de-identified or an aggregated limited data set, with a data use agreement in place even for de-identified data. The data use agreement should prohibit the recipient from re-identifying the data.
 * During the initial pilot phase of Query Health, there should be some limits on how recipients of Query Health results are permitted to subsequently use and disclose those results. Permissible uses for classes or categories of Query Health questions should be established, and the data use agreement should limit subsequent use and disclosure to those permissible uses. Such permissible uses should be commensurate with the potential privacy risk posed by the data (for example, a more limited set of permissible uses for “line level” data vs. data that is provided in summarized form). Of note, recipients of Query Health data should be permitted to use results received from Query Health to develop follow-up queries or questions.
 * Query Health policy should be that when identifiable data are needed to address a particular public health query, identifiable data should be disclosed in a manner consistent with applicable law. However, if identifiable data are not needed —and a limited data set, aggregate summary data or de-identified data would adequately address the question and are feasible to generate – such data should be disclosed in less identifiable form. This policy of Query Health should not be interpreted to impede public health reporting requirements.
 * For other than regulated/permitted use purposes, cells with less than 5 observations in a cell shall be blurred by methods that reduce the accuracy of the information provided. (The CDC-CSTE Intergovernmental Data Release Guidelines Working Group has recommended limiting cell size to three counts presuming a sufficiently large population; this is also reflected in guidelines used by several states.)

10.2.4 Expanded Analysis Assumptions

 * Provider/Provider Organization has an Electronic Health Record System.
 * HIE/RHIO for this User Story has a data repository (non-federated model).
 * As part of Meaningful Use Stage 1 requirements, eligible Providers/Provider Organizations at the minimum must populate or enter structured clinical data into an EHR for medications, laboratory orders/results, diagnoses/problem lists, allergies, demographic information, and vital signs. This data is sent to the Health HIE/RHIO.
 * Not all queries require the use of a numerator and denominator. Depending on the context of the question, the query may not include a denominator.
 * Summarized query results are numeric results (counts, sums, averages, etc.). The Query Results can be interpreted as a numerator and or denominator count as needed.
 * A Query Result could return multiple counts that could be interpreted as multiple numerators and denominators in the same result set.
 * For this User Story we are interpreting the counts in a numerator and denominator format; however alternative inpretations of a count are possible.
 * In some cases there can be multiple numerators over one denominator depending on the context of the question.
 * A query health network of information requestor(s), network data partners and providers (data sources) has been established including all necessary agreements outlined in Best Practices in Section 10.2.2 and to address regulatory issues outlined in Section 10.2.3.

10.2.5 Expanded Analysis User Story
A Public Health agency wants to understand how care is being managed in a select area.

A Public Health agency is interested in learning more about the management of diabetic care in a select region. The region under observation has a network of Provider/Provider Organizations with Electronic Health Record Systems or an central HIE/RHIO where the local Provider/Provider Organizations send their patients clinical data for population care management purposes under business associate and appropriate data use agreements. When the HIE/RHIO thus takes on the role of data source it determines what data should be disclosed. The data source formats and loads the clinical data into the CIM/Repository.

A Public Health agency (Information Requestor) initiates a query, as a query source, to learn more about diabetic care management for a given population. More specifically, the agency would like to receive counts of patients based on a number of condition specific data points, which are also considered the denominator options. In addition, a query will also be sent to find the overall risk stratification score for different populations. The specific questions asked as part of the query will be based on the numerator and denominator counts options listed below.

__NOTE:__ //The CMS e-Measures will be used to define the inclusions and exclusions which will be further refined as part of the technical specification.//


 * Numerator Counts** //(for each characteristic listed below the query should be based on same population)//
 * Counts of Patients based on the Quality Measures (which are listed in Appendix C)
 * Encounter Type
 * Timeframe (last 90 days, 1 day, etc.)
 * Risk Stratification Sum
 * Risk Stratification Score is calculated by counting the number of risk factors out of control. The query result will also show the number of patients out of control for each individual risk factors.
 * HbA1c > 9.0%
 * Blood Pressure ≥ 140/90 mm hg
 * LDL ≥ 130 mg/dl
 * Smoking Status
 * BMI ≥ 25
 * Microalbumin > 30 micrograms/mg Creatinine
 * Denominator Counts:**
 * Age (in ranges or groups)
 * Zip Code
 * Ethnicity
 * Race
 * Gender
 * Not Deceased (as of query date)
 * Diabetes Diagnosis Code (Type I, Type II)
 * Insurance Coverage (Y/N)
 * Insurance Type (Commercial, Federal, State)
 * Practice
 * Number of Inpatient Visits (within a specified time period)
 * Number of Outpatient Visits (within a specified time period)
 * Medication by Class (Statin, Aspirin, Ace Inhibitor/ARB)

To facilitate this request the Public Health agency sends a query request, selecting numerator and denominator specifications (where applicable), directly to the data source. The purpose and frequency of the request are also included as part of the query request.

The Provider/Provider Organization or HIE/RHIO acts as a query and results reviewer and examines the query request. After validating the query request the Electronic Health System/Health IT system utilizes the CIM to execute the query against the data of interest. The data extraction can occur at different intervals and can either be pre-extracted or extracted real time. The data is further refined to determine the specific count and/or risk stratification score for the desired population. The data source extracts the data for each result type requested in the query. The query is run against the extracted data and the results are aggregated to create the query result, including both the numerator and denominator counts. These results make up the query response.

A log is created to track the query requests and results. The final Result Set from the Provider/Provider Organization or HIE/RHIO (data source) is sent back to the Information Requestor (query source).

An example result set format is shown in table 6. This table is for illustrative purposes only and can be used to show the care for diabetic patients within a specific region for a given time period.



Table 5: Example Result Set

=11.0 Activity Diagram= The visuals below depict a combination of all events described in the scenario flows which are described in further detail in section 11.1.

Figure 3. Activity Diagram

11.1 Base Flow

 * **Step #** || **Actor** || **Role** || **Event/Description** || **Inputs** || **Outputs** ||
 * 1 || Electronic Health Record/ Health IT System || Data Source || Clinical Data is captured in the Electronic Health Record System || Raw Clinical Data || Clinical Data ||
 * 2 || Electronic Health Record/ Health IT System || Data Source || Electronic Health Record System Loads Clinical Data to CIM/Repository || Clinical Data || Standardized Clinical Data ||
 * 3 || Information Requestor Health IT System || Query Source || Information Requestor Health IT System Creates Query || Question to be Answered || Well Formed Query ||
 * 4 || Information Requestor Health IT System || Query Source || Information Requestor Health IT System Securely Distributes/Publishes Query || Well Formed Query || Well Formed Query Message ||
 * 5 || Intermediary Health IT System || Network Data Partner || Intermediary Health IT System Receives Subscribed Queries || Well Formed Query Message || Well Formed Query Message ||
 * 6 || Intermediary Health IT System || Network Data Partner || Intermediary Health IT System Examines and Distributes Queries, including security info of requestor and time to return to Data Sources || Well Formed Query Message || Query Request Message ||
 * 7 || Query & Results Reviewer Workflow System || Network Data Partner || Query & Result Reviewer Workflow System Examines, Validates and Distributes Queries, including security info of requestor and time to return to Data Sources || Query Request Message || Query Request Message ||
 * 8 || Electronic Health Record/ Health IT System || Data Source || Electronic Health Record/Health IT System Receives and Examines Query || Query Request Message || Query Request Details ||
 * 9 || Electronic Health Record/ Health IT System || Data Source || Electronic Health Record/Health IT System Checks for Patient Consent and Creates a File or Audit Log of All Patient Level Data Used to Create Query Result || Query Request Details || Query Request Details ||
 * 10 || Electronic Health Record/ Health IT System || Data Source || Electronic Health Record Health IT System Executes Query || Query Request Details || Query Request Details ||
 * 11 || Electronic Health Record/ Health IT System || Data Source || Electronic Health Record/Health IT System Utilizes CIM to Extract and Aggregate the Requested Data || Query Request Details || Extracted and Aggregated Data of Interest ||
 * 12 || Provider/ Provider Organization || Data Source / Aggregator || Electronic Health Record/Health IT Formats Aggregated Analysis Results into the Query Request Result Field. || Extracted and Aggregated Data of Interest || Aggregated Data of Interest and Audit File and/or Log ||
 * 13 || Provider/ Provider Organization || Data Source / Aggregator || Electronic Health Record/Health IT System Releases Result (either manually or electronically) || Releasable Aggregated Query Result || Released Aggregated Query Result ||
 * 14 || Electronic Health Record/ Health IT System || Data Source / Aggregator || Electronic Health Record System Sends Releasable Aggregated Query & Results Reviewer || Released Aggregated Query Result || Aggregated Query Result ||
 * 15 || Query & Results Reviewer Workflow System || Network Data Partner || Query & Result Reviewer Workflow System Receives Aggregated Query Result || Aggregated Query Results || Aggregated Query Results ||
 * 16 || Query & Results Reviewer Workflow System || Network Data Partner || Query & Results Reviewer Workflow System Reviews, Approves (Manually or Electronically) and De-Identifies Aggregated Query Result for Release || Aggregated Query Results || Reviewed and Approved Aggregated Query Results ||
 * 17 || Query & Results Reviewer Workflow System || Network Data Partner || Query & Results Reviewer Workflow System Sends Aggregated Query Results || Reviewed and Approved Aggregated Query Results || Aggregated Query Results ||
 * 18 || Intermediary Health IT System || Network Data Partner || Intermediary Health IT System Receives Aggregated Query Result || Aggregated Query Results || Aggregated Query Results ||
 * 19 || Intermediary Health IT System || Information Collector/ Combiner || Intermediary Health IT System Collects and then Combines Aggregated Query Results from all Applicable Sources || Multiple Aggregated Query Results || Combined Aggregated Query Result ||
 * 20 || Intermediary Health IT System || Information Collector/ Combiner || Intermediary Health IT System De-Identifies (Population/Source Data) the Aggregated Query Result Where Applicable || Combined Aggregated Query Result || De-Identified Combined Aggregated Query Result ||
 * 21 || Intermediary Health IT System || Network Data Partner || Intermediary Health IT System Sends Aggregated Query Result to Information Requestor || Combined Aggregated Query Result || Query Result/ Answer to Question ||
 * 22 || Information Requestor Health IT System || Results Receiver || Information Requestor Health IT System Receives Aggregated Query Result || Query Result/ Answer to Question || Aggregated Data ||
 * 23 || Information Requestor Health IT System || Query Source || Information Requestor Health IT System Refines the Query || Question to be Answered || Refined Well Formed Query ||
 * 24 || Information Requestor Health IT System || Query Source || Information Requestor Health IT System Securely Distributes Refined Query || Well Formed Query || Well Formed Query ||
 * 25-43 |||||||||| Repeat Steps 5 through 22 ||

Table 7: Base Flow

=12.0 Sequence Diagram=



Figure 4. Sequence Diagram

=13.0 Functional Requirements= Information systems participating in this Use Case must meet certain functional requirements based on their role. Functional requirements are of two types: information interchange requirements and internal system requirements.The Query Health Technical Working Group will develop the detailed technical requirements to fulfill Use Case Functional and Data Requirements as part of standards and data harmonization process.

13.1 Information Interchange Requirements
//*Query response will most likely be results but it can also include errors or rejections.// Table 7. Information Interchange Requirements
 * **Initiating System** ||  || **Information Interchange Requirement Name** ||   || **Receiving System** ||
 * Information Requestor Information System || Distribute || Query || Receive || Intermediary Information System ||
 * Intermediary Information System || Distribute || Query || Receive || EHR System/Clinical Data Source ||
 * EHR System/Clinical Data Source || Send || Aggregate Query Results || Receive || Intermediary Information System ||
 * Intermediary Information System || Send || Aggregate Query Results || Receive || Information Requestor Information System ||
 * Intermediary Information System || Send || Combined Query Results || Receive || Information Requestor Information System ||
 * Intermediary Information System || Send || Query Response* || Receive || Information Requestor Information System ||
 * Information Requestor Information System without Intermediary || Distribute || Query || Receive || EHR System/Clinical Data Source ||
 * EHR System/Clinical Data Source without Intermediary || Send || Query Response* || Receive || Information Requestor Information System ||

13.2 System Requirements
Table 8. System Requirements
 * **System** || **System Requirement** ||
 * Information Requestor Information System || * Create well-formed query (which includes query metadata) based on CIM
 * Process query results
 * Audit query response
 * Combine query results across organizations
 * Specify inclusion and exclusion criteria for the data source to use in sorting and calculating population based responses ||
 * Intermediary Information System || * Subscribe to queries
 * Examine query
 * Combine query results across organizations ||
 * Query & Result Reviewer Work Flow Information System || * Edit/Blur query responses
 * Audit query responses
 * Approve query
 * Approve response ||
 * Electronic Health Record System/Health IT System || * Capability to perform bulk and near time loading of patient data into the CIM
 * Publish patient data to a CIM
 * Validate CIM data and vocabulary
 * Execute query
 * Aggregate data as needed for query results
 * Analyze query result data
 * Examine query responses
 * Edit/Blur query responses
 * Audit query responses
 * De-identify when needed
 * Maintain file or audit log of patient level data used for each query result
 * Approve query
 * Approve response ||

13.3.1 Envelope Metadata - Query Request
NOTE: A "query" may consists of one or more result entries.
 * **Data Element** || **Definition** || **Notes** ||
 * Package ID || Global identifier for the entire query request package/set ||  ||
 * Query ID || A unique ID for one query request (there can be multiple query IDs under one request ID) ||  ||
 * Query Requestor || Information Requestor (Author or Organization's Name) who is initiating the query. ||  ||
 * Query Purpose || To answer the question that the query was created / initiated for. Examples include - Public Health Reporting, Research Reporting, Contracts, Biosurveillance, Quality Measure Reporting ||  ||
 * Query Request Type || Identifies the level of the expected result set. Aggregated, De-Identified, Limited Dataset, Protected Health Information || Query type should be linked to the security data.

__Personally Identifiable Information (PII)__

__Aggregated__: Numeric data (e.g. counts, averages, sums)

__Limited Data Set__: Allows a certain amount of identifiable information, defined by regulation to be exchanged (e.g. age, DOB) and requires a data use agreement

__De-Identified__: Detailed patient information without any individually identified information

__Protected Health Information__: Includes individually identified information on a patient level || Table 9. Envelope Metadata - Query Request
 * Notes/Annotation || Section dedicated to any notes or explanations in reference to overall query or elements within the query ||  ||
 * Contact Information || The appropriate contact information (E-mail and phone number) of the Query Requestor / other assigned point of contact to be contacted with questions regarding the query ||  ||
 * Priority Score || The purpose of this score is to prioritize the urgency and timing of requests execution and return of results. ||  ||
 * Query Request Expiration || The expiration date and time of the query request that has already been initiated || This can be done either via the Information Requestor or the Source System ||
 * Query Send Date || The date and time the query was distributed ||  ||
 * Query Start Date || The date and time the query is expected to begin execution and send final results || This can be done either via the Information Requestor or the Source System ||
 * Query End Date || The date and time the query is expected to end execution and send final results || This can be done either via the Information Requestor or the Source System ||
 * Frequency || Defines the total number of iterations (i.e. how often) the query should run within the set parameters of the query start and end date. A specified number of days, weekly, monthly, etc || This can be done either via the Information Requestor or the Source System ||
 * Active Flag || Determines whether the query request is Active or Inactive allowing for past requests to be preserved ||  ||
 * Renewal || Defines if the query can be reused (Yes/No) and therefore eliminating the need to repeatedly resend the same query ||  ||
 * Security Data || Applicable security information/security requirements. ||  ||
 * Sender Data ||  ||   ||
 * Receiver Data ||  ||   ||

13.3.2 Envelope Metadata - Query Response
NOTE: A "query" may consists of one or more result entries. Table 10. Envelope Metadata - Query Response
 * **Data Element** || **Definition** || **Notes** ||
 * Package ID || Global identifier for the entire query request package/set ||  ||
 * Query ID || A discrete unique identifier for on query instance ||  ||
 * Response ID || A discrete unique identifier for the for the response instance ||  ||
 * Query Requestor || Information Requestor (Author or Organization's Name) that is initiating the query ||  ||
 * Entity ID || A unique identifier of the health system or overarching provider organization. Examples include - hospital, hospital system, health system ||  ||
 * Entity Name || Name of the overarching organization || Example - XYZ Health System ||
 * Facility ID || A unique identifier of the provider's facility ||  ||
 * Facility Name || Facility where patient care was delivered || Example - Hospital A within the XYZ Health System. ||
 * Provider Name || Name of the individual provider ||  ||
 * Provider ID || Provider NPI or some other Unique Identifier (if available in the system) ||  ||
 * Response Date and Time || The date and time that query response is sent ||  ||
 * Security Data || Applicable security information/security requirements. ||  ||
 * Status Identifier || The individual or organization in charge of determining the Status of the query ||  ||
 * Status || The status of the query dictates whether or not the query is Approved, Not Approved, Rejected, Pending Approval, In Progress, Complete, or Deferred ||  ||
 * Status Date and Time || The date and time the Status is identified || Status types should include “warnings” along with a structured message describing the status itself. ||
 * Error Type / Messages || The error type or message ||  ||
 * Sender Data ||  ||   ||
 * Receiver Data ||  ||   ||

13.3.3 Query Syntax & Response Metadata (this will be defined outside the scope of the Use Case)
__NOTE:__ //The Query Health Technical Working Group will develop the detailed technical requirements to fulfill Use Case Functional and Data Requirements as part of standards and data harmonization process.//

This is the aggregate result response that includes the answer to the question. For example, this section can include grouping aggregate results by geographical groups like multiple zip codes, gender and ethnicity.

13.4 Dataset Requirements
__NOTE:__ //This section will be the starting point to gather the required data elements which will then be elaborated through the harmonization and standards development support activities.//

Vocabulary value sets supporting the prioritized Query Health user stories, will be defined by the community participants from patient data included in the CIM derived from patient care. These value set requirements and recommendations may be derived from required standards associated with problems, procedures, etc. al. used by Clinical Summaries and Quality Metrics. For example; SNOMED-CT; Medications - RxNorm; Multum, Medispan, First Data Bank, Immunizations - CVX; Results- LOINC; NDC; HSPC; ICD-9; ICD-10; UCUM.

13.4.1 Structured Data Elements for Generic User Story
__Note:__ //The initial set of computable data elements are derived from the ASTM CCR and HL7 CCD (as constrained by HITSP C32) which are specified for clinical summary documents in Stage 1 of Meaningful Use. These are included in the table below. A Transitions of Care CIM will be offered as the source of the data elements for Stage 2 summaries. These are not included in this table.//
 * **Ref.[[file:///C:/Users/merideth.c.vida/Documents/ONC/Query%20Health/UC%20Shared%20with%20External%20Teams/HHS_ONC_QueryHealth_Use%20Case_DRAFT_v0%2012.docx#_ftn1|**[1]**]]** || **Section** || **Data Elements** || **Notes** ||
 * T.CC.1 || Personal Information/Demographic Information || DOB, Next of Kin, Address, County, Gender, Marital Status, Religion, Race, Ethnicity, Language, Occupation, Level of Education || Note: only DOB, Gender, race/ethnicity and city, state and zip code may be included in limited data set (as long as the data set results in a small cell).

For this data to be used for syndromic queries the address, county (in contrast to billing address) and occupation need to be current. ||
 * T.CC.2 || Patient Contact Information || Contact Name, Contact Email, Contact Phone Number ||  ||
 * T.CC.3 || Insurance Information || Insurance Name, Phone #, Group #, Type, Member #, Subscriber Name, Financial responsibility ||  ||
 * T.CC.4 || Healthcare Provider || Provider Name, Provider Role, Provider Birthdate, Address, Phone Number,Type, Provider Fax Number, National Provider Identification ||  ||
 * T.CC.5 || Allergies and Other Adverse Reactions || Allergy Type; and Date

Substance intolerance

Associated Adverse Events ||  || Table 11. Standardized Computable Data Elements
 * T.CC.6 || Problem List || Current Diseases & Conditions monitored for the patient and status ||  ||
 * T.CC.7 || History of Past Illness || Diseases & Conditions Patient has suffered in the past ||  ||
 * T.CC.8 || Chief Complaint || Description of Patient's Complaint (narrative) || For syndromic queries there is a strong preference for captured in free-text using the patient’s own words. ||
 * T.CC.9 || Reason for Transfer || Reason Patient is being referred ||  ||
 * T.CC.10 || History of Present Illness || Sequence of events proceeding patient's disease/condition ||  ||
 * T.CC.11 || List of Surgeries || List of types of surgeries and dates ||  ||
 * T.CC.12 || Hospital Admission Diagnosis || List of Hospital Diagnosis and dates ||  ||
 * T.CC.13 || Discharge Diagnosis || Conditions/Diseases identified during hospital stay and dates ||  ||
 * T.CC.14 || Medications || List of current medication names; date, route, dose, frequency ||  ||
 * T.CC.15 || Admission Medications History || List of historical medication names, dose, route, frequency, date patient has taken prior ||  ||
 * T.CC.16 || Hospital Discharge Medications || Medications names, doses, frequency, route ordered for the patient for after discharge ||  ||
 * T.CC.17 || Medications Administered || Medications administered to patient during the course of an encounter; name, dose, route, frequency ||  ||
 * T.CC.18 || Advance Directives || A summary of patient's expectations for care ||  ||
 * T.CC.19 || Pregnancy || Pregnant, Yes/No || This should measure if the patient is currently pregnant. ||
 * T.CC.20 || Immunizations || Immunizations name, dose, route, date administered to the patient ||  ||
 * T.CC.21 || Physical Examination || Physical Findings of the Patient; VS, Biometrics, Review of Systems ||  ||
 * T.CC.22 || Vital Signs || Patient's Vital Signs ; Heart rate, Resp Rate, Pulse Ox, Temp, B/P, Pain, Height, Weight || For syndromic queries (e.g. measures of syndrome severity) initial temperature should be captured. ||
 * T.CC.23 || Review of Systems || Functions of various body systems; Neuro, Derm, GI, GU, Cardiac, Pulmonary, MS, Repro, Nervous, Endocrine ||  ||
 * T.CC.24 || Hospital Course || Sequence of (name, diagnosis associated with) events and dates from admission to discharge of hospital stay ||  ||
 * TBD || Diagnostic Order || Order and dates of Diagnostic Procedures ||  ||
 * T.CC.25 || Diagnostic Results || Results and dates of Diagnostic Procedures ||  ||
 * T.CC.26 || Assessment and Plan || Assessment of patients conditions and expectations/goals of care ||  ||
 * T.CC.27 || Plan of Care || Proposed interventions and procedures for patient ||  ||
 * T.CC.28 || Family History || Dates with Disease Suffered, Age of Death, other genetic information ||  ||
 * T.CC.29 || Social History || Patient's beliefs, home life, social/risky habits, family life, work history ||  ||
 * T.CC.30 || Encounters || Current and historical encounters; dates || This should be based on the visit ID and/or unique identifier. ||
 * T.CC.31 || Medical Equipment || Implanted and External Medical Devices; Dates ||  ||
 * T.CC.32 || Preoperative Diagnosis || Diagnosis (Date) assigned to patient prior to surgery ||  ||
 * T.CC.33 || Postoperative Diagnosis || Diagnosis (Date) assigned to patient after surgery ||  ||
 * T.CC.34 || Surgery Description || Particulars of Surgery (narrative) (images) ||  ||
 * T.CC.35 || Surgical Operation Note Findings || Clinically significant observations found during surgery ||  ||
 * T.CC.36 || Complications Section || Known risks or unidentified problems ||  ||
 * T.CC.37 || Operative Note Surgical Procedure || Date and Description of Procedure Performed ||  ||
 * TBD || Procedures ||  ||   ||
 * TBD || Diagnosis Type & Code ||  || Should include external cause of injusry code (e-codes and v-codes) ||
 * TBD || Visit Date/Time ||  ||   ||
 * TBD || Laboratory Orders ||  ||   ||
 * TBD || Laboratory Results ||  ||   ||
 * TBD || Security Information || Requestor, Time to Return to Data Sources, Patient Consent ||  ||
 * TBD || Care Setting || Hospital, Inpatient ||  ||
 * TBD || Facility Information || Facility ID, Facility Name, Facility/Visit Type ||  ||
 * TBD || Entity Information || Entity ID, Entity Name ||  ||
 * TBD || Functional Status || Activities of Daily Living like walking, bathing, smoking, drinking alcohol, etc. ||  ||
 * TBD || Enrollment/Observation Time || Start and Stop Date ||  ||

13.4.2 Structured Data Elements for Expanded Analysis
This table is a supplement to table 13.4.1. . It provides additional data elements required for the Expanded Analysis User Story and describes how they are to be used in constructing a query response.. These data elements (or derived ranges of data elements) are used for cross tabulated cell counts in the numerator and denominators as listed in Section 10.2.3.

Diagnosis Status (Inactive or Active) || Obtain total counts for patients that have identified Diabetes diagnosis codes ||
 * **Data Element** || **Definition** || **Notes** ||
 * Provider ||  || Obtain total counts for patients that were seen by an individual provider ||
 * Age ||  || Obtain total counts for patients that fall into identified age ranges ||
 * Zip Code ||  || Obtain total counts for patients that fall into regions identified by zip code ||
 * Gender ||  || Obtain total counts for patients based on gender. ||
 * Ethnicity || Ethnicity is a term that extends the concept of race. The coding of ethnicity is aligned with public health and other federal reporting standards of the CDC and the Census Bureau || Obtain total counts for patients that fall into identified Ethnicity categories ||
 * Race || Race is usually a single valued term that may be constant over that patient's lifetime. The coding of race is aligned with public health and other federal reporting standards of the CDC and the Census Bureau. Typically the patient is the source of the content of this element. However, the individual may opt to omit race || Obtain total counts for patients that fall into identified Race categories, multiple races need to be supported. ||
 * Last Seen || Date of last outpatient or inpatient encounter ||  ||
 * Alive || Y/N/Unknown || Was the patient alive during the time of the query? ||
 * Diagnosis Code (Diabetes) || Diabetes diagnosis codes that indicate either Type I or Type II
 * Insurance Coverage (Y/N) || Does patient have some type of insurance coverage? Yes or No. || Obtain total counts of patients that have insurance as well as counts of patients that do not have insurance ||
 * Insurance Type || The category that the patients' insurance coverage falls into - Commercial, Federal, or State || Obtain total counts of patients based on identified insurance types ||
 * Time Period || The data range that query should return results for ||  ||
 * Practice || The location name of where patient care was provided ||  ||
 * HbA1c ||  || Total counts for the following categories

Count of patients with HbA1c > 9.0 %

Count of patients with HbA1c< 8.0 %

Count of patients with HbA1c< 7.0 % ||
 * Systolic and Diastolic Blood Pressure ||  || Total count of patients with BP ≥140/90 mm Hg* ||
 * Eye Examination || Y/N || Total count of patients who have had an eye examination ||
 * Smoking Status || Y/N || Total count of patients who have had smoking status of a Yes or No ||
 * LDL ||  || Total counts for the following categories

Count of patients with LDL ≥130 mg/dl

Count of patients with LDL <100 mg/dl ||
 * Microalbumin level || Y/N || Has it been completed? (Y/N) ||
 * Microalbumin result ||  || Count of patients with Microalbumin > 30 micrograms/mg Creatinine

Count of patients with Microalbumin < 30 micrograms/mg Creatinine ||
 * Foot Examination ||  || Has it been completed? (Y/N) ||
 * BMI ||  || Count of patients with BMI ≥ 25 ||
 * Medication || Statin, Aspirin, Ace Inhibitor/ARB || Results should pull how many patients are taking medications in the identified class.

Medications can also be grouped as active,inactive, dispensed, ordered, etc. || Table 12. Structured Data Elements for Expanded Analysis

=14.0 Risks, Issues and Obstacles= As existing user stories expand and others are added to the Query Health Use Case numerous risks, issue and obstacles are likely to arise. This list is intended to be a starting point which will need further consideration as the Query Health network grows. Open issues that will need to be addressed as scale increases include:

=Appendix=
 * Dependent on capability of EHR system to provide standardized data consistent with CIM which will change with time
 * Timing and transition from Stage 1 to Stage 2 requirements including:
 * C32 to CDA Consolidation for MU Stage 2 and proposed constraints on code sets
 * New clinical quality measures
 * Potential use of metadata tagging
 * Changes to public health, surveillance and adverse reporting standards
 * Existence of a Extractor/Aggregator Function within or associated with an EHR
 * Who is responsible for payment
 * Financial and cost avoidance incentives
 * Proof of lower transaction costs and added value to all stakeholders (it is likely that some stakeholders will benefit more than others)
 * Net value of Query Health Network considering
 * Start-up costs
 * Ongoing costs
 * Expected return or value to network participants
 * Organization, management and coordination issues, including:
 * CIM agreement, maintenance and enhancements
 * Privacy and proprietary data issues
 * Security within distributed environment
 * Capability of Query Health networks to grow and scale as needed
 * Obtaining “out of band” agreements from each participating entity
 * Adding new participants
 * Introducing new purpose, scope and query types
 * Adding new coverage area or jurisdiction
 * Gaps in data collection standards
 * Lack of standards for many clinical concepts and population health indicators
 * Linkage of individual’s data across sources and over time
 * Interpreting results from a distributed network requires a thorough understanding of the data and may require follow up between data partners

Appendix A: Previous Work Efforts/Reference Materials
NOTE: This list should not be considered inclusive.
 * i2b2 / SHRINE – i2b2 (Informatics for Integrating Biology and the Bedside) is a scalable informatics framework deployed at 60 sites in the US and internationally. SHRINE (Shared Health Research Information Network) supports distributed queries over selected standard data and participating sites. [|http://i2b2.org]
 * Laika – Laika analyzes and reports on the interoperability capabilities of EHR systems. This includes the testing for certification of EHR software products and networks. []
 * PopHealth – PopHealth is an open source reference implementation software service which automates the reporting of Meaningful Use quality measures. PopHealth integrates with a healthcare provider’s electronic health record system using continuity of care records. PopHealth also streamlines the automated generation of summary quality measure reports on the provider’s patient population. []
 * The Hub Population Health System - The Hub Population Health System was designed by the New York City Department of Health and Mental Hygiene in partnership with multiple EHR partners. The system permits the aggregation of population health metric counts for over 1.5 million patients in 400+ clinics using a distributed query model. The system was recently awarded the 2011 HIMSS Public Health Davies Award of Excellence and is described in an in-press article of the Journal of the American Medical Informatics Association.
 * hQuery – hQuery is an open source research project being developed by MITRE looking into best technical practices for national-scale distributed queries of electronic health records using information content from continuity of care documents.
 * PopMedNet –Enables simple creation of distributed health data networks, and facilitates distributed queries of electronic health and claims data to support medical product safety, comparative effectiveness, quality, medical resource use, cost-effectiveness, and related studies. MDPHNet is a project that will combine PopMedNet with ESP, a clinical data model, for distributed queries of EHRs. []
 * ESP - The Electronic Medical Record Support for Public Health (ESP) project is an automated software application, which analyzes electronic medical record (EMR) data, to identify and report conditions of interest to public health and other agencies. []
 * Mini-Sentinel –a pilot project sponsored by the U.S. Food and Drug Administration (FDA) to inform and facilitate development of a fully operational active surveillance system, the Sentinel System, for monitoring the safety of FDA-regulated medical products. Mini-Sentinel is a part of the Sentinel Initiative, a multi-faceted effort by the FDA to develop a national electronic system that will complement existing methods of safety surveillance. Mini-Sentinel is a PopMedNet project. []
 * OMOP – Observational Medical Outcomes Partnership supports research into the methods for distributed analysis of healthcare databases to identify and evaluate safety and benefit issues of drugs on the market. []
 * DARTNet – The Distributed Ambulatory Research in Therapeutics Network links de-identified patient level data from EHRs, labs, imaging, pharmacy, and billing systems enabling a distributed query to return results on care and outcomes across a number of federated sites. []
 * caBIG® - The caBIG® mission is to develop a collaborative information network that accelerates the discovery of new approaches for the detection, diagnosis, treatment, and prevention of cancer. caBIG® is sponsored by the National Cancer Institute (NCI) and administered by the National Cancer Institute Center for Bioinformatics and Information Technology (NCI-CBIIT). Anyone can participate in caBIG® and there is no cost to join. The community includes Cancer Centers, other NCI-supported research endeavors, and a variety of federal, academic, not-for profit and industry organizations. https://cabig.nci.nih.gov/overview/
 * PCAST – President’s Council of Advisors on Science and Technology. Report to the President. Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward. December, 2010. []
 * International Society for Disease Surveillance Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance (http://www.syndromic.org/meaningfuluse/EDdata)
 * Universal Public Health Node (UPHN) -- ([|Query Health - UPHN Presentation)]

Appendix B: Glossary of Terms
Definition of Business Actors: Each business actor can play a number of roles which are defined in section 8.0 Actors and Roles.
 * **Business Actor** || **Definition** ||
 * Provider/Provider Organization || A Provider is
 * 1) Any supplier of a healthcare service;
 * 2) Healthcare Provider - Person or organization that furnishes bills, or is paid for healthcare in the normal course of business.

A Provider Organization is
 * 1) A structure of a provider;
 * 2) Discrete and accountable function or sub-function within an organization

Example: business unit includes a department, service or specialty of a healthcare provider organization. Providers and Provider organizations are covered entitites under HIPAA definition. ||
 * Intermediary (e.g. HIE, HISP) || The organizations that mobilize healthcare information electronically across organizations within a region, community or health system. An HIE is
 * 1) The organization enabling the sharing action between any two or more organizations with an executed business/legal arrangement that have deployed commonly agreed-upon technology with applied standards.
 * 2) HIO: An organization that oversees and governs the exchange of health-related information among organizations according to nationally recognized standards.

An HISP are entities that serve as a node on the National Health & Information Network to enable a private, secure and safe alternative method to send and receive sensitive health information or provide other services. When playing the role of data source an HIE/RHIO has a data repository (non-federated model). In this role the HIE/RHIO is a Business Associate of provider or provider organization under HIPAA definition. ||
 * Query & Results Reviewer || The actor that
 * 1) Reviews the initial query to assure that it is from authorized information requestor and within scope of agreements.
 * 2) Reviews and validates results before releasing the query results. This includes determination that results to be disclosed comply with all regulatory and data use agreements. In addition they’d also check to ensure no patient information is included as part of the results. ||
 * Information Requestor || The actor authorized and responsible for formulating and sending the query request and receiving and using query results response. ||
 * Registry (e.g. Societies, State Registries) || The actor associated with a registry service and registry data that stores patient information in specialized format, e.g., by disease category, for evaluating compliance to best practices, quality and utilization metrics. ||
 * Providers/Payors || The actors that are authorized to provide and use registry data for healthcare treatment, operations and payment. ||
 * **Cluster**: A “cluster” is multiple quality metrics for a single condition, (i.e. diabetes, hypertension, etc.) While this User Story focuses on diabetes the same approach can be used for other conditions.
 * **Galaxy**: A “galaxy” is multiple clusters for the same patient, i.e., diabetes, hypertension, lipids, CHF, etc.

Appendix C: Quality Measures/Data Elements of Interest for Expanded Analysis User Story
__Note__: //This table is meant to provide an example list of data elements that can be queried for within the Expanded Analysis User Story.// **// (For Reference Purposes Only) //** || NDFRT ||
 * **Quality Measures/Data Elements of Interest** || **Endorsement Body**  ||||||||||||  **Organizations/Recognizing Bodies that Develop or Define Quality Measures**  ||  **Applicable Terminology Standards**
 * ^  || **National Quality Forum (NQF)** || **American Medical Association (AMA) – Physician Consortium for Performance Improvement (PCPI)** || **Physician Quality Reporting System (PQRS)** || **Meaningful Use (MU)** || **National Committee for Quality Assurance(NCQA)** || **BTE** || **American Diabetes Association (ADA)** ||^   ||
 * HbA1c Poor Control > 9.0% || √  ||   ||  √  ||  √  ||  √  ||  √  ||   ||  LOINC  ||
 * HbA1c Control < 8.0% ||  ||   ||  √  ||  √  ||  √  ||  √  ||   ||  LOINC  ||
 * HbA1c Control < 7.0% || √  ||   ||  √  ||   ||  √  ||  √  ||  √  ||  LOINC  ||
 * Blood Pressure Control ≥ 140/90 mm Hg || √  ||   ||  √  ||  √  ||  √  ||  √  ||   ||  LOINC  ||
 * Blood Pressure Control < 130/80 mm Hg || √  ||   ||  √  ||   ||  √  ||  √  ||  √  ||  LOINC  ||
 * Eye Examination || √  ||  √  ||  √  ||  √  ||  √  ||  √  ||  √  ||  CPT  ||
 * Smoking Status ||  ||  √  ||   ||  √  ||  √  ||  √  ||  √  ||  TBD  ||
 * LDL Control ≥ 130 mg/dl || √  ||   ||   ||   ||   ||   ||   ||  LOINC  ||
 * LDL Control < 100 mg/dl ||  ||   ||  √  ||   ||  √  ||  √  ||   ||  LOINC  ||
 * Microalbumin (has it been done? Y/N) || √  ||   ||   ||   ||   ||   ||  √  ||  LOINC  ||
 * Microalbumin Poor Control > 30 micrograms/mg Creatinine ||  ||   ||   ||   ||   ||   ||  √  ||  LOINC  ||
 * Microalbumin Control < 30 micrograms/mg Creatinine ||  ||   ||   ||   ||   ||   ||  √  ||  LOINC  ||
 * Foot Examination || √  ||   ||  √  ||  √  ||  √  ||  √  ||  √  ||  CPT, SNOMED  ||
 * Medication Class ||  ||  √  ||   ||   ||   ||   ||   ||  RxNorm
 * BMI ≥ 25 ||  ||   ||   ||   ||   ||   ||  √  ||  LOINC  ||

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"