Use Case Template

advertisement
Semantic-E-Science Assignment 2
Hithika Chhaochharia
RCS ID: chhaoh
Question 1:
The application area that I chose is HealthCare Sciences. The use case deals with recording and
updating patient’s health data that can be monitored by the doctor to encourage a health life-style.
The information is recorded into an electronic health record which updates a portal that is maintained.
As of 2000 at least 171 million people worldwide suffer from diabetes, or 2.8% of the population. Type
2 diabetes is by far the most common, affecting 90 to 95% of the U.S. diabetes population.
This particular use case is developed with the following things in mind:
a. It would be an interactive way to keep check on a patient’s health for the doctor.
b. It would keep the patient aware about his own health and medication.
c. This would eventually help in reducing the number of cases of diabetes.
Question 2:
Use Case Name: Collaborative Health Tracker
Point of Contact Name: Hithika Chhaochharia
Use Case Name
Give a short descriptive name for the use case to serve as a unique identifier. Consider goal-driven use case name.
Collaborative Health Tracker is a web portal that helps a patient and his doctor to monitor the
patient’s health.
Goal
The goal briefly describes what the user intends to achieve with this use case.
Patient and physician develop plan and track progress toward healthy living style using a
collaborative health information system.
Summary
Give a summary of the use case to capture the essence of the use case (no longer than a page). It provides a quick overview and includes the goal
and principal actor.
Patient exhibits symptoms of diabetes (but does not know that it is diabetes and has never heard of
WebMD) and visits physician to find out why he is exhibiting these symptoms and what can be
done in order to return to a healthy lifestyle. Doctor retrieves health records from his electronic
medical record, information from the patient's personal health records (e.g. weight measured every
morning), and blood glucose readings from a nutritionist the patient has been seeing for diet
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
1
advice. The weight and glucose levels indicate that the patient may be suffering pre-diabetic
symptoms and the doctor advises that the patient reduce his weight and blood glucose to normal
levels (indicated by a range of weight/blood glucose readings). He sets these suggested limits in
the collaborative system and gives the patient a blood glucose device to track glucose levels from
home. The patient tracks these items every morning in an attempt to reach the goals set by the
doctor, using a web-enabled device to enter information.
Actors
List actors, people or things outside the system that either acts on the system (primary actors) or is acted on by the system (secondary actors).
Primary actors are ones that invoke the use case and benefit from the result. Identify sensors, models, portals and relevant data resources. Identify
the primary actor and briefly describe role.
Primary Actor(s)

Physician

Patient
Secondary Actors(s)

Physician's record system

Patient's personal health records

Patient's web browser

Patient's data measurement devices (e.g. scale, blood glucose meter)

Nutritionist record system
Preconditions
Here we state any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about
other systems can also be stated here, for example, weather conditions. List all preconditions.

Patient exhibits symptoms

Patient has method of recording blood glucose

Patient has recorded health data in PHR system

Patient's nutritionist has recorded sugar levels in nutrition system
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
2
Triggers
Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They
can be single events or when a set of conditions are met, List all triggers and relationships.

