METODOLOGÍA DE LA INVESTIGACIÓN
Módulo 3 sobre EdC 10 Creencias sobre cuestiones ligadas a la
4.3.5 Sistemática de contexto para AdC
Figure 3-13 Use case diagram Top Level
91
3.12.5.1 Request Treatment Use Case
Table 3-3 Use Case for Requesting Treatment Use Case Name: Request treatment
Goal in Context To enable the patient to seek and receive treatment in a timely manner
Scope WeCare® system
Level Primary task
Preconditions 1. Patient seeks out for health care
2. Patient is pre-registered with the system 3. Patient is able to access the health system Success End Condition Patient receives diagnostic information or receives an
appointment for the earliest opportunity to meet care provider.
Failed End Condition Patient fails to receive any immediate attention or assistance
Actor: Patient
Trigger: Patient requests for help
Scenario Description: 1. Performs verification of patient, account and historical information
2. Performs immediate data collection from device 3. Solicit additional inputs/data from patient
4. Create user incident portfolio
5. System receives notification of request 6. System performs resolutions of request 7. Primary care facility availability
8. On-call provider availability 9. Closest and most timely facility
10. Contracture agreement with patient insurance 11. Present selection to patient
12. Submitting portfolio for incident review and monitoring 13. Perform possible care-giver to patient pairing for
immediate assistance if needed
14. Perform care-giver to patient assignment for next possible appointment.
Extensions 1. Select patient from the user data store 2. Service user account
3. Route prescription to the nearest pharmacy 4. Geo-reference and correlate similar symptoms for
possible common cause
5. Event classification to aid diagnosis.
Exceptions:
92
Figure 3-14 Use Case Diagram Request Treatment
3.12.5.2 Sensor Data Collection Use Case
Table 3-4 Use Case for Sensor Data Collection Use Case Name: Sensor data collection
Goal in Context Enables the (wearable or issued) sensors to send data to the sensor data store based on a patient’s profile. It also enables the sensor to receive commands from the data store.
Scope Software/hardware data interfaces and data store.
Level Primary task
Preconditions 1. Sensor is network enabled
2. Standard sensor data interface is established 3. Sensor data store is accessible
Success End Condition Sensor is able to communicate successfully with the data store.
Failed End Condition Sensor is unable to communicate with data store
Actor: Sensor
93
Trigger: Sensor pushes data to the data store Scenario Description: 1. Associate a sensor with user
2. Monitor the user health condition
3. Generate digital signature to ensure integrity 4. Transmit the measurement data based on patient’s
condition
5. Schedule transmission based on device resource 6. Check for data integrity and data error
7. Associate raw measurement data to system user Extensions 1. Sensor to patient registration and assignment
2. Sensor management 3. Sensor tasking
4. Remote sensor data pulling
5. Persistent data storage and management Exceptions: Improper use of the device
Figure 3-15 Use case diagram Sensor Data Collection
3.12.5.3 Sensor Device Registration Use Case
94
Table 3-5 Use Case for Sensor Registration Use Case Name: Sensor Device Registration
Goal in Context Establish an authentication and authorization profile for a sensor device to associate it with a user/clinic/municipal profile.
Scope Account Services
Level Top Level
Preconditions 1. Sensor has network connectivity with WeCare® system 2. Authorization and Authentication Services are online 3. User/Care Provider has an active account with
WeCare®
Success End Condition Device is registered with the system Device can submit data for consumption Failed End Condition Device registration failed
Device will not authenticate with system Device cannot upload data
Actors: Individual Users/Clinic and Municipal IT Administrators Trigger: User desire to utilize data from new sensor
Scenario Description: 1. User logs onto the system 2. User access account profile 3. User edits device list
4. System prompts user for device registration information
5. System validates connectivity with device 6. User saves device in personal profile.
Extensions 1. User makes device available as a municipal/clinic device
2. User replaces existing device with new device Exceptions 1. Sensor device not recognized by the system
2. Sensor device does not support interface with WeCare®
3. User does not have account/account privileges to register a new device
95
Figure 3-16 Use case diagram - Sensor Device Registration
3.12.5.4 Provider Collaboration Use Case
Table 3-6 Use Case for Provider Collaboration Use Case Name: Provider Collaboration
Goal in Context Enable the health care provider to perform collaborative diagnostics.
Scope Data stores and Knowledge management
Level Primary task
Preconditions 1. Collaborative network of providers have been established within the ecology.
2. Patient requests service
3. Available sensor data has been collected
4. Care provider has been notified of the patient request 5. Care provider is unable to provide resource to the
request and needs further consultations.
6. Case has been marked for consultation.
Success End Condition Patient receives diagnostics and/or treatment plane Failed End Condition Patient is unable to receive information.
Actors: Care Providers
Trigger: System notifies provider of request for care.
96
Scenario Description: 1. Provider logs on the system
2. Provider opens the patient portfolio 3. System presents patient information 4. Historical information
5. Sensor monitoring information 6. Latest request information 7. Possible causes* and symptoms 8. Direct link to medical library
9. Provider requests collaboration/Consultation 10. Within network
11. Within community 12. Within specialty
13. Provider performs collaboration with colleagues.
14. Provider performs diagnosis 15. Patient receives care
Extensions 1. Provider receives collaboration request/consultation 2. Provider accepts request for collaboration
3. Remote collaboration session management Exceptions: 1. Provider declines requests for patient case
2. Provider declines requests for collaboration
97
Figure 3-17 Use Case Diagram Provider Collaboration
3.12.5.5 Knowledge Distribution Collaboration Use Case
Table 3-7 Use Case for Knowledge Distribution Use Case Name: Knowledge distributionGoal in Context This is an enabler that facilitates information sharing and knowledge distribution.
Scope Knowledge management
Level Primary task
Preconditions 1. System has data stores for sensor data, patient information, diagnostics information and resource constrains.
2. System creates customized information to distribute to individual user.
3. Internal criteria for distribution has been met, for example:
4. Notification to patient of environmental factor (pollen)
98
that could cause allergic reaction 5. Notification of appointment 6. Notification of doctor assignment 7. Notification of sensor information 8. Notification of prescriptions
9. Notification of health monitoring information Success End Condition Patient receives notification
Failed End Condition Patient fails to receive notification
Actor: Patient
Trigger: New assignment from the knowledge center Scenario Description: 1. Notify patient of appointment
2. Knowledge subsystem performs primary physician availability check using data from clinic data store.
3. Knowledge subsystem performs match based on symptoms
4. Knowledge subsystem performs resource de-confliction
5. Knowledge subsystem performs de-confliction using similar criteria using a certain radius from patient location across multiple clinic data stores.
6. Notify patient of the top 3 choices
7. Notify patient of environmental condition
8. Sensor data store correlates environmental conditions with weather feeds.
9. Analytic subsystem performs modeling of possible plums
10. Knowledge subsystem uses data from the sensor data store, analytics and patient data store to create possible effected users within the system.
11. Notify users of possible impacts.
Extensions Exceptions: