-
Notifications
You must be signed in to change notification settings - Fork 0
Inception User Stories
This is a summary of the user stories that are being planned to be part of the inception phase of the development for SCOOP. This phase marks the start of co-development between the Physician Data Collaborative and the SCOOP project.
These are documented as use case maps (the diagrams) and then written as features using the gherkin language.
In order to improve one's health and address illness
A patient should be able to
Seek care of a qualified health professional, who will document the care appropriately in their EMR.
Rationale
Activities of the network require the proper documentation in the EMR. While the goal of the network is not to cause unneeded work for the patients and or clinicians, there is a requirement to document. We may, over time, include documentation of specific information for specific studies / questions.
NOTE: We may, also, consider linking to a Personal Health Record. The use case map would look different for that and is not in scope at this time.
In order to perform research, evaluate practice, or perform QI on the network
A Questioner should be able to
Work with the members of the network to develop a suitable question (or questions) that can be encoded and executed on the network.
Rationale
Not all questions can be answered on the network - some will require other data and some are not suited to the quantitative approach we are taking. Other questions cannot be answered in their current form. Potentially suitable questions need to be reviewed, modified and approved by the network prior to encoding. We have begun to develop processes and templates to support this work through one of our sub projects.
Questions may come to the network to be reviewed in anticipation of a funding application, seeking feasibility assessment long before they potentially are run on the network.
There will be a set of supporting documents to help with this process, based on some of our current work.
In order to translate an approved research question into something that can be utilized by the network
A Network Question Manager should be able to
Encode the specified question in the Hub so it can be stored and later executed on the network.
Rationale
Research questions are not queries. Indeed a good research question will likely consist of a query set (see below). Researchers and questioners should not be expected to be able to encode a query from their question (although some questions will be very easy and some questioners will be able to encode their queries). Thus, we have considered this step a key element of moving from question to answer.
Feature: Manage Queries
In order to ensure the hub has the most appropriate set of queries that can be easily executed
A Network Question Manager should be able to
Manage the current stored and active queries on the hub, editing, removing and creating query sets (groups of related queries that should be run at an end point in sequence).
Rationale
Queries are able to be stored once encoded and can build up over time. There needs to be a set of administrative processes to support the management of queries on a hub. This could be very simple (e.g. stored files) or complex. Query sets are an important concept for the network.
A QUERY SET is a collection of related network queries that can be run as a batch. The set of queries provide a answer to a question and provide needed context to be able to interpret the answers returned. For example, a query set may also include some data quality queries to estimate quality of the answer.
In order to have the network answer a clinical question (research, QI, evaluation)
A Network Question Manager should be able to
Execute a valid query (or query set) from the hub so that it is distributed to the active end points and responses are returned and processed.
Rationale
Queries need to be executed on the network when a question is to be answered. This is separated out so that the same question (query / query set) could be re-run at multiple points over time.
In order to confirm that the query has sufficiently answered the question
A Network Question Manager and Questioner should be able to
Review the findings from a query / query set and determine if the question / queries
need to be revised or if the answer is sufficient.
Rationale
Query results may not properly answer the question - there may be issues with the translation of question to query or there may be data quality issues or the query results may trigger a refinement of the question itself. Indeed, we have seen this in practice in our early field work with questioners. So this user story captures the activities of answer review and question/query refinement. Some major changes to a question may require re-approval, but likely many will not.
In order to answer questions that are relevant within a practice
A Practitioner along with their Practice Question Manager should be able to
Develop, reuse and execute queries / query sets on their own endpoint to provide answers.
Rationale
One of the goals of the Physician Data Collaborative is to support local reflection as well as regional reflection. Thus, the local reflector allows for members of the practice to answer practice relevant questions. Queries from the hub should be reusable at the practice level. Finally, we have considered that local queries within a practice should be able to return patient lists (see .feature file). The rational for this last idea (which is very different than the what a network query through the Hub could do) is that there will be times when a network query generates a desire to act (e.g. if a query finds that there are patients on a contraindicated medication). The network cannot identify patients, but the practice should be able to rerun the query and get a list of patients that need to be recalled.
In order to answer questions with up to date information
The Practice should be able to
Update the data in the end point with any changed information from the EMR at regular intervals (e.g. nightly)
Rationale
The End Point data in the practice needs to be maintained so that current data is being queried by the network. The frequency of updates will be determined (e.g. nightly, weekly) and this activity should not impact the performance of the practice.
In order to ensure the network is up to date,
The Network Question Manager (guided by Network Governance) should be able to
Update users, review and report on audit logs, and manage end point connections.
Rationale
There needs to be mechanisms for managing the network, providing appropriate review of audit logs and reviewing / maintaining end point connections.
In order to ensure a practice's end point is working and appropriately connected to the right hub(s),
The Practice Question Manager (guided by the practice) should be able to
Review the end point, updating users, reviewing audit logs, review questions answered and the answers, and manage hub connections.
Rationale
Just like the network itself needs to be managed, so does the end point. This provides the practice with a key level of control. They can remove themselves from a network, confirm what questions have been asked, etc.
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