Patient exhibits symptoms and visits doctor, informs him of nutritionist.
Basic Flow
Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to
follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the
document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required)
1. Doctor uses system to retrieve health records: local, patient's personal record, and
nutritionist's record.
2. Doctor performs tests. Test results are entered into record system.
3. Identifying the case as pre-diabetes, the doctor sets goals for weight and blood glucose
levels for the patient and annotates the recommendation with potential changes in diet and
activity levels.
4. Patient, at home, takes measurements of weight and blood glucose regularly and enters
information into his health record system, which in turn renders history of weight and
glucose and compares it to limits imposed by the doctor.
5. After a month, the patient returns for a checkup and has succeeded in reaching the goals
encoded in the system and the symptoms are no longer presenting.
Alternate Flow
Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow.
1. Patient unable (or unwilling) to make blood glucose measurements himself, so he hires a
home healthcare nurse to visit him and take the measurements at his home. The nurse
enters these data into her employer's EMR system (which, WLOG is not affiliated with the
doctor's EMR system).
2. Patient returns for checkup. System retrieves measurements from 3rd party EMR system.
Post Conditions
Here we give any conditions that will be true of the state of the system after the use case has been completed.
1. System(s) contains goals and history of measurements recording the patient obtaining those
health goals.
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
3
Activity Diagram
Here a diagram is given to show the flow of events that surrounds the use case. It might be that text is a more useful way of describing the use case.
However often a picture speaks a 1000 words.
Notes
There is always some piece of information that is required that has no other place to go. This is the place for that information.
EMR - Electronic Medical Record
PHR - Personal Health Record
BG - Blood Glucose
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
4
Resources
In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured.
These resources include data and services, and the systems that offer them. This section will call out examples of these
resources.
Data:
Data
Type
Characteristics Description
Owner
Source System
(dataset
name)
Remote,
e.g. – no cloud
cover
Short description of the
dataset, possibly including
rationale of the usage
characteristics
USGS,
ESA, etc.
Name of the system
which supports
discovery and
access
Electronic
Health
Record
EHR has the health
information of the
patient
Patient,
Blood Glucose
Portal
Electronic
Medical
Record
Has all the medical
information of the
patient
Nurse
In situ,
Etc.
Doctor
Modeling Services
Model
(model
name)
Owner
Description
Consumes
Frequency
Source System
Organization
that offers the
model
Short
description of
the model
List of data consumed
How often
the model
runs
Name of the
system which
offers access to the
model
Event Notification Services
Event
Owner
Description
Subscription
Source System
(Event
name)
Organization
that offers the
event
Short description of the event
List of subscriptions
(and owners)
Name of the system
which offers this
event
Application Services
Application
Owner
Description
Source System
(Application
name)
Organization
that offers the
Application
Short description of the application portal
Name of the system
which offers access to
this resource
Helps in electronic monitoring of
patient’s health
Web Browser
Blood
Glucose
Portal
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
5
Other resources
Resource Owner
Description
Availability
Source System
(sensor
name)
Short description of the resource
How often the
resource is available
Name of system
which provides
resource
Organization
that owns/
manages
resource
Question 3:
The field of healthcare data is a large and complex one. For years the system has been a manila folder
on a shelf or in a cabinet in a doctor’s office. This leads to high information uncertainty since the
patient only has the opportunity to see their health record when in the doctor’s office and even when
present rarely gets a glimpse of the file of data about them.
This use case involves the patient by allowing them to contribute their own data to their health record
by means of a locally stored Personal Health Record. This allows the patient to contribute without
having direct access to the totality of their data.
The design flows naturally from the use case. The patient is allowed to keep a local (at least more local
than the doctor’s office) Personal Health Record. Reducing the patient’s uncertainty of a portion of
their health record is paramount and easily achieved.
The patient would have a nutrition record that would be uploaded to the portal.
The patient also updates his health record which is again uploaded to the portal.
The physician can access this portal and monitor the patient’s health regularly by checking whether the
patient is following the procedures or medicines he was prescribed.
CMap Ontology:
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
6
Question 4:
a. The physician wants to know if there is any spike or dip in a patient’s blood glucose
level.
The use case makes it possible for the physician to check a patient’s glucose levels
without actually asking the patient to come in every week. This would help the
physician decide whether the medication should be changed or and other procedures
should be prescribed.
b. The physician wants to see if the patient is following the weekly prescribed diet and
medication.
The use case makes it possible for the physician to check and monitor closely the
patient’s weekly activities regarding diet and medication. So the physician will not need
to ask the patient to update him every time they meet for a check-up, since all the
information will already be available on the portal and the patient will not need to
recollect it.
UseCase- -Template
http://en.wikipedia.org/wiki/Use_cases#Use_case_templates
7
Download