-
Notifications
You must be signed in to change notification settings - Fork 0
Principles
These are working principles, meant to guide, be discussed, and be revised as we learn and as the community contributes to the goals and directions of SCOOP. They are meant to serve as useful guideposts while making decisions on architecture and design.
- Patient data does not leave the control of the practitioner.
- Practitioners opt in to questions.
- Patients opt in or opt out of questions, depending on the question / method.
- SCOOP will support multiple questioners on the network.
- Data will come from multiple EMRs
- Questions will be answered from routinely collected data wherever possible.
- We do not know all the questions we will ask.
- The network will support a variety of question and study types relevant to primary care.
- The network will support participants in personal practice reflection and action.
- Privacy and security are ensured through software design.
Following from these principles, some design elements are worth highlighting:
- Data Quality is managed in the practice but can be monitored centrally.
- Network participants will control how much they engage with the network.
- SCOOP design supports multiple trust networks that will co-exist and will include research networks as well as quality improvement networks.
One of the elements we heard from practitioners to feel more comfortable with engaging in a study network was that many would insist that patient data stays under their control. This also meant de-identified data did not leave control of the practitioner.
Practitioners would want control to review all questions: their source, what they are asking and possibly even the answers before they decide to share. Over time, we imagine, trust would develop and there would be a need to opt in to a series of questions or to trust the questioner for any question.
For basic, observational questions -- where the question is answered using only data routinely collected and there is no intervention -- patients would need to opt out. That is they would be informed (e.g. through posters) that a practice was part of SCOOP and could ask to be excluded from any and all questions. For other prospective questions that require specific interventions, of course informed consent and opt in is needed.
From the questioner side, we understood that there would be a need for multiple questioners. This could be handled through process or through the system design. We intend to handle this in the design to that multiple questioning networks could leverage the same infrastructure.
We are not designing SCOOP to be focused on a single EMR product, rather, the design will allow the capability for multiple EMR products to connect their own end points. This results in additional design complexity, but will allow more practitioners to engage over time.
To reduce the burden of engagement in answering questions, routinely collected EMR data will be used. That is, the documentation in the EMR that occurs as part of routine care (e.g. prescriptions) will be used to answer questions rather than having specific data capture tools that replicate that data solely for study purposes.
A core data set will be developed and presented in a standardized manner so questions can be asked from multiple EMRs.
Unlike many individual projects where the question is known, as this is an evolving network, we do not know all the questions we will ask over time. Therefore, careful attention must be made to the design of the system to try to include multiple question types. Range of likely data elements needs to be standardized to support likely types of questions. Still, the data models will need to be extensible to accommodate specific questions in the future.
Primary care is broad and the types of questions that need to be asked are also broad. SCOOP should support a range of question and study types - many but not all - that are relevant to primary care. Observational studies using data contained the EMR will, of course, be the "bread and butter" studies. In office intervention studies will also be supported. Given some of the other design principles, some studies will be hard to accomplish using the SCOOP infrastructure. A key gap will be linked studies - where SCOOP data is linked to other data sources.
The same components that support questioning across a network can also support an individual reflecting on their own practice population. These features currently are supported in many EMRs today. However, the SCOOP design may provide several benefits:
- Using the SCOOP components does not impact the EMR performance.
- A range of questions may be asked in SCOOP that are not easily available from the EMR.
- SCOOP network questions can be shared to practices and replicated locally.
One key difference of local questions is that they CAN get patient identifiable data for quality improvement activities from their local data source. Thus, one of the key benefits of this approach is that a practitioner in a quality improvement network can comfortably contribute without sharing patient data and then, if there is an activity that needs clinical action (e.g. patients on a medication that is contraindicated) the practitioner can reuse the question in their office to discover WHO needs to be called in. This is not disclosure of data.
Many of the elements above relate to ensuring control of the patient data is maintained in the hands of the practitioner. Further design work will be done to ensure that the network components limit risk of exposure. The details of this work will be described in detail in other documents.
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