Challenge
The nation is reaching a critical mass of HealthIT systems (EHRs, Data Warehouses etc) that comply with data and vocabulary standards. The wide deployment of HealthIT systems has created unique opportunities for providers, provider support teams, healthcare professionals and organizations etc. to access and use the patient data that is already collected during clinical workflows. While the Health IT systems provide many access paths through their pre-defined interactions between a user and the system, they are limited in their support for data queries, APIs, or services to access data sets as needed. Where Health IT systems provide data access, they likely do not use industry standard access methods. Increasing support for this class of data access, using industry standards, would enable other applications to expand the ability of users to create value out of their data without having to rely on the predefined access paths. Allowing access to this data can enable a provider to further analyze the collected data to understand a patient’s overall health, the health of a provider’s collective patient population, and use the data to power innovative new applications and tools to take better care of patients and populations.
However accessing data from the HealthIT systems presents some challenges as outlined below:
- Who is accessing the data, why are they accessing the data and what are the challenges faced in accessing the data?
- Providers, healthcare professionals etc., want to access data within their own organization so that they can use additional care management tools appropriate for individual patient and groups of patients. The ability for providers and their clinical support staff to access their own data allows for the use of innovative new applications that can improve patient engagement and care.
- Providers, healthcare professionals etc., want to access data from external organizations visited by patients for specific healthcare needs. Accessing data from an external organization requires the appropriate authentication and authorization before data can be made available.
- Government agencies requiring access to data from various organizations to comply with laws and regulations.
- What are the types of data accesses that need to be supported? While there is a large spectrum of data granularity required based on the business requirements they can be abstracted using example dimensions represented in the table below. (Note: The Data Access mechanism dimension can keep extending depending on the types of information that the provider is trying to access, one example is accessing decision support information within a clinical workflow).
The table below highlights the complexity of the Data Access Framework by including sample Data Access Mechanisms and highlights the granularity of the data being accessed at both the Patient and Population level. For a definition of the various columns presented in the table, please refer to DAF Terminology.
- The challenge is to select appropriate mechanisms to access the data described in the above table in a uniform way both within an organization and from an external organization.
- While query concepts can be used to access the data, standardizing query mechanisms for the variety of data access needs presents a significant technical challenge.
- To add to the above challenges, Interoperable Implementation of Data Access Framework in the real-world will require selection of multiple standards across multiple layers. These standards can be visualized as a Query stack (Draft) as shown in the figure on the left hand side. The Query stack identifies the various layers for which standards would have to be selected and implemented. An example of an existing Data Access Framework using IHE XCA Query stack is also shown to aid the reader.
The Data Access Framework Initiative recognizes that solving the various challenges outlined above requires a Query stack that is composed of Modular and Substitutable standards.
- Modularity is the ability to keep the various layers of standards independent of each other. (e.g., Transport Layer standards should be independent of query structure standards which should be independent of query result standards).
- Substitutability is the ability to replace a particular standard without affecting the other layers of the query stack. (e.g., depending on the business requirements the query structure might be best represented using ebRIM/ebRS or HL7 FHIR or HL7 HQMF).
The goal for the initiative is to
- Enable Local and Targeted data access using the various data access mechanisms (document based, data element based, quality measure based, etc.)
- Identify privacy and other necessary metadata to enable the various data access mechanisms
- Modularize the query stack into modular layers (transport, query structure, query results, authentication, etc.) and allow for substitutability at each layer of the query stack. The extent of the modularity and substitutability that can be achieved will be determined by working with the community experts and experimenting with real-world technical feasibility.
- Identify the set of modular components and industry standards that should be assembled together as valid combinations to promote interoperability for the various business requirements of the community. Identifying the valid combinations to be used based on business requirements should address the community concern around substitutability leading to a large number of combinations which may not be interoperable.
Scope Statement
The Data Access Framework will be built incrementally by first focusing on Local Access via Intra-Organization query, Targeted Access via Inter-Organization query. Finally Multiple Data Source Access via Distributed Queries is a future goal but not-in-scope for this initiative. This incremental path and focus areas are shown in the figure below. 
The work of this initiative will be done in 2 phases:
- Phase 1 is focused on Local Access via Intra Organization Query
- Phase 2 is focused on Targeted Access via Inter Organization Query
The following capabilities are In-Scope:
- Identify the business and functional requirements for Local Access and Targeted Access.
- Define the modular layers for Data Access Framework to support identified business and functional requirements.
- Identify the existing standards that can be used for each layer of the Data Access Framework including guidance for substitutability of standards for both Local Access and Targeted Access.
- Identify the existing information models, vocabularies, terminologies from MU2 and other ONC initiatives that can be leveraged for defining the semantics for the DAF Initiative.
- Identify any metadata (including security, privacy and provenance) standards and vocabularies that can be leveraged for the DAF initiative.
- Define Implementation Guides leveraging existing standards where necessary to structure queries and query results for identified business and functional requirements.
- Identify standardized APIs that allow applications to query data in a consistent manner across HealthIT systems.
The following capabilities may influence the operational deployment of the standards selected by DAF, however they will not be addressed by the DAF initiative.
- Creating or modifying policies that allow queries to be executed within an organization or across organizations.
- These Policies include Trust establishment between organizations, any governance required, data use agreements, privacy laws, authorization policies related to data disclosure etc.
- Patient identity matching policies, matching rules and matching algorithms to identify patients and their related clinical data.
- Patient consent policies for query purposes which vary from organization to organization.
- Definition of new clinical domains, information models along with associated vocabularies and terminologies.
- Discovery of Query Service end points for Local Access or Targeted Access.
- Specifying standards for the inner workings of Health IT systems (e.g., EHRs might store data in multiple databases and may have to access this data to respond to a query. The exact mechanisms used by the EHR to store and retrieve their internal data will not be examined or standardized by the DAF initiative).
- Specifying access control policies or mechanisms that allow a Patient access to their own data.
- Specifying implementation technologies and programming languages to implement DAF.
Value Statement
The value of the Data Access Framework in the real world is the ability to use multiple modular and substitutable standards as necessary to implement sample scenarios listed in the table below.
Note - The Multiple Data Source Access scenarios in the table are examples of work done in the Query Health Initiative and are out of scope. These are just examples to demonstrate the applicability of Data Access Framework.
| Local Access via Intra-Organization Query | Targeted Access via Inter -Organization Query between two organizations | Multiple Data Source Access via Distributed Queries – Out of Scope |
| Access a Patient’s latest Clinical data using demographic information. | Access a Patient’s latest Clinical data from an external organization using demographic information. | Access a Patient’s latest Clinical data from multiple organizations using demographic information. |
| Access the list of all patients who have HbA1C > 8% over a period of time | Access lab results, medications from a recent encounter at an external organization for a patient who has HbA1C > 8%. | Determine the percentage of patients who have HbA1C > 8% among all diabetics across multiple organizations. |
| Allow clinical research/population analysis tools, and other 3rd party applications to function alongside the HealthIT systems (EHRs, Data Warehouses etc) by accessing the necessary patient or population data from the HealthIT system. | Access an EMR for a single patient’s longitudinal clinical information (ie. Allergies, medications, procedures, problem list across multiple encounters) | De novo queries for clinical research, quality measures, population health and analysis |
The above table is for example purposes only and does not convey actual work products. Appropriate Scenarios and User Stories to support this initiative will be further detailed during the Use Case and functional requirements phase with assistance from the community.
Target Outcomes
The target outcomes for the Data Access Framework Initiative include
- Empowering providers to manage their patients effectively across care settings by accessing the appropriate data required for treatment and care transitions.
- Allow innovative applications to provide value added functions by accessing data from the HealthIT system within an organization.
- Ability to use the Data Access Framework standards in a consistent way for meaningful use of health information technology.
- Leverage existing standards from IHE, HL7 and others to compose a modular and substitutable Data Access Framework and support standards in use by eHealth Exchange, EHR vendor communities, HIOs, RHIOs.
- Establish the incremental path that builds the necessary infrastructure to scale data access nationally.
- Improvement in provider experience and workflow for patient care and other purposes.
Strategic Alignment
The Data Access Framework will strategically align with
- HITPC and HITSC guidance on queries
- ONC Innovation community work
- Meaningful Use Stage 2 standards where applicable
- Industry work related to queries as appropriate.
- eHealth Exchange standards related to queries as appropriate.
- "EHR|HIE Interoperability Workgroup" work related to queries as appropriate.
- Existing standards from IHE and HL7
Timeline
The Data Access Framework Initiative timeline for the first 18 months is shown below. Slide one (1) illustrates the first 6 months; Slide two (2) illustrates months 7-12; Slide three illustrates months 13-18. The initiative timeline will be refined and adjusted as necessary.
Guiding Principles
To guide the Initiative across various phases we will:
- Leverage existing intellectual property, technology, and standards to create the Data Access Framework
- Allow Data Access Framework to be used and integrated into clinical workflows using APIs for Local Queries.
- Leverage internet technologies to enable national scale and performance
- Make decisions to promote modularity and substitutability while balancing complexity
- Leverage data captured during the routine course of patient care without adding new workflows or data capture requirements on the provider
- Align with other applicable ONC initiatives for standards across each of the Data Access Framework layers
Expected Deliverables
The specific deliverables for the project include
- Project Charter (this document)
- Use Case and Functional Requirements 1 – Local Access via Intra-Organizational Query
- Use Case and Functional Requirements 2 – Targeted Access via Inter-Organizational Query
- Project proposals to Standards Organizations
- Data Access Technical Framework and approach
- Identify/modify standards to support Local Access via Intra-Organization query
- Identify/modify standards to support Targeted Access via Inter-Organization query between organizations which may be using health information systems from same or multiple vendors.
- Implementation guides to support the implementation of use cases
- Demonstrate implementation of both Use Cases through successful pilots and obtain Pilot Feedback
Relevant Standards
The following are a list of candidate standards that have been identified for consideration across the various Data Access Framework layers. Other standards, as they are identified based on the business needs and requirements, will be included as part of the candidate standards analysis.
Relevant Stakeholders
| Stakeholders / Communities of Interest | Description |
| Individual Providers | 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 personnel involved in patient care. |
| Provider Organizations | Organizations that are engaged in or support the delivery of healthcare to include Hospitals, Ambulatory Centers, Provider Practices, Integrated Delivery Networks, Community Health Agencies and Rehabilitation Centers. |
| Query Thought Leaders | Organizations leading implementations of queries in the real-world. |
| Government Agencies | Federal, State, HIOs, Local agencies and other organizations implementing queries. |
| 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 systems |
| Health Information Exchange (HIE)/ Health Information Organization (HIO)* | HIE/HIO - Health Information Exchange (HIE) is defined as the mobilization of healthcare information electronically across organizations within a region, community or hospital system |
| Health IT Vendors – EHR/ EMR/ PHR/ Third party data receivers | Vendors which provide specific EHR/PHR solutions to clinicians such as software applications and software services. These suppliers may include developers, providers, resellers, operators, the innovation community, and others who may provide these or similar capabilities. |
| Other Healthcare Vendors | Vendors that provide health care solutions other than EHR/EMR/PHR solutions such as software applications and services. Examples include: integration vendors, data providers, medical device vendors, Release of Information (ROI) Vendors, RMMS (Remote Monitoring Management System) vendors, diagnostic imaging service provider, clinical order system supply vendor, transcription service vendors, clearinghouses, drug knowledge suppliers, network infrastructure provider, Clinical Decision Support (CDS) resource system, practice-based registry system suppliers, public health registry system, immunization information system providers, clinical genetic database/repository system vendor, etc. |
| Privacy and Security Experts | Consumer/patient and technology experts who represent the public's and organization interests for privacy and security. |
| Patients | Members of the public who receive healthcare services from ambulatory, emergency department, physician’s office, and/or a public health agency/department. While patient information is being exchanged as part of the eMDR, the patient is not a direct participant in this use case. |
| Patient Advocates | Patient advocates who act as liaisons between a patient, healthcare provider(s) and research institutions. |
| Beacon Communities | Selected communities of groups who have received federal funding through the ONC 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 health care spending. |
| Federal Agencies | Organizations within the federal government that deliver, regulate or provide funding for health and health care |
| Public Health Agencies | Public Health Agencies who query data for public health purposes and provide data for others to query. |
| 3rd Party Clinical Application Vendors | Vendors who provide innovative applications that supplement the EHRs, PHRs and other HealthIT systems and focus on improving patient care. |
| Healthcare Organizations | Healthcare Organizations who query data for various purposes and provide data for others to query. These organizations include specialty areas such as Behavioral Health organizations, Dental organizations, Cardiology, Radiology, Labs etc. The requirements for these specialty areas may vary depending on laws, regulations and other business workflow needs. |
Potential Risks
- Risk #1: Trying to address several interoperability problems in a single Initiative
- Mitigation: Constrain the use cases and requirements within a manageable scope so that readily available standards are leveraged.
- Risk #2: Projected timeline may not be achievable due to various reasons such as lack of community input, delays in achieving consensus on artifacts, and unavailability of relevant experience
- Mitigation: Work with community to refine timeline as the initiative progresses and adjust timelines as needed.
- Risk #3: EHR vendors have already implemented some query standards and may not have the availability to participate due to other priorities such as Meaningful Use
- Mitigation: Include support for existing standards so that vendors can reuse existing implementations.
- Risk #4: Modularity and Substitutability identifies too many combinations of how to access data many of which may not be used in the real-world.
- Mitigation: Identify the combinations based on the existing use cases and existing standards that are most likely to be adopted and implemented in the real-world.
- Risk #5: Ensuring potential Pilot Sites are identified and engaged throughout the initiative, so that the standards can be pilot tested in the real world
- Mitigation: Perform outreach and frequent communication, identify tangible Data Access Framework benefits to the potential pilot organization
- Mitigation: If the standards selected are already implemented and used in the real-world, then pilot feedback will be obtained from these real-world implementations.
- Risk #6: Vendors use a variety of other protocols and programming languages to access the query data
- Mitigation: Standards selected will be independent of programming languages and implementation technologies so that vendors can use their choice of programming languages and implementation technologies. In addition implementation guidance will provide the necessary context for vendors to implement the selected standards.
- Mitigation: Standards selected will be independent of programming languages and implementation technologies so that vendors can use their choice of programming languages and implementation technologies. In addition implementation guidance will provide the necessary context for vendors to implement the selected standards.
Project Charter Consensus
Please take a moment to review the final DAF Project Charter updates and dispositions.
DAF Members
<iframe width='450' height='400' frameborder='0' src='https://docs.google.com/spreadsheet/pub?key=0ApW4Ox66ml2IdGNnakN6UW5OTUhJUWctelVSZ3JMSWc&output=html&widget=true'></iframe> |