-
Notifications
You must be signed in to change notification settings - Fork 0
Overview
To be successful, quality improvement and practice based research both require measurement. To improve care delivered we, in primary care, need to be able to answer practice relevant questions. EMRs have the potential to support the rapid answering of reflective questions; however, they are often not designed for this. Further, they are not designed to support reflection questioning across groups of practices. Without an infrastructure to support data collection and analysis, considerable effort is required to answer each question. Often this effort is too much and questions go unanswered.
Several networks (QI and research networks) provide an infrastructure to do this by aggregating data. However, many providers want to ensure their data and their patients' data are kept under their control.
This project seeks to develop an infrastructure to support networks to answer questions while keeping data in the control of the providers.
Primary care in Canada has been undergoing a series of changes over the past years with the goals of: improving quality of care to patients, to better support care of the population, and to do so in a sustainable manner. However, measurement of the changes has been challenging due, in part, to the effort required to properly measure impact of change.
The same issue is true in primary care research: it is often difficult to collect data to answer primary care questions from primary care settings.
Many provider groups around the world have set themselves up as networks in order to measure improvements and answer clinically relevant questions. With the increasing availability of Electronic Medical Records (EMRs), more primary care data is available in an electronic form. There is the potential to leverage this to answer questions and make networks more responsive and provide more feedback to quality improvement activities and to generate new knowledge.
There are hundreds of EMR users in BC and very few are connected together to support answering of clinical questions outside of their own practice. This project seeks to develop the infrastructure to support EMR enabled practices to connect together to help answer clinically relevant questions.
The current gold standard approach is to de-identify patient and provider data and collect information in a data warehouse. This allows for members of the network to work with the data as a single entity and manage data quality, querying, etc centrally without impacting the practice on a day to day basis.
Some examples of where this approach is taken include:
- CPCSSN
- CIHI’s VRS
- DELPHI Network (Ontario)
- NorTreN (Ontario)
- TayRen (Scotland)
- Pegasys (New Zealand)
Some groups, with the appropriate legislation and processes extract patient identifiable data. ICES’ EMRALD and some integrated health providers (e.g. HMOs in the US, Health Authorities) take this approach. The key advantage to this approach is that the data can be easily linked to other data sets such as hospital admission data.
Other groups have chosen not to aggregate data. AMCARE in BC is a tool developed to receive indicators from the MOIS EMR and securely compare those indicators. AMCARE was developed to answer a specific set of indictors and relies heavily on MOIS to do the analysis work. This is successful as the two products are closely linked. Two Harvard based open-source projects, HQuery and PopMedNet, are also taking a distributed data approach. These two, combined, are very interesting to us as they provide some flexibility in questions and in data. They are not built for primary care.
One of the concerns raised by BC physicians and others is the pooling of data, even de-identified data. Physicians are more comfortable if their and their patient data resides under their control. By ensuring that the data never leaves their control, we expect more physicians will be interested in participating.
As described, this approach will ensure that the data never leaves the control of the physician while providing much of the flexibility of a de-identified data warehouse. Further, individual practices will have the ability to decide which questions they want to participate in answering. Thus, we ensure that practitioners “vote with their feet” such that they decide what they want to participate in. This is a common success criteria for collaborative networks. We are ensuring that this is built into the infrastructure and not just the processes. We believe this will be a new approach that will become the gold standard in the future.
Traditional warehouse approach allows researchers to clean-up data after it has left the practice. This cleanup process allows a certain amount of standardization of data quality. At the end all of the data from different sources should be of consistent quality. In this new approach, practice data is a “black box” from the network perspective. So new ways need to be developed to evaluate the quality and consistency of data across practices.
In the new approach, data quality transformation (i.e. data cleanup) will be the responsibility of the practices. It will require effort and/or cost to the practice. Although, this may not exceed the cost of joining a traditional data warehouse-based research network.
This project supports practitioners and groups of practitioners to engage in reflective practice. it does so by leveraging the use of standardized EMR data across multiple practices while the patient data stays in the control of the practice. A secure network hub can ask questions of the practices with sufficient rigor to support quality improvement and research.
This project will develop the infrastructure needed for networking EMR practices together to robustly answer a range of clinical questions without data leaving the control of the provider.
- Reusable set of components that can be used to connect EMR practices into a question answering network.
- Infrastructure can support multiple sub-networks asking different questions.
- Infrastructure will work with existing standards.
- Infrastructure will be secure and trustworthy.
Additional project documentation will be available online. It includes:
- Example Questions
- Architectural Design
- User Stories and Use Cases
- Iteration Plan
This project will develop the tools needed to deploy a network that connects EMR based practices to answer a range of clinically relevant questions. It will build / adapt and test four components:
- EMR Adaptor that connects and EMR to the Endpoint, converting data as needed to a standardized format.
- Endpoint that contains a replicated subset of the EMR data that will be used for analysis and resides under the provider's control. The endpoint will provide a user interface so that the provider can review who would like to ask questions of the data (without data being released) and will handle querying of the data and summarizing answers that are shared with the network.
- Local Reflector that will allow the practitioner to question their own end point.
- Network Hub that allows question managers to encode questions, distribute them to endpoints, and aggregate responses.
The project will leverage data standards and other existing projects and extend these. It will not build its own data standards. For testing purposes, the project will work with 2 EMR products to ensure the EMR adaptor is capable of extending beyond one product.
We want to focus on the development of the core components of the network, including initial adoption in early sites as part of the iterative development and testing process. The broader roll out will be the scope of an implementation group.
<td valign="top">
<strong>Out of Scope</strong>
</td>
<td valign="top">
Build tools from scratch.
</td>
<td valign="top">
Develop a new comprehensive data dictionary / model for extracting and representing EMR data for analysis purposes.
</td>
<td valign="top">
</td>
<td valign="top">
</td>
<td valign="top">
</td>
<td valign="top">
</td>
<td valign="top">
Deploy to all EMRs enabled practices in BC
</td>
In Scope |
Adapt existing distributed network tools to the context of ambulatory / primary care network |
Build one EMR Adaptor using the BC EMR2EMR specification |
Build Endpoint such that it can serve as a secure, practice level repository |
Build a Network Hub that can manage the question answering process and securely connect to Endpoints in the network. |
Configure the tools to support rapid feedback an analysis of questions asked in the network. |
Develop sufficient documentation to support implementers deploy the products AND develop appropriate questions (including how to assess relevant metadata to help interpret answers). |
Deploy the network to test practices to ensure that the system is functional and robust. |
-
Three Components:
-
EMR Adaptor
-
Endpoint
-
Network Hub
-
Development of documentation and processes related to how to ask questions; modeling questions, and managing the question answering activities.
-
Deployment within a group of practices using the one EMR product.
- EMR Standards and EMR Data Quality (in practices) are not robust enough to support answering of clinically relevant questions.
- Capacity for collaboration of EMR vendors may be limited to work on a project such as this.
- Practices may not be willing to engage in activities needed to test and participate in the network.
If we accomplish the elements of our plan, we will have a reusable infrastructure that can be used for a variety of purposes related to practice reflection, quality improvement, and research. The tools will be available to multiple interested groups
SCOOP is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
- SCOOP Overall Design
- SCOOP Actors
- User Stories and Use Case Maps
- System Architecture
- Development Process
- Prototypical Questions
- Current Meds vs Med List
- Data Enrichment Design
- Data Visualization
- Deployment Architecture
- EMR-2-EMR (E2E)
- OSCAR Setup
- Gateway & Hub Setup
- OSCAR Development Notes
- OSCAR DB Table Notes
- Coding Standards
- Mongodb Notes
- Server Configuration
- PDC Gateway Server
- Iteration Overview
- Feature List
- Architecture
- Requirements
- Visualization Requirements
- Test Specification