iTrust Medical Care Requirements Specification

Version 18
October 14, 2009

Project Team:
You
Your Partner/Team

Document Authors:
Laurie Williams
Tao Xie
Andy Meneely
Lauren Hayward

Return to iTrust Homepage

This project involves the development of an application through which doctors can obtain and share essential patient information and can view aggregate patient data. Currently, access to a patient's history regarding previous medical problems, previous surgery, medications, allergies and other factors is often difficult or obtainable only from a patient's recollection. Now, as more hospitals and doctor's offices are automated, this information is available electronically. However, it is not accessible by other doctors, and is often only viewed through some proprietary software so it can not be shared.

The final product is a site where health care workers can access important patient information, the non-emergency access can be controlled, and all access would be tracked. Security and privacy of such a system is of paramount importance. HIPAA rules protect patients' information and also allow a patient to dictate who can access this information.

Approved diagnostic information: The set of diagnostic information a patient allows a designated or other licensed health care professional to view. A patient is only given the choice to restrict viewing on selected diagnostic information, such as those related to mental illness, substance abuse, and cosmetic surgery. The licensed health care professional making a diagnosis determines if a patient is granted the ability to restrict viewing of the diagnosis. For the diagnostic information which a patient can restrict viewing, he or she can choose to enable designated licensed health care professionals, and/or other licensed health care professionals, and/or no one.

• Health Care Personnel (HCP): All of designated licensed health care professionals, licensed health care professionals, and unlicensed authorized personnel, as defined below.

There are eight roles in the iTrust Medical Records system. The role of a user determines their viewing and editing capabilities (role-based access control).

• Patient: When an American infant is born or a foreigner requests medical care, each is assigned a medical identification number and password. Then, this person's electronic records are accessible via the iTrust Medical Records system.
• Administrator: The administrator assigns medical identification numbers and passwords to LHCPs. [Note: for simplicity of the project, an administrator is added by directly entering the administrator into the database by an administrator that has access to the database.]
• Licensed Health Care Professional (LHCP): A licensed health care professional that is allowed by a particular patient to view all approved medical records. In general, a patient does not know this non-designated health care professional, such as an emergency room doctor, and the set of approved records may be smaller than that granted to a designated licensed health care professional.
• Designated Licensed Health Care Professional (DLHCP): A licensed health care professional that is allowed by a particular patient to view all approved medical records. Any LHCP can be a DLHCP to some patients (with whom he/she has an established relationship) and an LHCP to others (whom he/she has never/rarely seen before).
• Emergency Responder (ER): Police, Fire, Emergency Medical Technicians (EMTs), and other medically trained emergency responders who provide care while at, or in transport from, the site of an emergency. [referred to as “on site care providers” by Department of Health and Human Services Emergency Responder Electronic Health Record Use Case http://www.dhhs.gov/healthit/usecases/documents/EmergencyRespEHRUseCase.pdf]
• Unlicensed Authorized Personnel (UAP): A health care worker such as a medical secretary, laboratory technician, case manager, care coordinator, or other authorized clerical-type personnel. An unlicensed personnel can enter and edit demographic information, diagnosis, office visit notes and other medical information, and can view records.
• Software Tester: An information technology worker who tests the iTrust Medical Records system. Of particular interest to the software tester is the operational profile information which informs him/her of the frequency of use of the features of the system.
• Personal Representative: A person legally authorized to make health care decisions on an individual's behalf or to act for a deceased individual. When a person logs into iTrust, if he or she is a personal representative, they view their own records or those of the person/people they are representing. (For example, a mother could choose herself and any one of her children.)

* Public Health Agent: A person legally authorized view and respond to reports of adverse events.

These are the standards codes used within iTrust:

• ICD-9CM: The International Statistical Classification of Diseases and Related Health Problems (most commonly known by the abbreviation ICD) provides codes to classify diseases and a wide variety of signs, symptoms, abnormal findings, complaints, social circumstances and external causes of injury or disease. NHCS Classification of Diseases, Functioning and Disability
• ND: The National Drug Code (NDC) is a universal product identifier used in the United States for drugs intended for human use. National Drug Code Directory
• LOINC: Logical Observation Identifiers Names and Codes (LOINC) is a database and universal standard for identifying medical laboratory observations. LOINC c/o Medical Informatics
• CPT: The CPT code set accurately describes medical, surgical, and diagnostic services and is designed to communicate uniform information about medical services and procedures among physicians, coders, patients, accreditation organizations, and payers for administrative, financial, and analytical purposes. About CPT

There are 33 Use Cases for the system, as indicated by the attached diagram:

This diagram is also available as a Microsoft Visio File

Throughout this document MID = medical identification number. The MID is a unique number assigned to all roles.

The following use cases document flows of events.

The iTrust HCP has authenticated himself or herself in the iTrust Medical Records system [UC3].

An HCP creates patients [S1] and disables patients [S2]. The create/disable patients and HCP transaction is logged [UC5].

• [S1] The HCP enters a patient as a new user of iTrust Medical Records system. Only the name and email are is provided. An email with The patient's assigned MID and a secret key (the initial password) is personally provided to the user, with which the user can reset his/her password. The HCP can edit the patient according to data format 6.4 [E1] with all initial values (except patient MID) defaulting to null and/or 0 as appropriate. Patient MID should be the number assigned when the patient is added to the system and cannot be edited. The HCP does not have the ability to enter/edit/view the patient's security question/password.
• [S2] The HCP provides the MID of a patient for whom he/she wants to disable [E2]. The HCP provides a deceased date (data format 6.4). An optional diagnosis code is entered as the cause of death.

• [E1] The system prompts the enterer/editor to correct the format of a required data field because the input of that data field does not match that specified in data format 6.4 for patients.
• [E2] The enterer/editor is presented with the name of the user and determines if it is invalid or not the right person. The enterer/editor is prompted to try again.

The iTrust Admin has authenticated himself or herself in the iTrust Medical Records system [UC3].

An admin creates a LHCP, an ER, or a public health agent [S1]. A LHCP creates [S2] UAPs. Once entered, the enterer/editor is presented a screen of the input to approve [E2].

• [S1] An administrator enters a LHCP, ER, or public health agent as a user of iTrust Medical Records system, initially only the name and email are provided. A secret key is personally provided to the user, with which the user can reset his/her password. The data for personnel can be edited according to Data Format 6.2 (all fields mandatory except for associated MID and Street Address 2) [S6, E1]. The administrator shall be allowed to assign a LHCP to multiple hospitals, and the administrator can choose among only the hospitals provided in the hospital list pull down menu. The hospital ID numbers for a LHCP are stored in the Medical Care Personnel Affiliation database (data format 5.11).
• [S2] A LHCP enters an UAP as a user of iTrust Medical Records system according to data format 6.2 (all fields mandatory) [E1].
• [S3] The transaction is logged [UC5].

• [E1] The system prompts the enterer/editor to correct the format of a required data field because the input of that data field does not match that specified in data format 6.2, for HCPs.
• [E2] The enterer/editor is presented with the name of the user and determines if it is invalid or not the right person. The enterer/editor is prompted to try again.

The inclusion of the ER role was inspired by Department of Health and Human Services USA Emergency Responder Electronic Health Record Use Case http://www.dhhs.gov/healthit/usecases/documents/EmergencyRespEHRUseCase.pdf

UC1/UC2 has completed and a user has been created.

A user enters their MID and their password to gain role-based entry into the iTrust Medical Records system [E1] or requests that their password be changed [S1]. A session that has been inactive for too long is terminated [S3]. An authenticated session ends when the user logs out or closes the iTrust application.

• [S1] If the security question/answer has been set (it is not null) [E2], present security question and obtain answer [S2, E1].
• [S2] If answer to security question is correct, allow user to change their password. An email notification is sent [UC27, S1].
• [S3] Electronic sessions must terminate after a “pre-determined” period of inactivity. Allow the administrator to set the length of this period of time and ensure that all authorization is disabled after a period of inactivity that exceeds this length.
• [S4] A LHCP is presented with a screen of links to the following:
  • Recent Laboratory Results: recent (within the last month) laboratory results [UC26] for laboratory procedures he/she ordered in office visits.
  • Any upcoming appointments within the next week
  • Rejection/Acceptance of comprehensive report

• [S5] A patient is presented with a screen of links to the following:
  • Recent Laboratory Results: recent (within the last month) laboratory results [UC26] for laboratory procedures that the patient (or a patient he/she represents), that the patient has access.
  • Any upcoming appointments within the next week
  • Comprehensive report requested/generated of the patient, including patients that he/she represents

• [E1] The user may try three times. After three failed attempts with a userid in a given session, disallow attempts to log in via IP address for 15 minutes (see comments in the source code).
• [E2] If the patient has never stored a security question/answer, the user is not provided the ability to change the password.

UC1 has completed and a patient has been created. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

Demographic information is entered and/or edited [S1, S2]. Once entered, the enterer/editor is presented a screen of the input to approve [E2].

• [S1] A patient or personal health representative may enter or edit their own demographic information including their security question/answer according to data format 5.1. When answer to the security question is typed in, the answer should not appear on the screen (similar to how a password normally appears) and the answer should be confirmed (by the patient or personal health representative) before it is saved. [S4, E1].
• [S2] HCP must enter the MID of a patient and then enter or edit demographic information with the exception of the patient's security question/password according to data format 5.1 [S4, E1].
• [S3] An HCP may enter or edit their own demographic information according to data format 5.2 [S4, E1].
• [S4] The enter/edit demographics transaction is logged [UC5].

• [E1] The system prompts the patient or HCP to correct the format of a required data field because the input of that data field does not match that specified in data format 5.1 or data format 5.2, as appropriate.
• [E2] The enter/editor reviews the input and finds an error, he or she does not confirm the selection. He/She provides the correct input and submits again.

One of UC1-UC4 or UC6-UC17 has been initiated.

One of UC1-UC4 or UC6-UC17 has been initiated.

An HCP or patient enter/edits demographics [UC4, S1], designate/un-designate DLHCP [UC6, S2], allows/disallows access to diagnosis [UC7, S3], views access log [UC8, S4], views medical records [UC9, S5], view prescription report [UC19, S19], find LHCPs for prescription renewal [UC31, S32], or chronic disease risk factors [UC16, S15], authenticates users [UC3, S6], enter/edits personal health information [UC10, S7], documents an office visit [UC11, S8], proactively determines if healthcare is an office visit or procedure is due for a patient [UC17, S17], or proactively confirm prescription-renewal needs of a patient [UC32, S33]. An administrator or HCP creates or disables a HCP [UC2, S9] or patient [UC1, S9] respectively. An administrator maintains the standards list [UC 15, S10, S12-14] or maintains the hospital list [UC 18, S18]. An HCP requests biosurveillance information [UC14, S11], declares/undeclares a personal health representative for a patient [UC13, S16], or refers a patient for consultations [UC33, S34]. An LHCP, UAP and patient engage in telemedicine through which blood pressure and glucose levels can be monitored [UC34, S35]. All transaction logs are formatted via data format 6.3.

• [S1] Enter/edit demographics. The MID of the editor (may be the patient) and of the patient, transaction type = 1, and the date are recorded.

• [S2] View HCP; declare/undeclare LHCP as DLHCP. The MID of the editor (may be the patient) and of the patient, transaction type = 2, and the MID of the LHCP, and the date are recorded.

* [S3] Allow/disallow access to diagnosis. The MID of the editor (may be the patient) and of the patient, transaction type = 3, the diagnosis number and ”-allow” or “-disallow” (concatenated with diagnosis number), and the date are recorded.

• [S4] View access log. The MID of the viewer (must be patient), transaction type = 4, and the date are recorded.

• [S5] View medical records. The MID of the viewer (may be patient) and of the patient, transaction type = 5,and the date are recorded.

• [S6] Authenticate users. The MID of the patient and/or the health care professional, transaction type= 6, an optional string of “authenticated” and the date are recorded. “Authenticated” should be logged when the user's home page is accessed.

• [S7] Enter/edit personal health information. The MID of the editor and of the patient, transaction type = 7, and the date are recorded.

• [S8] Document office visit. The MID of the editor and of the patient, the office visit id, transaction type = 8, and the date are recorded.

• [S9] Create/disable patient or HCP. The MID of the editor and of the new patient or health care personnel, and role of the new user, transaction type = 9, and the date are recorded.

• [S10] Diagnosis code. The MID of the administrator, [patient = blank], transaction type =10, the diagnosis code, and the date are recorded.

• [S11] Request biosurveillance. The MID of the administrator, [patient = blank], transaction type =11, the diagnosis code, and the date are recorded.

• [S12] Medical procedure code. The MID of the administrator, [patient = blank], transaction type =12, the medical procedure code, and the date are recorded.

• [S13] Drug code. The MID of the administrator, [patient = blank], transaction type =13, the drug code, and the date are recorded.

• [S14] Identify risk factors. The MID of the LHCP and of the patient, transaction type =14, and the date are recorded.

• [S15] Cause of Death Trends. The MID of the logged in user, transaction type = 15, and the date are recorded.

• [S16] Declare/undeclare personal health representative. The MID of the editing HCP and of the patient, transaction type = 16, and the MID of the personal representative, and the date are recorded.

• [S17] Proactively determine necessary patient care. The MID of the HCP making the request, secondary MID = patient MID, transaction type = 17, and the date are recorded. Note that each patient in the presented patient list will have one log entry

• [S18] Maintain a hospital listing. The MID of the administrator, [secondary MID = blank], transaction type = 18; optional entry = hospital ID number, and the date are recorded.

• [S19] View prescription report. The MID of the editor and of the patient, transaction type = 19, and the date are recorded.

• [S20] View Hospital Statistics. The MID of the HCP, transaction type = 20; and the date are recorded.

• [S21] View patient comprehensive record. The MID of the HCP and of the patient, transaction type = 21, and the date are recorded.

• [S22] View emergency report. The MID of the LHCP and of the patient, transaction type = 22, and the date are recorded.

• [S23] Schedule Appointments. The MID of the person logged in, secondary MID = the person who the appointment is scheduled with, transaction type=23, and the date are recorded.

• [S24] Request Appointment. The MID of the person logged in, the person who the appointment is requested with (if applicable), transaction type=24, and the date are recorded.

• [S25] Comprehensive Report. The MID of the person logged in, the MID of the patient's record being requested (as the secondary MID), the status of the request at the time of the transaction (including the requesting LHCP where applicable), transaction type = 28, and the date are recorded.

• [S26] Take Satisfaction Survey. The MID of the patient, the office visit id, transaction type = 32, and the date are recorded.

• [S27] View physician satisfaction results. The MID of the patient, transaction type = 33, and the date are recorded.

• [S28] View laboratory procedure results. The MID of the viewer and of the patient, laboratory procedure ID, transaction type = 29, and the date are recorded.

• [S29] View patient list. The MID of the HCP, transaction type = 34, and the date are recorded.
• [S30] Find LHCPs with experience with a diagnosis. The MID of the patient, transaction type = 35, and the date are recorded.

• [S31] Send messages. The MID of the message sender, the MID of the message recipient, transaction type = 36, and the date are recorded.

• [S32] Find LHCPs for prescription renewal. The MID of the patient, transaction type = 41, and the date are recorded.

• [S33] Proactively confirm prescription-renewal needs. The MID of the HCP making the request, secondary MID = patient MID, transaction type = 42, and the current date are recorded. Note that each patient in the presented patient list will have one log entry.

• [S34] Refer a patient for consultations. The MID of the HCP sending the referal, secondary MID = patient MID, transaction type = 43, and the current date are recorded.

• [S35] Telemedicine monitoring. When an LHCP chooses to add/delete patients from his or her monitoring list, the MID of the LHCP, the MID of the patient, transaction type = 45, the word “add” or “delete”, and the current date are recorded. When a patient reports their blood pressure and/or glucose levels, their MID, transaction type 45, and a timestamp are recorded. When an LHCP chooses to monitor their patients, their MID, transaction type 45, and a timestamp are recorded.

• [S36] Adverse event reporting. A patient MID, type 46, and the date are recorded.

• [S37] Prescribe medication. A patient MID, an LHCP MID, the CPT code, type 38, and the date are recorded.

• [38] Adverse event monitoring. A public health agent MID, type 47, and the date are recorded.

None.

UC1 and UC2 have completed and a licensed health care professional and a patient have been created. The patient has authenticated himself or herself in the iTrust Medical Records system [UC3].

The patient chooses to view all LHCPs the patient has ever had an office visit with and those whom he/she had designated [S1, S2]. The patient can also add a LHCP to their provider list by searching for the name of a LHCP [S3] and then selecting to add the HCP to their list of providers. The event is logged [UC5].

[S1] The LHCP's name, specialty, address, date of office visit, and whether or not the LHCP is a DLHCP for this patient is indicated. The list is sorted by the date of the last office visit (most recent first).

[S2] The patient can choose to toggle between designating/undesignating any LHCP as being a DLHCP for them.

[S3] The patient types a last name or partial last name and optionally reduces the list of choices by providing the specialty and/or zip code (match on first three numbers of zip code). The LHCP's name, specialty, and address are provided.

none

Office of the National Coordinator for Health Information Technology (ONC) Consumer Empowerment: Consumer Access to Clinical Information Prototype Use Case http://www.hhs.gov/healthit/usecases/consumeraccess.html, Scenario 2

The patient has authenticated himself or herself in the iTrust Medical Records system [UC2].

The patient chooses to allow/disallow access to diagnosis to DLHCP, to LHCP, or to no one. He or she is presented with a listing of diagnoses for which allowing access is discretionary. The default access option is “allow” and all prior allow/disallow choices are displayed. The patient can change the default or current choices. The patient is then asked to confirm their selection [E1]. Upon confirmation, the patient sees a listing of their diagnoses with discretionary access and the current allow/disallow status.

None.

• [E1] The patient does not agree with the update and is prompted to try again. * [E2] If an office visit applies to more than one diagnosis and any of those diagnoses has discretionary access, the office visit can only be seen by the DLHCP.

A patient is a registered user of the iTrust Medical Records system [UC1]. The patient has authenticated himself or herself in the iTrust Medical Records system [UC3].

The patient chooses to view his or her access log. The patient then chooses the beginning and end date for the period of time they would like to view their access log for [S1, S2]. The resulting list should include the following for each access:

• Name of accessor (with a link to contact information if the viewer is an LHCP)
• Role of accessor relative to the patient
• Date and time of access
• Transaction Type (See Section 6.3)

The event is logged [UC5].

[S1] The patient also chooses to view the list sorted by dates, most recent access first.
[S2] The patient also chooses to view the list sorted by the role of the accessor relative to the patient (personal health representative, DLHCP, LHCP, UAP, Emergency Responder; any order is fine as long as the list is sorted by role) as well as by date for each role type.

None.

A patient is a registered user of the iTrust Medical Records system [UC1]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

A patient or personal health representative chooses to view medical records [S1] including family history [S2]. The event is logged [UC5].

• [S1] The patient or personal health representative can see patient personal health information (including historical values), immunizations, and office visit information (date, diagnoses, medication, name of attending physician but not notes, laboratory procedures) for (a) their own records and (b) the records for whom the user is a personal representative. If a patient or personal health representative has not taken an office visit satisfaction survey for an office visit yet, the patient may choose to take the survey for an office visit (if the survey has already been taken, the patient or personal health representative will not have the ability to take the survey or view their previously submitted survey) [UC24].
• [S2] The patient or personal health representative can see an abbreviated health history of their siblings, parents, and both sets of grandparents for which MIDs are available in iTrust. They can see diagnoses related to the following [presented as a table with an x if the family member suffered from that diagnosis]:

1. high blood pressure (Systolic blood pressure over 240 mmHg and/or a diastolic blood pressure over 120 mmHg);
2. high cholesterol (HDL (“good”) cholesterol levels under 35 mg/dL (milligrams per deciliter) and/or a triglyceride level over 250 mg/dL);
3. diabetes [is diagnosed with ICD-9CM code beginning with 250: http://icd9cm.chrisendres.com/index.php?action=child&recordid=1765],;
4. cancer [is diagnosed with ICD-9CM code beginning with 199: http://icd9cm.chrisendres.com/index.php?action=child&recordid=1765],;
5. heart disease [is diagnosed with ICD=9CM code beginning with 402: http://icd9cm.chrisendres.com/index.php?action=child&recordid=1765],;
6. smoking; and
7. the cause of death if the family member has deceased.

None.

The inclusion of the ER role was inspired by Department of Health and Human Services USA Personalized Health Care Use Case http://www.hhs.gov/healthit/usecases/documents/PHCDetailed.pdf

An HCP is a registered user of the iTrust Medical Records system [UC2]. The HCP has authenticated himself or herself in the iTrust Medical Records system [UC3].

An HCP chooses to enter/edit personal health information. The information is view/editied [S1]. If the HCP is not one of the patient's DLHCP or the UAP associated with one of their DLHCP, a message is sent to the patient and their personal representative [S2]. The event is logged [UC5, S7].

• [S1]The health care personnel enters a MID [E1] of a patient and confirms their selection [E2]. The event is immediately logged as a “view” by the LHCP [UC5, S5]. The health care personnel may enter/edit personal health information including editing historical values from Data Format 6.4.1 and 6.4.2, immunizations, and office visit information (date, diagnoses, medication, name of attending physician but not notes, laboratory procedures), and family history (the MIDs of the patient's mother and father). The HCP can indicate the patient has passed away, providing an appropriate diagnosis code.
• [S2] The patient whose personal health record was viewed by a LHCP or UAP is notified of the viewing/editing on his or her notification area upon logging into iTrust [patient is provided name of LHCP and/or HCP and the date of access]. This notification remains on the patient's notification screen for a period of 90 days. A fake email is also sent to the patient telling the patient to log onto iTrust to see who has viewed their Emergency Heath Record. Note to students: the iTrust system does NOT currently support actual email sending, only a “fake” email sending facility. All email notifications should be executed through the fake email utility.

• [E1] The health care professional types an invalid medical identification number and is prompted to try again.
• [E2] The patient chosen is not the desired patient. The health care professional does not confirm the selection and is prompted to try again.

An HCP is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

An HCP chooses to document [S1] or edit [S2] an office visit .

• [S1] The LHCP enters a MID [E1] of a patient and confirms their input [E2]. The LHCP document the notes (numbers, characters, ?, -, ', ., :, blankspace and carriage return) of an office visit, providing the date of the office visit, and their own medical identification number. Additionally, the HCP can document one or more diagnoses (ICD-9CM code), one or more medical procedures (CPT code) performed, one or more lab procedures that are ordered (LOINC code, see Data Format 6.11) one or more medications (NDC, see Data Format 5.6) prescribed, and one or more immunizations given (CPT Code, see UC15, S1) chosen from appropriate pull-down lists. The LHCP can indicate if the patient is allowed to restrict access to the diagnosis information. The event is logged [UC5, S8].

* [S2] LHCPs can return to an office visit and alter the fields of the office visit [text, diagnoses, medical procedures, medications]. The event is logged [UC5, S8].

• [E1] The LHCP types an invalid medical identification number and is prompted to try again.
• [E2] The patient chosen is not the desired patient. The health care personnel does not confirm the selection and is prompted to try again.

The inclusion of recording of immunizations was inspired by Department of Health and Human Services USA Immunization and Response Management Detailed Use Case http://www.dhhs.gov/healthit/usecases/documents/EmergencyRespEHRUseCase.pdf

A software tester has a login and password. Similar to an administrator, a software tester is added by directly entering the software tester into the database by an administrator that has access to the database.

The software tester authenticates himself or herself in the iTrust Medical Records system [UC2]. He or she is then presented with the actual operational profile of the operations of the iTrust Medical Records where the use percentage is the % of total transactions of a particular type by each of the user types [patient, LHCP, UHCP, admin, tester]

None.

None

An HCP is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

A patient's DLHCP chooses to add or delete a patient's [E1, E2] personal representative by typing that person's MID [E1, E2]. The event is logged [UC5].

None.

• [E1] The health care personnel types an invalid medical identification number and is prompted to try again.
• [E2] The patient chosen is not the desired patient. The health care personnel does not confirm the selection and is prompted to try again.

An HCP is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

A LHCP chooses to determine if instances of a certain ailment is reaching epidemic proportions in a given area. Allowable epidemic queries are malaria [S1] and influenza [S2]. Alternatively, the LHCP chooses to examine recent trends in diagnoses [S3]. The event is logged [UC5].

• [S1] The LHCP can choose a malaria diagnosis [E1] and type in the desired zip code [E2] and a date (such as today's date) [E3]. The data in the database is analyzed according to the heuristics in section 5.7.1 to determine if an epidemic is occurring in the region defined by the zip code that match the first three numbers in the provided zip code (e.g. if zip code 27695 is provided, all data with zip code 276xx is analyzed, where each x is any digit from 0-9). If the health care professional chooses to analyze the epidemic potential for a diagnosis for which there is not a defined epidemic detection algorithm, the doctor is notified that no analysis can occur. The LHCP is provided a yes/no answer on whether an epidemic is occurring during any consecutive two weeks during the time period.

• [S2] The LHCP can choose an influenza diagnosis [E1] and type in the desired zip code [E2] and a date (such as today's date) [E3]. The data in the database is analyzed according to the heuristics in section 5.7.2 to determine if an epidemic is occurring in the region defined by the zip code that match the first three numbers in the provided zip code (e.g. if zip code 27695 is provided, all data with zip code 276xx is analyzed, where each x is any digit from 0-9). If the health care professional chooses to analyze the epidemic potential for a diagnosis for which there is not a defined epidemic detection algorithm, the doctor is notified that no analysis can occur. The LHCP is provided a yes/no answer on whether an epidemic is occurring.

• [S3] The LHCP can choose to examine recent trends in diagnoses. The LHCP can choose any diagnosis code [E1] and type in the desired zip code [E2] and a date (such as today's date) [E3] . The LHCP is then provided a bar chart (such as can be found here: http://www.imedi.org/docs/references/testbed.htm) for the last 8 weeks. For each week, three bars are provided: (1) the region (region defined by the zip code that match the first three numbers in the provided zip code (e.g. if zip code 27695 is provided, all data with zip code 276xx is analyzed, where each x is any digit from 0-9); (2) the state (region defined by the zip code that match the first two numbers in the provided zip code (e.g. if zip code 27695 is provided, all data with zip code 27xxx is analyzed, where each x is any digit from 0-9); and (3) all cases in the database.

• [E1] The HCP types an invalid diagnosis code and is prompted to try again.
• [E2] The HCP types a invalid zip code and is prompted to try again.
• [E3] The HCP types an invalid date and is prompted to try again.

The administrator has authenticated himself or herself in the iTrust Medical Records system [UC2].

An administrator chooses to maintain the standards list for immunizations [S1], diagnoses [S2], allowable drugs [S3], or allowable physical services [S4]. The event is logged [UC5].

• [S1] The administrator will maintain [add/update] a listing of allowable immunizations that an HCP can use. The administrator will store (1) the CPT code (The CPT code set accurately describes medical, surgical, and diagnostic services and is designed to communicate uniform information about medical services and procedures among physicians, coders, patients, accreditation organizations, and payers for administrative, financial, and analytical purposes. About CPT) [E1] and (2) up to 30 alpha characters giving the name [E1] of the immunization.

• [S2] The administrator will maintain a listing of allowable diagnoses that an LHCP can use. The administrator will store (1) the ICD-9CM code (The International Statistical Classification of Diseases and Related Health Problems (most commonly known by the abbreviation ICD) provides codes to classify diseases and a wide variety of signs, symptoms, abnormal findings, complaints, social circumstances and external causes of injury or disease. NHCS Classification of Diseases, Functioning and Disability) for the diagnosis [E1]; (2) a classification that the diagnosis is either chronic/long-term OR short term; and (3) up to 30 alphanumeric characters giving the name [E1] of the diagnosis.

• [S3] The administrator will maintain [add/update] a listing of allowable drugs that an HCP can use. The administrator will store (1) the National Drug Code (The National Drug Code (NDC) is a universal product identifier used in the United States for drugs intended for human use. National Drug Code Directory)

• [S4] The administrator will maintain [add/update] a listing of allowable physical services (including laboratory procedures) that an HCP can use. The administrator will store information of a LOINC code (Logical Observation Identifiers Names and Codes (LOINC) is a database and universal standard for identifying medical laboratory observations. LOINC c/o Medical Informatics) [E1] according to Data Format 6.11.

• [E1] The administrator types an invalid code information and is prompted to try again.

The LHCP has authenticated himself or herself in the iTrust Medical Records system [UC3].

Through the Personal Health Records page, an LHCP chooses a chronic disease and a patient. The data in the database is analyzed according to the risk factors for the disease to determine if the patient exhibits a certain risk factor. Currently available risk factors for chronic diseases are defined for Diabetes and Type 1 and Type2 and Heart Disease. When the chosen patient satisfies the preconditions of the chosen chronic disease [E1], the LHCP is provided with a warning message if that patient exhibits three or more risk factors. The message will display the risk factors that the patients exhibit. The event is logged [UC5].

None.

• [E1] The LHCP chooses to examine a patient for which the preconditions do not apply (e.g., an adult shouldn't be tested for child diabetes) and the LHCP is prompted that no analysis can occur.

The HCP has authenticated himself or herself in the iTrust Medical Records system [UC2].

An HCP chooses to identify chronic patients who need an office visit [S1], older patients who need a flu shot [S2], or any patient who is overdue for an immunization [S3]. The HCP is presented with a listing of patients for whom they are a DLHCP who need care because of satisfying the one of preceding conditions. The presented patient information shall include each patient's name and home phone number so that reminder calls can be made. The list is sorted based on the alphabetical order of the patients' last names, and then first names. The event is logged [UC5].

• [S1] An alive patient who has not had an office visit for more than one year and who has been diagnosed with
  • diabetes mellitus [is diagnosed with ICD code beginning with 250: http://icd9cm.chrisendres.com/index.php?action=child&recordid=1765],
  • asthma [is diagnosed with ICD code beginning with 493: http://icd9cm.chrisendres.com/index.php?action=child&recordid=4700], or
  • circulatory-system disease [is diagnosed with an ICD code between 390 and 459 inclusive: http://icd9cm.chrisendres.com/index.php?action=child&recordid=4025].

• [S2] An alive patient over 50 years old who has not had a flu shot [CPT codes 90656, 90658, 90660 per http://www.influenza.com/index.cfm?fa=ADDITIONAL_RES_HC_2] during the months Sept - Dec of the last calendar year (or during the months Sept - Dec of the current calendar year if the retrieval time is between Sept - Dec).

• [S3] An alive patient under the age of 19 who has not had proper immunizations per the immunization schedule. The “catch up schedule” is relevant when the patient did not begin the immunizations according to the recommended schedule.
  • Hepatitis B (90371) three doses: at birth, at age 1 month, at age 6 months; catch up schedule: at least 4 weeks between dose 1 and dose 2 and at least 8 weeks between dose 2 and dose 3
  • Rotavirus (90681) three doses: at age 6 weeks, at age 4 months, at age 6 months; catch up schedule: at least 4 weeks between dose 1 and dose 2 and at least 4 weeks between dose 2 and dose 3
  • Diphtheria, Tetanus, Pertussis (90696) six doses: at age 6 weeks, at age 4 months, at age 6 months, at age 15 months, at age 4 years, at age 11 years; catch up schedule: at least 4 weeks between dose 1 and dose 2, at least 4 weeks between dose 2 and dose 3, at least 6 months between doses 3 and 4, at least 6 months between dose 4 and dose 5, at least 5 years between dose 5 and dose 6
  • Haemophilus influenzae (90645) three doses: at 6 weeks, at age 4 months, at age 12 months; catch up schedule: at least 4 weeks between dose 1 and dose 2 and at least 4 weeks between dose 2 and dose 3 if first dose is administered at younger than 12 months; if first dose is administered between 12 and 14 months, at least 8 weeks between dose 1 and dose 2 and dose three is canceled; if first dose is administered at or after 15 months, only one dose is required
  • Pneumococcal (90669) four doses: at age 6 weeks, at age 4 months, at age 6 months, at age 12 months; catch up schedule: at least 4 weeks between dose 1 and dose 2 and at least 4 weeks between dose 2 and dose 3 and at least 8 weeks between dose 3 and dose 4 if first dose is administered at younger than 12 months; if first dose is administered between 12 and 14 months, at least 8 weeks between dose 1 and dose 2 and dose three is canceled; if first dose is administered at or after 15 months, only one dose is required
  • Poliovirus (90712) four doses: at age 6 weeks, at age 4 months, at age 6 months, 4 years; catch up schedule: at least 4 weeks between dose 1 and dose 2, at least 4 weeks between dose 2 and dose 3, at least 4 weeks between doses 3 and 4, dose 4 is not required if dose 3 was administered at the age of 4 or older
  • Measles, Mumps, Rubella (90707) two doses: at age 12 months, at age 4 years; catch up schedule: at least 4 weeks between dose 1 and dose 2
  • Varicella (90396) two doses: at age 12 months, at age 4 years; catch up schedule: at least 3 months between dose 1 and dose 2
  • Hepatitis A (90633) two doses: at age 12 months; at age 18 months: catch up schedule: at least 6 months between dose 1 and dose 2
  • Human Papillomavirus (90649) Female only, three doses; at age 9 years; at age 9 years + 2 months; at age 9 years + 6 months; catch up schedule: at least two months between dose 1 and dose 2; at least four months between dose 2 and dose 3

None.

American Academy of Pediatrics http://www.cispimmunize.org/

• Childhood schedule (birth to 6 years): http://www.cispimmunize.org/IZSchedule_Childhood.pdf
• Adolescent schedule (7 to 18 years): http://www.cispimmunize.org/IZSchedule_Adolescent.pdf
• CPT Codes: http://www.cdc.gov/vaccines/programs/iis/stds/cpt.htm

The administrator has authenticated himself or herself in the iTrust Medical Records system [UC2].

An administrator chooses to maintain hospitals that a health care professional belongs to (a health care professional can belong to multiple hospitals [UC2, S3]]) [S1] and the event is logged [UC5].

• [S1] The administrator will store (1) hospital Id number for the hospital [E1]; and (2) up to 30 alphanumeric characters giving the name of the hospital
• [S2]. The system shall enable the administrator to add a new entry for a hospital, or modify the hospital name in an existing entry. Note that the administrator is not allowed through the system interface to delete an existing entry or modify the hospital ID number in an existing entry.

• [E1] The administrator types an invalid ID and is prompted to try again.
• [E2] The administrator types an invalid name and is prompted to try again.

A patient and LHCP is a registered user of the iTrust Medical Records system [UC1 and UC2]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

A patient or personal health representative [S1] or LHCP [S2] chooses to view prescription reports. If the LHCP is not one of the patient's DLHCP or the UAP associated with one of their DLHCP, a message is sent to the patient and their personal representative [S4]. The event is logged [UC5].

• [S1] The user (patient or personal health representative) can choose to view a list of (1) their own prescriptions or (2) the prescriptions for whom the user is a person health representative by choosing one patient from a a list of these patients. A prescription list is then displayed [S3], sorted by start date (the later date is ranked earlier).
• [S2] The user (LHCP) enters a MID of a patient [E1] and confirms their input [E2]. At this point, the LHCP can view a prescription list for that patient [S3], sorted by start date (the later date is ranked earlier).
• [S3] The prescription report is titled with the patient name. The prescription list includes medication, date prescribed, start date, end date for each prescription, and the name of the doctor who prescribed the medication.
• [S4] The patient whose prescription was viewed by a LHCP or UAP is notified of the viewing/editing on his or her notification area upon logging into iTrust [patient is provided name of LHCP and/or HCP and the date of access]. This notification remains on the patient's notification screen for a period of 90 days. A fake email is also sent to the patient telling the patient to log onto iTrust to see who has viewed their Emergency Heath Record. Note to students: the iTrust system does NOT currently support actual email sending, only a “fake” email sending facility. All email notifications should be executed through the fake email utility.

• [E1] The LHCP types an invalid medical identification number and is prompted to try again.
• [E2] The patient chosen is not the desired patient. The LHCP does not confirm the selection and is prompted to try again.

A LHCP is a registered user of the iTrust Medical Records system [UC1 and UC2]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

A LHCP chooses to view a cause-of-death trends report that provides a sorted list of the “top 2” most common causes of death for all patients [S1], for all males [S2], and for all females in the databased [S3] for a stated time period. The set of a LHCP's patients are all those patients whom have ever had an office visit with the LHCP. The event is logged [UC5].

• [S1] The LHCP chooses the time period for which he or she would like to see the report at the granularity level of a starting year and an ending year (which can be the same) [E1]. The LHCP can then view the top 2 most common causes of death of his or her own patients and the top 2 most common causes of death for all patients during the specified time period. For each of the top 2, the diagnosis ICD-9CM code and name is displayed, the quantity of deaths by this diagnosis is provided.

• [S2] The LHCP chooses the time period for which he or she would like to see the report at the granularity level of a starting year and an ending year (which can be the same) [E1]. The LHCP can then view the top 2 most common causes of death of his or her own male patients and the top 2 most common causes of death for all male patients during the specified time period. For each of the top 2, the diagnosis ICD-9CM code and name is displayed, the quantity of deaths by this diagnosis is provided.

• [S3] The LHCP chooses the time period for which he or she would like to see the report at the granularity level of a starting year and an ending year (which can be the same) [E1]. The LHCP can then view the top 2 most common causes of death of his or her own female patients and the top 2 most common causes of death for all female patients during the specified time period. For each of the top 2, the diagnosis ICD-9CM code and name is displayed, the quantity of deaths by this diagnosis is provided.

• [E1] The LHCP chooses and invalid year and is prompted to try again.

A LHCP or ER is a registered user of the iTrust Medical Records system [UC1 and UC2]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

A LHCP or ER chooses to view an emergency report and provides an MID [S1]. At this point, the LHCP obtains a printable report [meaning you should minimize the space taken up to provide the information] containing vital information for the patient:

• Name
• Age
• Gender
• Emergency contact (name and phone number)
• Allergies
• Blood type
• A list of all diagnosis codes chronic/long-term diagnoses for the patient and well as all short term diagnoses made within the last 30 days. Display the ICD-9CM code and the name of the diagnoses. Sort by most recent first.
• A list of all prescriptions the patient is likely to be currently taking as determined by the end date of the prescription has passed by 91 days or less. Display the National Drug Code and the name of the prescription. Sort by most recent first.
• A list of all immunizations the patient has had. Display the CPT Code and the name of the immunization. Sort by most recent first.

A notification and email notify the patient of the viewing [S2]. A notification is also sent to all of the patient's DLHCP's [S3]. The event is logged [UC5].

• [S1] The LHCP or ER enters a MID [E1] and confirms the input [E2].
• [S2] The patient whose emergency electronic health record was viewed by a LHCP or ER is notified of the viewing on his or her notification area upon logging into iTrust [patient is provided name of LHCP and/or HCP and the date of access]. This notification remains on the patient's notification screen for a period of 90 days. A fake email is also sent to the patient and the patient's personal representative; the email should ask telling the patient to log onto iTrust to see who has viewed their Emergency Heath Record. Note to students: the iTrust system does NOT currently support actual email sending, only a “fake” email sending facility. All email notifications should be executed through the fake email utility.
• [S3] All of the DLHCP's of the patient whose emergency electronic health record was viewed are notified of the viewing on their notification area upon logging into iTrust [the name of the LHCP or ER and the date of access is also included]. This notification remains on the DLHCP's notification screen for a period of 30 days. A fake email is also sent to all of the DLHCP's telling them that one of their patient's records has been viewed in an emergency situation.

• [E1] The LHCP types an invalid medical identification number and is prompted to try again.
• [E2] The patient chosen is not the desired patient. The LHCP or ER does not confirm the selection and is prompted to try again.

The inclusion of the ER role was inspired by Department of Health and Human Services USA Emergency Responder Electronic Health Record Use Case http://www.dhhs.gov/healthit/usecases/documents/EmergencyRespEHRUseCase.pdf

A patient and LHCP are registered users of the iTrust Medical Records system [UC1 and UC2]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

A patient can request an appointment with an LHCP [S1] or an LHCP can request an appointment with a patient [S4]. An appointment request can be accepted or rejected by the recipient [S3]. Also, users are notified of accepted appointments on their appointments page [S6]. Both patients and LHCPs can view a list of their upcoming appointments [S6].

• [S1] The patient requests an appointment by inputting either the mid of the LHCP or a hospital. The patient also inputs the reason for the appointment, his top two date and time options for the appointment, and length of the visit [E1](see Data Format 6.10) [E2]. The event is logged [UC5, S24].
  
• [S2] The LHCP is notified on his/her appointment page if a patient has requested an appointment with him/her or if a patient has requested an appointment at his/her hospital that has not already been scheduled. If he/she chooses to schedule appointments, a list of requested appointments that apply to him/her is displayed. If he/she selects an appointment request, he/she can view all information input into data format 6.10. [S3]
  
• [S3] He/She can accept [E1, E3] or reject the suggested dates and times. If he/she rejects both dates and times, he/she is prompted to suggest two more dates and times [E1], length of the visit, and/or comments [E2]. The event is logged [UC5, S24]. If the appointment is accepted, the LHCP medical identification number, patient medical identification number, date, time, and length of the appointment are recorded. The event is logged [UC5, S23].
  
• [S4] The LHCP chooses to request an appointment with the patient. He/She inputs the reason for the appointment (optional), length of the visit, and approximately how far from today's date the appointment should be scheduled in weeks (see Data Format 6.10) [E2]. His/her mid is recorded with the appointment request. The event is logged [UC5, S24].
• [S5] The patient is notified on his/her appointment page if any requested appointments have been accepted or rejected. The patient is also notified on the appointment page if an LHCP has requested an appointment. When the patient chooses to schedule appointments, he/she can view a list of any requested appointments that have been accepted or rejected or if an LHCP has requested an appointment. If an LHCP has requested an appointment (indicating how many weeks away the appointment should be scheduled), [S1]. If an LHCP has responded to a previous appointment request with this patient, [S3].
• [S6] The LHCP is notified on their appointment page and via email [UC27, S3] of any newly accepted or rejected appointments.

• [E1] The appointment time conflicts with another appointment that the user previously scheduled. The system asks if the user would like to schedule the appointment. The user is permitted to schedule the appointment despite conflicts.
  
• [E2] The user inputs invalid information and is prompted to try again.
• [E3] The LHCP chooses to accept an appointment with his/her hospital, but another LHCP has already accepted. The system notifies the LHCP of this and does not allow the appointment to be scheduled.

An LHCP and Admin has authenticated him or herself in the iTrust Medical Records system [UC2].

The LHCP requests a comprehensive patient report for a particular patient [S1]. The Admin can either approve [S2] or reject [E3] the report from a list of requests. Upon approval, The LHCP is able to view the approved comprehensive patient report [S3] from a list of his/her requests. The event of requesting, approving/rejecting, and report generation is logged [UC5].

• [S1] The LHCP enters a patient medical identification number (MID) [E1] and confirms his/her input [E2].
• [S2] The Admin views the Names and MIDs of the requesting LHCP and the requested patient, and approves the report [E3].
• [S3] The LHCP can view of the comprehensive patient report for the specified patient, including the information below. An email notification is sent [UC27, S4]
  • All patient demographic information (address, phone, etc.), see [UC4] and Data Format 6.1
  • The entire history of personal health records, see [UC10] and Data Format 6.4
  • All diagnoses, including those not normally viewable by the requesting LHCP, see [UC11] and Data Format 6.5
  • All designated HCPs (MIDs and Names), see [UC6]
  • All allergies, procedures, medications, office visits, and known relatives, see [UC11] and Data Format 6.5, 6.6
  • All MIDs and names of people that this person is representing, see [UC13]
  • All MIDs and names of people that this person is represented by, see [UC13]
  • The date/time in which the report was generated by the LHCP * The date/time in which the report was approved by an Admin * The MID and name of the LHCP who requested the report * The MID and name of the Admin who approved the report
• [S4] The LHCP views a list of requests he/she has made for reports, with the status and pertinent information about the requests. For approved requests, a one-time only link to generate and display the report [S3] is shown.

• [E1] The LHCP types an invalid MID and is prompted to try again.
• [E2] The chosen patient is not the desired patient. The LHCP does not confirm the selection and can try again.
• [E3] The Admin rejects the request for a comprehensive patient report, providing justification for the rejection. The LHCP can view rejection justification in his/her list of report requests.

A patient is a registered user of the iTrust Medical Records system [UC1]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

A patient or personal health representative can answer any of the following questions relative to a previous (in UC9, S1) office visit according to Data Format 6.13.

• How many minutes did you wait in the waiting room?
• How many minutes did you wait in the examination room before seeing your physician?
• How satisfied were you with your office visit?
• How satisfied were you with the treatment or information you received?

The answers to the survey are stored. The event is logged [UC5, S26].

None

None

A user is a registered user of the iTrust Medical Records system [UC1]. The iTrust user has authenticated himself or herself in the iTrust Medical Records system [UC3].

A user chooses to view physician satisfaction survey results. The user provides a zip code [E1] and an (optional) physician type (from a pull-down list: see data format 6.2 - general, surgeon, heart specialist, pediatrician, OB/GYN). The patient is provided with the following for each physician of that type that practices in a zip code (based upon the address/zipcode provided in UC2) that match the first three digits of the provided zip code:

• Name
• Address
• Average number of minutes patients wait in waiting room
• Average number of minutes patients wait in examination room prior to seeing physician
• Average office visit satisfaction
• Average satisfaction with treatment/information
• Percentage of office visits for which satisfaction information is available

The event is logged [UC5, S27].

None

[E1] The input is not a valid zip code and/or a valid physician type (see Data Format 6.2). The user is asked to try again.

A patient and HCP are registered users of the iTrust Medical Records system [UC1 and UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

A patient or personal health representative [S1] or HCP [S2] chooses to view laboratory procedure status; or a HCP chooses to edit a laboratory procedure [S3]. If the HCP is not one of the patient's DLHCP or the UAP associated with one of their DLHCP, a message is sent to the patient and their personal representative [S4].

• [S1] The patient can view a list of laboratory procedures and status for (a) their own records and (b) the records for which the user is a personal representative. Only laboratory procedures for which the HCP has allowed viewing access are shown. The list is sorted by date of the last status update, most recent first. The event is logged [UC5, S28].

• [S2] The HCP enters a MID [E1] of a patient and confirms their input [E2]. The HCP can view a list of laboratory procedures and results, sorted by the date of the last status update, most recent first. The HCP can choose to sort by date of the last status update or by LOINC code ([UC15 S4], ascending order). If the HCP is the HCP that ordered the laboratory procedure, the HCP can allow or disallow viewing access to the laboratory results and is given the option to edit the office visit in which the laboratory procedure was ordered. The event is logged [UC5, S28].

• [S3] The HCP enters a MID [E1] of a patient and confirms their input [E2]. The HCP can view a list of laboratory procedures and can choose to update the status and comments (including results, if applicable) (see Data Format 6.11). The list is sorted by the dates of the last status update. The event is logged [UC5, S28] and an email notification is sent [UC27, S2].

• [S4] The patient whose laboratory report was viewed by a LHCP or UAP is notified of the viewing/editing on his or her notification area upon logging into iTrust [patient is provided name of LHCP and/or HCP and the date of access]. This notification remains on the patient's notification screen for a period of 90 days. A fake email is also sent to the patient telling the patient to log onto iTrust to see who has viewed their Emergency Heath Record. Note to students: the iTrust system does NOT currently support actual email sending, only a “fake” email sending facility. All email notifications should be executed through the fake email utility.

• [E1] The HCP types an invalid medical identification number and is prompted to try again.
• [E2] The patient chosen is not the desired patient. The HCP does not confirm the selection and is prompted to try again.

One of UC3, UC22, UC23, or UC26 has been initiated.

An email alert is sent out to the iTrust user in the event of a changed password [S1], status change in laboratory procedure [S2], accepted scheduled appointment [S3], comprehensive report requested and generated [S4]. Note to students: the iTrust system does NOT currently support actual email sending, only a “fake” email sending facility. All email notifications should be executed through the fake email utility.

• [S1] The user has successfully changed his/her password [UC3, S2]. An email informing the user of the password change is sent to the user including the MID but not the password.
• [S2] The status of a laboratory procedure has been updated [UC26, S3]. The patient is notified with the following information: the LOINC number and the updated status.
• [S3] The patient or LHCP has accepted an appointment as scheduled [UC22, S6] and both users are notified of the date, time, length, and comment via email.
• [S4] The admin has approved the comprehensive report generation [UC23, S2] or the LHCP generates the report. The patient is notified via email that a comprehensive report was generated, and the MID of the LHCP and the approving Admin are included.

A LHCP is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

The LHCP chooses to view all patients with which he or she has ever had an office visit with. The patient’s name (clickable to view PHR), address, and date of last office visit. The list is sorted by the date of the last office visit (most recent first). The event is logged [UC5, S29]

None.

Office of the National Coordinator for Health Information Technology (ONC) Consumer Empowerment: Consumer Access to Clinical Information Prototype Use Case http://www.hhs.gov/healthit/usecases/consumeraccess.html, Scenario 2

A patient is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

A patient has just been diagnosed with a condition and wants to find the LHCPs in the area who have handled that condition. The patient chooses 'My Diagnoses” and is presented with a listing of all their own diagnoses, sorted by diagnosis date (more recent first). The patient can select a diagnosis and will be presented with the LHCPs in the patient's living area (based upon the first three numbers of their zip code) who have handled this diagnosis in the last three years. The list is ranked by the quantity of patients the LHCP has treated for that diagnosis (each patient is only counted once regardless of the number of office visits). For each LHCP, the following information is displayed:

• Name of LHCP linked to contact information for that LHCP
• The quantity of unique patients treated by that LHCP for that diagnosis (each patient is only counted once regardless of the number of office visits)
• List of all prescriptions given by that LHCP for that diagnosis
• List of all laboratory procedures ordered by that LHCP for that diagnosis
• The LCHP's average visit satisfaction
• The LHCP's average treatment satisfaction

The event is logged [UC5, S30]

None.

Inspired by Office of the National Coordinator for Health Information Technology (ONC) Quality Detailed Use Case http://healthit.hhs.gov/portal/server.pt?open=512&objID=1202&&PageID=15677&mode=2&in_hi_userid=10732&cached=true

A LHCP or patient is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

An HCP wants to send a message to a patient and/or that patient's personal representative [S1] or a patient or personal representative wants to send a message to one of their DLHCP or that of a person they are representing [S2]. The message exchange is recorded [S3]. The event is logged [UC5, S31]

• [S1] A patient or personal representative for a patient chooses to send a message to an LHCP. They are presented with a pull down menu of their DLHCP. They can choose one of these and type the text of a message. The message, the sender, and the date is then posted in the LHCP's MyMessages page. The LHCP can read the message and can reply to it which sends a message back to the patient. The reply message and the date is then posted on the patient's MyMessages page and a fake email is sent to the patient that indicates that they have a message from an LHCP.
• [S2] An LHCP chooses to send a message to a patient. He or she enters and confirms the patient's MID. The LHCP types the text of a message. The message, the sender, and the date is then posted on the the patient's MyMessages page and a fake email is sent to the patient that indicates that they have a message from an LHCP. The patient can choose to reply to the message which is then available in the LHCP's MyMessages area.
• [S3] The text of the message between the LHCP and the patient becomes a permanent part of the patient's record. A LHCP can view the text of all the messages between him/herself and the patient by choosing the View Messages option after selecting and confirming the Patient's MID [E1, E2].

• [E1] The HCP types an invalid medical identification number and is prompted to try again.
• [E2] The patient chosen is not the desired patient. The HCP does not confirm the selection and is prompted to try again.

Inspired by Office of the National Coordinator for Health Information Technology (ONC) Patient - Provider Secure Messaging Use Case http://www.hhs.gov/healthit/usecases/remcon.html

A patient is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

A patient wants to renew the patient's expired prescriptions (i.e., prescriptions' end dates are later earlier than the current date) and therefore wants to find the LHCPs who earlier wrote the patient's expired prescriptions (it is assumed that the doctors who wrote prescriptions are all LHCPs so no LHCP checks on the prescription-writing doctors are needed). The patient chooses “My Expired Prescription Reports” and is presented with a list of the patient's expired prescriptions [S1], sorted by start date (the later date is ranked earlier closer to the top). The patient can select to view contact information of a selected LHCP shown in the expired prescription list [S2].

• [S1] The expired prescription report list is titled with the patient name. The expired prescription list includes medication, date prescribed (i.e., the day of the office visit), start date, end date for each prescription, and the name of the LHCP who prescribed the medication (where the name of the LHCP is linked to contact information for that LHCP). If there are no expired prescriptions, an empty expired prescription list is presented. The event is logged [UC5, S32]
• [S2] The patient clicks on the name of the LHCP for an expired prescription, and is presented with the contact information for that LHCP (including First Name Last Name, LHCP Type, Street Address 1, Street Address 2, City, State, Zip Code, Phone, and Contact Email); if any type of contact information is missing or the whole contact information for the LHCP is not available in the database, the corresponding missing types of information are simply shown as blank.

The event is logged [UC5, S32]

The HCP has authenticated himself or herself in the iTrust Medical Records system [UC2 3].

The HCP chooses “My Patients with Potential Prescription-Renewal Needs” and is presented with a list of patients [S2] that satisfy ALL of the three conditions: (1) patients for whom the HCP is a DLHCP, (2) chronic special-diagnosis-history patients [S1], (3) patients whose prescriptions will expire within 7 days (including the 7th day) from the current date (i.e., (currentDate < = expiredDate < = (currentDate + 7 days)). The event is logged [UC5, S33] (after the patient list is displayed).

• [S1] A chronic special-diagnosis-history patient is an alive patient who has been diagnosed with at least one of the following:
  • diabetes mellitus [is diagnosed with ICD code beginning with 250: http://icd9cm.chrisendres.com/icd9cm/index.php?action=child&recordid=1894],
  • asthma [is diagnosed with ICD code beginning with 493: http://icd9cm.chrisendres.com/icd9cm/index.php?action=child&recordid=5000], or
  • circulatory-system disease [is diagnosed with an ICD code between 390 and 459 inclusive: http://icd9cm.chrisendres.com/icd9cm/index.php?action=child&recordid=4314].
• [S2] The patient list is titled with the HCP's name. The patient list includes the patient's name (i.e., first name and last name), phone number, and contact email address [E1, E2] (so that confirmation calls or emails can be made or sent outside of the iTrust system). The list is sorted based on the ascending alphabetical order of the patients' last names, and then first names. When a chronic special-diagnosis-history patient satisfies all three conditions and has multiple prescriptions satisfying the third condition, the patient is listed in the list only once. The list is a static list with no link on the patient's name, phone number, or contact email address)

• [E1] If there are no patients satisfying the three conditions, an empty list is presented.
• [E2] If any type of contact information is missing in the database, the corresponding missing types of information are simply shown as blank. (this flow is deleted since Data Field Formats 3.1 stated that the mentioned contact info here is mandatory)

http://www.patentstorm.us/patents/7286996/fulltext.html

A LHCP is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

A sending HCP refers a patient to another receiving HCP [S1]. A receiving HCP reviews pending consultations [S2]. A sending HCP reviews the consultation sent back by the receiving HCP [S3].

• [S1] An HCP chooses to refer a patient to another receiving HCP. The sending HCP is presented with a drop down menu of his patients and another drop down menu of other HCPs. When the patient and receiving HCP are chosen, the HCP is presented with the MID of the patient that will be sent to the receiving HCP. The sending HCP is also presented with a text box to include the details of the referral to be sent to the receiving HCP. The sending HCP then chooses to send the request or to cancel [E1, E2]. The status of the consultation being sent is set as “pending”. After the consultation is sent, the event is logged [UC5, S34]
• [S2] An HCP chooses to review pending consultations. The receiving HCP is presented with a list of pending referrals. The receiving HCP then selects a referral to view details and is presented with the MID of the sending HCP, the patient MID, and the referral detailsreason for the consultation. The HCP is also presented with an option (“finish”, “decline”, “pending” with “pending” as default value) to mark the status of the consultation and a text box to enter the details of the consultation. The receiving HCP can then choose to confirm the status setting/consultation entering or cancel.
• [S3] An HCP chooses to review patient consultations referred by the HCP and already entered by the receiving HCPs. The HCP is presented with a list of referrals that were sent by him and whose statuses are “finish” or “decline”. Each referral includes the patient MID, receiving HCP MID, referral details, and consultation details.

• [E1] The patient chosen is not the desired patient. The HCP does not confirm the selection and is prompted to try again.
• [E2] The receiving HCP chosen is not the desired HCP. The sending HCP does not confirm the selection and is prompted to try again.

A LHCP, UAP, or patient is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

An LHCP or UAP creates a list of patients (by MID) for which he or she will monitor remotely [E1, S1]. A patient inputs his or her blood pressure and glucose levels throughout each day [S2]. An LHCP can see the blood pressure and glucose levels for the patients he or she is monitoring [S3]. A UAP [S5] or patient representative [S6] can input the blood pressure and glucose levels for a patient. A patient may have up to 10 data points in any one day, reported by him/herself, a UAP, or a personal representative [E4]. All events are logged [UC5,S35].

• [S1] An LHCP or UAP can add and delete patients from his or her monitoring list. A patient is added to the list by the LHCP or UAP typing in the patient's MID [E1] or name. An LHCP can delete a patient from his or her monitoring list by the LHCP typing the the patient's MID [E1]. In both cases, the LHCP is presented the name of the patient and must confirm the add/delete.
• [S2] A patient choose to report their status. He or she can report their blood pressure (systolic and diastolic) [E2] and/or glucose levels [E3]. The input data and a timestamp and that fact that the status is “self-reported” are saved.
• [S3] An LHCP chooses to view their monitoring. The LHCP is presented with a listing of all his or her patients with their blood pressure and glucose levels, time recorded timestamp, and whom reported the data (patient, UAP name, personal representative name). Patients with no information for the current day are highlighted. Patients with blood pressure or glucose level out of range are highlighted (normal blood pressure: systolic 90-140; diastolic 60-90; normal glucose 70-150). The LHCP can select a patient to obtain additional information about a patient [S4].
• [S4] An LHCP selects to view additional information for a patient. The LHCP is presented with a screen upon which he/she can choose a date range. Once the date range is selected, the LHCP can see the patient name; patient phone number; personal representative (name and phone number), if applicable; and the blood pressure and glucose levels as well as whom reported the data (patient, UAP name, personal representative name) for that date range.
• [S5] A UAP can select to report physiologic measurements. He/she is presented with a list of the patients for which he/she is allowed to report measurements. He she can select a patient and then enter data. He or she can report the blood pressure (systolic and diastolic) [E2] and/or glucose levels [E3] for the patient. The input data and a timestamp and that fact the the status was reported by “case manager” and their MID are saved.
• [S6] A patient can select to report physiologic measurements for those for whom they are patient representatives. He/she is presented with a list of the patients for which he/she is allowed to report measurements. He she can select a patient and then enter data. He or she can report the blood pressure (systolic and diastolic) [E2] and/or glucose levels [E3] for the patient. The input data and a timestamp and the fact that the status was reported by “patient representative” and their MID are saved.

• [E1] The patient chosen is not the desired patient. The HCP does not confirm the selection and is prompted to try again.
• [E2] The patient, UAP, or personal representative enters a systolic blood pressure outside the range 40-240 or a diastolic blood pressure outside the range 40-150. He/she is notified of an error and is prompted to try again.
• [E3] The patient, UAP, or personal representative enters a glucose level outside the range 0-250. He/she is notified of an error and is prompted to try again.
• [E4] The patient, UAP, or personal representative tries to enter more than ten data points for one day and is told additional data cannot be entered.

US Department of Health and Human Services Remote Monitoring Use Case: http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848114_0_0_18/RMonDetailed.pdf

A patient is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

A patient selects to reports an event related to a prescription drug [S1] or immunization [S2] reaction. The event is logged [UC5; S36].

• [S1] A patient is presented with a listing of all prescription drugs for which he/she has been prescribed and/or has taken in the last 12 months. The patient chooses one or more drug(s) for which to report the adverse event. The patient is then able to write a textual description which describes the symptoms of the adverse event and to save the information. A fake email is sent to the LHCP who prescribed the medication indicating the patient name and MID, drug, and symptoms.
• [S2] A patient is presented with a listing of all immunizations for which he/she has been administered in the last 12 months. The patient chooses the immunization for which to report the adverse event. The patient is then able to write a textual description which describes the symptoms of the adverse event and to save the information. A fake email is sent to the LHCP who administered the immunization indicating the patient name and MID, drug, and symptoms.

US Department of Health and Human Services Consumer Adverse Event Reporting Use Case: http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848115_0_0_18/CAERFinalExtGap.pdf

A patient or public health agent are a registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3]. The event is logged [UC5, S38].

A public health agent selects a specific time period for which he/she would like to see a detailed listing of all adverse events related to prescription drugs [S1] or immunizations [S2] or to see trends in adverse events relate to prescription drugs [S4] or immunizations [S5].

• [S1] A public health agent is presented with a listing of prescription drug-related adverse events for the time period that do not have a status of “removed”, sorted by NDC. The public health agent can select to see the detail of a specific report. Upon reading the report, the public health agent can choose to send a “fake email” message to the adverse event reporter to gain more information about the report. The public health agent may also choose to remove an adverse event report (such as based upon communication with the reporter or because the report appears to be bogus) [S3].
• [S2] A public health agent is presented with a listing of immunization-related adverse events for the time period that do not have a status of “removed”, sorted by CPT code . The public health agent can select to see the detail of a specific report. Upon reading the report, the public health agent can choose to send a “fake email” message to the adverse event reporter to gain more information about the report. The public health agent may also choose to remove an adverse event report (such as based upon communication with the reporter or because the report appears to be bogus) [S3].
• [S3] The adverse event report changes to a status of “removed.” A message of the removal is sent to the adverse event reporter and to the LHCP involved in the report (because the LHCP prescribed the drug or administered the immunization).
• [S4] The public health agent chooses a time period and a drug (NDC). The public health agent is presented with a bar chart giving the quantity of non-removed drug-related adverse events for this drug by month.
• [S5] The public health agent chooses a time period and an immunization (CPT). The public health agent is presented with a bar chart giving the quantity of non-removed drug-related adverse events for this drug by month.

US Department of Health and Human Services Consumer Adverse Event Reporting Use Case: http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848115_0_0_18/CAERFinalExtGap.pdf

An LHCP is registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

The LHCP selects to prescribe a patient a drug by selecting its NDC and name [S1, S2]. Upon notice of allergies and interactions the LHCP proceeds with the prescription [S3] or the the use case begins again to allow the LHCP to choose another drug or the LHCP abandons the use case. If a prescription is completed, the event is logged [UC5, S37].

• [S1] The drug desired to be prescribed is checked against the patient's drug allergies. The LHCP is notified of drug allergy.
• [S2] The drug desired to be prescribed is checked for interactions between other drugs currently taken by the patient. The LHCP is notified of possible interactions.
• [S3] The patient is sent a “fake email” that the LHCP has prescribed a medication that he/she is allergic to or that has a known interaction with a drug he/she is taking.

US Department of Health and Human Services Medication Gaps Use Case: http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848121_0_0_18/MedGapFinalExtGap.pdf

An admin is a registered user of the iTrust Medical Records system [UC2]. The iTrust user has been authenticated in the iTrust Medical Records system [UC3].

The administrator records [S1] or deletes [S2] a drug interaction between two prescription drugs.

• [S1] The administer is presented with two lists of NDC codes/names. The administrator chooses a drug from each list to record an interaction between the two drugs [E1] The two drugs and a textual description of the possible effects of the interaction are stored.
• [S2] The administrator selects one drug and is presented with a listing of all drug interactions with that drug. The administrator can select a particular pair of drugs and delete the interaction between the two drugs.

• [E1] The administrator has chosen the same drug from both lists. The system directs the user to make a different choice.

US Department of Health and Human Services Medication Gaps Use Case: http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848121_0_0_18/MedGapFinalExtGap.pdf

Implementation must not violate HIPAA guidelines.

The system shall enable multiple simultaneous users, each with his/her own exclusive authentication.

The form validation of the system shall show the errors of all the fields in a form at the same time.

A report is a page which opens in a separate window and contains minimal decoration. The format is printer-friendly in that the background is white and the information does not exceed the width of 750 pixels so that upon printing, no information is lost due to the information being too wide.

The system shall have a privacy policy linked off of the home page. The privacy policy should follow the template provided here: http://ecommerce.ncsu.edu/studio/templates/privacy_tem.doc

Remove MID from being displayed on all pages and URLs. MIDs should be considered private, sensitive information.

The system shall be implemented as a Java Server Page web application.

The implementation shall adhere to the Java Coding Standards.

All new code shall be documented using the Javadoc documentation system.

The implementation shall run on the Windows platform in the Eclipse 3.3 environment.

All non-GUI classes must have at least 80% unit testing/JUnit coverage of tests that pass.

To control open connections to the database, all database access should be done through an object that uses the Singleton pattern.

The implementation must use the Strategy pattern for epidemic detection and cause-of-death trends and the Singleton pattern for database connections.

The application should have no true positive Severe or Medium FindBugs errors.

Transaction Types

Order of these entries does not matter.

The following information must be maintained

Table 6.4.1

Additionally, a history of the following information must be maintained

Table 6.4.2

From: http://www.webmd.com/hw/diabetes_1_2/uq1456.asp

• Family history of type 1 diabetes (mother, father, sister, brother)
• Ethnicity: Increase risk for Caucasian people.
• Viral infections during childhood (less than 18 years old): echovirus (ICD9cm 079.1) and Coxsackie B (ICD9cm 079.2)

From: http://www.webmd.com/content/article/59/66831

• Age over 45.
• Ethnicity. The risk of diabetes is greater in Hispanics, African American, American Indians, and Asians.
• Being overweight. If you are overweight, defined as a body mass index (BMI) greater than 25.
  • Assume any height and weight are in inches and pounds, respectively.
  • With the English system, calculate BMI by dividing weight in pounds (lbs) by height in inches (in) squared and multiplying by a conversion factor of 703.
• Hypertension. High blood pressure increases the risk of developing diabetes.
  • Systolic blood pressure over 240 mmHg and/or a diastolic blood pressure over 120 mmHg.
• Abnormal cholesterol levels. HDL (“good”) cholesterol levels under 35 mg/dL (milligrams per deciliter) and/or a triglyceride level over 250 mg/dL increases your risk.
• Prior diagnoses. History of gestational diabetes, polycystic ovary disease (PCOS) or vascular disease
• Family history of type 2 diabetes (mother, father, sister, brother)

From: http://www.webmd.com/content/pages/9/1675_57840

• Gender. Men have greater risk than women.
• Age. Over 45
• Ethnicity. The risk of heart disease is greater in African American, American Indians and Hispanic Americans.
• Obesity. If you are overweight, defined as a body mass index (BMI) greater than 30.
  • Assume any height and weight are in inches and pounds, respectively.
  • With the English system, calculate BMI by dividing weight in pounds (lbs) by height in inches (in) squared and multiplying by a conversion factor of 703.
• Hypertension. High blood pressure increases the risk of developing diabetes.
  • Systolic blood pressure over 240 mmHg and/or a diastolic blood pressure over 120 mmHg.
• Abnormal cholesterol levels. HDL (“good”) cholesterol levels under 35 mg/dL (milligrams per deciliter) and/or a triglyceride level over 250 mg/dL increases your risk.
• Smoking. Current or prior smoker
• Prior diagnoses. Diabetes.
• Family history of heart disease (mother, father, sister, brother)

Either the HCP Medical Identification Number or the hospital is required.
Note: Date/Time can be timestamps.

see Test Data for examples

All fields are optional.

Version 12

Andy Meneely

Date: December 22, 2007

Change Desc.

• Moved the requirements over to a wiki, see version control on wiki to see history

To see previous revision history, see Version 11 of the requirements

Version 13

Laurie Williams

Date: September 8, 2008

Change Desc.

• Added subflow 29 to UC5
• Added three flows to UC6
• Added addition transactions to UC12 (UC23-28)
• Added UC28

Version 14

Laurie Williams

Date: October 16, 2008

Change Desc.

• added emergency responder role (UC 2, 15, 21)
• removed ability to restrict access to certain diagnoses (UC 7, 10, 11, 26)
• added ability to create dynamic health history of chronic illness and cause of death (UC 9, 10)
• added ability to track immunizations (UC 9, 11, 17)
• made prescription report more streamlined and user friendly (UC 19)
• added ability to message between patient and HCP
• removed MID from pages and URLs

Version 14.1

Laurie Williams

Date: October 22, 2008

Changed UC21 from listing all prescriptions given in the last 90 days to the following: A list of all prescriptions the patient is likely to be currently taking as determined by the end date of the prescription has passed by 91 days or less. Display the National Drug Code and the name of the prescription. Sort by most recent first.

Version 15

Tao Xie

Date: January 28, 2009

Added UC31 for Find LHCPs for prescription renewal Use Case.

Version 15.1

Tao Xie

Date: February 18, 2009

Added UC32 Proactively Confirm Prescription-Renewal Needs Use Case.

Version 15.2

Ben Smith

Date: July 26, 2009

• Added updated, legible use case diagram (pending corrections)
• Updated references to standards codes.