Workgroups



This Week's Agenda




Who's Tweeting about QH?




How to Get Involved

  • Keep me Informed
    • To be notified about significant events and announcements from the project, follow this site
  • How can I contribute?
  • Add my organization as an official member

Edit SidebarRight

Edit PageTabs

QHhome.pngQH_Launch_Blue.pngQHcharter.pngQHimplementationgroup.pngOperations_WG.pngQHclinical_HL.png

QHtechnical.pngQHsignup.pngQHwikispaces.pngQHsummerconcert.pngQHinthenews.pngQHreference.jpg

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.



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.

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.
Pilot Implementations.
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
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.
Support Pilot implementations.
Support for definition of SDO independent CIM, ‘Query’, and ‘Return Results’ Standards.
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.
Table 1: Key Stakeholder Groups for the Query Health Initiative.

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.
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.
Table 2: Communities of Interest

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[1] , Query Request Receiver, Network Data Partner,[2] Information Collector/Combiner
Intermediary (e.g. HIE, HISP)[3]
Health IT System
Data Source[4] /Aggregator, Query Request Receiver, Network Data Partner, Information Collector/Combiner
Query & Results Reviewer [5]
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


.QH_Use_Case_Diagram_11-7-11.jpg


Figure 1. Query Health Use Case Diagram

ContextDiagram_v01.png
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

Business Actor
System
Role
Provider/Provider Organization
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
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
Table 4: Expanded Analysis User Story Actors and Roles

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.


ExampleResultSet_ConsensusApproved_111611.png

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.


QH_Activity_Diagram_11-15-11.jpg
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


QH_Sequence_Diagram_11-7-11.jpg

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

Initiating System

Information Interchange Requirement Name

Receiving System
Information Requestor Information System
Distribute[6]
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
*Query response will most likely be results but it can also include errors or rejections.
Table 7. Information Interchange Requirements

13.2 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
Table 8. System Requirements

13.3 Defining the Metadata

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
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


Table 9. Envelope Metadata - Query Request

13.3.2 Envelope Metadata - Query Response

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 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


Table 10. Envelope Metadata - Query Response

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.**[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

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

Table 11. Standardized Computable Data Elements

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.

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
Diagnosis Status (Inactive or Active)
Obtain total counts for patients that have identified Diabetes diagnosis codes
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:

  • 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

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. http://laika.sourceforge.net/
  • 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. http://projectpophealth.org/
  • 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. http://www.popmednet.org/Home.aspx
  • 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. http://esphealth.org/redmine/
  • 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. http://mini-sentinel.org/
  • 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. http://omop.fnih.org/
  • 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. http://www.cina-us.com/DARTNet_AIM_092009.pdf
  • 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. http://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf
  • 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.
Quality Measures/Data Elements of Interest
Endorsement Body
Organizations/Recognizing Bodies that Develop or Define Quality Measures
Applicable Terminology Standards
(For Reference Purposes Only)
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
NDFRT
BMI ≥ 25







LOINC



  1. ^ When playing the role of the aggregator, a provider/provider organization would use their electronic health record system to automatically pull together the information necessary for the query result.
  2. ^ Network Data Partner: Combines aggregated data from multiple data sources and sends the combined data to the Information Requestor
  3. ^ If queries repeatedly run over a period of time or requesting information over a period of time require individually identifiable data, Intermediaries must be business associates of any data holder contributing to the query under HIPAA.
  4. ^ HIE's playing the role of data source is optional and dependent on the context of the User Story.
  5. ^ Only used in the event that more than one Intermediary is required to complete query.
  6. ^ Distribute is a special form of send in which one sender sends to multiple receivers.