MD: physician using the system.

Nurse: nurse using the system

MOA: Medical Office Assistant

Admin: System Administrator

Project Owners and other members

User is logged in

The acronym CAVE was developed to describe common activities for clinical elements:

• Create - ability to create a new instance of the particular element (eg adding a new patient to the system)
• Archive - Archive is used instead of delete as a robust audit trail will be needed for any clinical information system. No clinical elements will be deleted from the system.
• View - some users will not have the ability to edit certain items, but may need to be able to view aspects of the summary.
• Edit - The ability to update a section. As with archive, audit trails will be kept for all edits. Therefore all edits will, essentially, be a copy and change to the specific element and not a true edit of the content. This will apply to all elements in the server system including: patient data, demographic data and user data.

Use Cases with a PDA component will have a PDA icon attached and additional notes. Some PDA specific use cases are also described if they have no desktop equivalent. For the sake of these use cases, the editing functionality on the PDA is described. NOTE: at this time the editing patient summaries on a PDA is out of scope of this project. These are left in for future work and to remind the PDA development team of where we want to go in future iterations.

The sysadmin module contains use cases for the management of the system including adding users, managing user passwords, etc.

CAVE system user: the system must have the ability to manage users in the system. Like clinical data, users should not be able to be deleted from the system as they will be tied to activities in a record. This is particularly important when one needs to review audit trails, etc.

User data that will need to be captured here should reflect all the information that the system needs to have for authentication, privacy, role definition, etc plus information to support the management of users in the clinic (ie phone numbers, etc).

Essential

Rarely

Admin

1. A new / existing user of the TAPAS system will need to be registered / viewed / archived / edited in the system. User name, role, access and passwords will need to be set.

2. Create:
   • Use Name
   • User ID (NOTE: this will be provided by the system and will not be editable as it connects to the rest of the system)
   • Address
   • City
   • Province / State
   • Postal / Zip code
   • Country
   • Telecom
   • Telecom #
   • Prefix
   • Given Name
   • Family Name
   • Suffix
   • Organization (Name of the Clinic / Office)
   • A new user will be given one of the roles / user profiles (MOA / Nurse / Physician / Sysadmin)
   • Password (see ADMUSR-02 request new password below)
     

3. Archive: a user account can be deactivated if the user leaves the practice. The account will not be deleted.

4. View: view user settings

5. Edit: edit user settings

6. When a system user has been successfully CAVE'd, the use case has ended.

Request a new user password. A user may forget his or her password from time to time. This needs to be considered by the system and provide the sys admin the ability to reset / request a new password. A process will be needed to provide the temporary password to the user that is secure.

Essential

Admin, (any actor)

1. For some reason, a user needs to enter a new password

2. The system admin asks the user to enter and confirm a new password

3. The password is successfully updated.

4. This ends this use case.

• NOTE: no admin should be able to see ANY password!

CAVE PDA accounts. Some users will have a PDA account - that is a PDA that will be assigned to the server and to their own account that will be able to sync to the PDA for syncing of personal messages and patient summaries (and future patient data).

Essential

Rarely

Admin

1. A new / existing PDA account (on the TAPAS system) will need to be registered / viewed / archived / edited in the system.

2. Create:
   • A PDA is synced to the system server using a secure "Initiation of PDA" protocol.

3. Archive: a PDA account can be deactivated when the user leaves the practice or a PDA is lost. The account will not be deleted.

4. View: view PDA account settings

5. Edit: edit PDA account settings

6. When a PDA account has been successfully CAVE'd, the use case has ended.

CAVE Module Elements: TAPAS is to be designed as a modular system where new modules can be added to an instance from a library of TAPAS modules as they are created. In the first iteration, all modules will be added and active. in future iterations, modules for various targeted conditions can be added (eg management of maternity care, management of diabetic patients, etc).

Medium

Rarely

Admin

1. A new / existing TAPAS system module will need to be added / viewed / archived / edited (portlet?)
   Adding or Archiving will typically happen at a users' request / consensus (?)

2. Create: a new module element (portlet) can be added to TAPAS by the system admin

3. Archive: an existing module element (portlet) can be removed from the TAPAS portal server. The module will remain available for eventual re-introduction.

4. View: view module element settings

5. Edit: edit module element settings

6. When the module element has been successfully CAVE'd, the use case has ended.

• This use case was formerly known as "Manage Modules"  (TUFKAMM)

Update / install software to a physician's PDA

Essential

Weekly

Admin

1. There is either a system-wide reason for installing / upgrading the PDA TAPAS-related software, or

2. The physician(s) in case requests another PDA software install / upgrade This would include the installation of content in the form of eBooks that are readable on the PDA

3. The document(s) / application(s) are installed on the server to be deployed to all PDAs in the group.

4. PDA users sync to the server and during the sync applications are loaded automatically.

5. When the PDA software has been successfully installed / updated, the use case has ended.

• There is an error on installation:
  • Insufficient memory
  • Application not compatible
  • Sync incomplete

Register a PDA: before being used, a PDA must be securely registered to a user account. Without this manual process that requires activation from the trusted sys-admin, the user will not be able to get information from a server account to their PDA. This

Essential

Rarely

Admin

1. When a new MD starts with the practice OR the MD receives a new PDA, it will have to be registered

2. The System Admin enters the PDA information (serial number) and the MD's name (either a admin module needs to be built for that or it is done on paper) and copies that on a form (PDA lend-out agreement form)

3. The System Admin and the MD both sign the PDA lend-out agreement form

4. THe System Admin stores one copy and hands one copy to the MD

5. The System Admin hands out the PDA to the MD

6. When the PDA is registered and handed out, the use case has ended.

• In case of a new MD, the system admin goes on to Use Case UC-ADMUSR-01 and UC-ADMUSR-04 (CAVE new user and CAVE new PDA account)
• In case of just a new PDA, it might be necessary to change PDA connection settings

This collection of Use Cases describes the management of patient information and the workflows of elements like referrals, etc that are managed by the medical office assistant. The key distinction here is that core clinical elements of the record / summary are not modified by the user. Elements like demographics, address, status of a referral are managed.

CAVE a patient record. Patients need to be added to the system and when they are, their record must be created . This use case describes the creation of new patients in the system, as well as managing their demographic data by any clinical user (MD, MOA, Nurse, etc).

Searching for a patient record is described in the View aspect of this use case.

Essential

Several times a day

MOA, MD

1. A new patient attending clinic will need to be registered in the system; patient records need to be archived in case of a patient leaving the clinic; patient data can be viewed an edited

2. Create: typically, a new patient will be added to the system on their first appointment. They will be asked to fill out a paper form in the waiting room and this will be handed to the MOA who registers the patient. Registration includes filling in demographic data, health card number, etc and storing / committing this in the system. 

   1. The first step is Initialization: A new ID is generated for this record and user who creates the record fills in the data set.
   2. The current care provider (family doctor) is determined for the patient
   3. Data captured in the demographic section includes:
      
   • Personal Health Number for province
   • Province code
   • Other ID type
   • ID #
   • Address
   • City
   • Province / State
   • Postal code / zip code
   • Country
   • Telecom type
   • Telecom # (f.i. "Telephone" and "tel nr")
   • Prefix
   • Given name
   • Family name
   • Suffix
   • Gender
   • Date of birth
   • Preferred language
3. Archive: when a patient leaves the practice, it is noted in the patient's record that this now concerns an Archived patient record. Records are not to be deleted.
4. View: viewing patient (demographic) data (demographic data, health card number, etc)

• The user searches for a patient by a number of methods: by name fragment, birthday, by health number, etc.
• From a list of possible patients, one is selected
• The patient summary is shown when they are selected.
• The list remains open so the provider can quickly move to another patient, in case the first selected patient was in error.
• The user closes the search window and continues with their activity.
• NOTE: on the PDA the screen will be too small. Therefore, this will have to be a single screen and the search will need to be remembered so the user can return to this list in case the tap the wrong patient.

1. Edit: Over time patient information will need to be updated in the system: people move, change MDs, phones, additional information becomes available.
   EITHER: Patient notifies the clinic staff or MD that their demographic data has changed.
   OR: Front office staff asks patient about demographics, if there is an update, the MOA enters patients (demographic) screen
   User / MOA will interrupt current task (which may be booking appointment, managing the clinical record, etc) and edit the patient information (demographic data, health card number, etc)
   User confirms changes to demographics, and commits update to patient record (demographics sections)
2. When a patient record has been successfully CAVE'd, the use case has ended.

• A patient may be partially registered over the phone with the remaining data filled in over time.
• Other provider is notified that demographic data is out of date during the normal delivery of care (eg writing a prescription, ordering a lab test, etc) and needs to update the demographics before continuing.

• Thinking about the patient records in terms of demographic / administrative data vs clinical data: I think that the basic patient record holds the patient (system) ID plus the administrative / demographic data. All clinical data are also in this patient's record (medical summary), but are only accessible to MDs / nurses
• NOTE: We will need to explore how to interface with existing billing and scheduling systems. Implementation of interfacing with billing systems is out of scope for the first iteration.
• NOTE again: This use case concerns ONLY the basic demographic / administrative (non clinical) patient data!
• NOTE encore: updating demographic data cannot lose the position of the other workflow.

Patient cover sheets are important in a paper-based practice or in a hybrid practice. The system should be able to print out an up to date cover sheet. This could be used to attach to the front of a paper chart or a number of other clinical tasks. The cover sheet would include demographics as well as the core medical summary.

This becomes less useful as a provider moves to a paperless practice but is key to a hybrid practice.

Expected

Many times a week

MOA, MD

1. Whenever a cover sheet is needed (to attach to a paper chart or whatever) the user / MOA is able to print a patient cover sheet at the click of a button.

2. The system has a cover sheet template; gathers all the necessary patient data and sends it to a printer

3. The patient cover sheet is printed out and manually attached by the user / MOA to whatever it is needed for.

4. When patient cover sheet is attached to whatever it was needed for, the use case has ended.

• We'll also need cover sheet template editing capabilities of some sort

• THis is a special instance of Print Medical Summary

This system will still existing in a paper / electronic hybrid environment and label printing will be essential to the smooth running of the office. The system should support common label shapes from an easy interface. Labels will need to be printed so they can be used for patient requisitions such as: Name, Date of Birth, Age, Address, phone number, health ID, GP name, GP College ID.

Expected

Daily

MOA, MD

1. Whenever patient labels are needed the user / MOA is able to print these at the click of a button;

2. The system has a standard label template (or templates);

3. The user selects one or more patients and the number of labels that have to be printed;

4. The user puts (a) label page(s) in the printer OR selects a label printer if one exists in the practice ;

5. The system gathers all the necessary patient data and sends the lot to a printer;

6. The patient labels are printed out

7. When the patient labels have been successfully printed, the use case has ended.

• Printer is out of paper
• no printer attached to the client desktop computer

• We'll also need label template editing capabilities of some sort

Patient summaries are important in a paper-based system or in a hybrid system. the system should be able to print out an up to date medical summary.

This would be used, for example, to give to the patient for them to keep with them or to keep at home. It would capture their summary information plus the information of the patient's GP in an "If you need to contact this patient's GP, please contact..."

Expected

Many times a week

MOA, (+ ???)

1. Whenever a summary is needed the user / MOA is able to print a patient summary at the click of a button;

2. The system has a standard summary template; gathers all the necessary patient data and sends it to a printer;

3. The patient summary is printed out

4. When the medical summary has been successfully printed, the use case has ended.

• We'll also need summary template editing capabilities of some sort

• The details of the print out will need to be worked out.

Patient summaries will need to be exported from TAPAS to other systems for a variety of reasons, including: patient moving, system upgrades, physicians moving to another office.

Electronic migration of the patient data is, therefore, critical to allow these necessary tasks in managing the healthcare data.

The system must be able to support the exporting of EMS data to other systems on a per patient basis or in a batch process.

Batch process needs to filter on a group of patients by physician or by name.

The eMS export will only capture a current snapshot of the patient. The current eMS standard does not support the exporting of the complete data set, therefore this system will only support the data set as per the eMS standard.

Expected

Occasionally

MOA

1. The MOA enters the "Export Patient Summary" screen
2. Searches for a patient(s)
3. Selects the patients
4. Presses Export patients button
5. Picks the location for the storage of the export file(s)
6. The files are exported to the location specified on the client machine. An alert notifies the user if any files are being overwritten.
7. The user is reminded that these files must be protected as they contain patient information and deleted as soon as they are no longer needed.

• The system needs to alert if there is insufficient write privileges and / or there is not enough space on the drive.

This section pertains to the management of the referral process (thus the "meta" in the title). These use cases pertain primarily to office staff who need to maintain the list of specialists and manage the referrals that are in process. The creation of individual patient referrals is documented in use case XXX.

One of the tasks that the practice manages on a daily basis is referrals to specialists. These referrals follow certain workflows and have to be followed up regularly. Considerable time is spent each day managing referrals in a busy practice. As referrals to be written inside the TAPAS|ems system, it is expected that the MOAs are also supported in the management of referrals.

The MOAs and other users should be able to manage the status of referrals of a selected patient electronically in a way that supports their current practice and saves them time.

This Use Case refers to the management of the referrals of a single patient. management of a collection of workflows is described in use case CLAREF-02

Expected

Daily

MOA , MD

1. element cardinality: 0..n

2. The user selects a patient in the system;

3. The user selects the 'view referrals' function;

4. The system presents a list of referrals of the selected patient. The referral list shows:
• Referral Date
• Who referred (MD who wrote the referral, this will be filled in automagically)
• importance (elective, routine, urgent, emergent)
• Who they were referred to: name and specialty
• Status (see below)
• Appointment Date
• Last Update Date
• Referral Manager (NOTE: This is the user who has been given / taken responsibility for the referral)
5. The user can view the details of the referral by clicking on a specific referral and change the status of the referral.
• Status can be changed to the following:
  • Referral Needed
  • Referral Written
  • Awaiting Specialist Response
  • Need to contact patient
  • Patient to book appointment
  • Appointment confirmed
  • Referral completed
  • Referral Archived
• Status comments can be added to the status - these may include free text comments like "message left at home" etc
6. This concludes this use case.

• All referrals will be kept on the server.
• Referrals will not be copied to the PDA. (NOTE: it is quite possible that the users will want to see a list of specialists a patient has been referred to on the PDA - this would be quite handy, in fact and we need to keep in on the radar for future development).

One of the tasks that the practice manages on a daily basis is referrals to specialists. These referrals follow certain workflows and have to be followed up regularly. Considerable time is spent each day managing referrals in a busy practice. As referrals to be written inside the TAPAS|ems system, it is expected that the MOAs are also supported in the management of referrals.

Referrals to other specialists have a particular workflow. The referral management system needs to support that workflow, allowing MOAs to review outstanding referrals that they are responsible for and change their status based on updates from specialists and patients.

Expected

Often

MOA

1. element cardinality: 0..n

2. Reviews current referrals that are active - can filter based on referral status, GP, specialist being referred to and by the referral manager.

3. Opens an existing referral by clicking on the referral.

4. Reviews the status while viewing the referral information (eg specialist phone number)

5. Acts on the referral status (eg calls the specialist for confirmation).

6. Changes the status of the referral if applicable.

7. Saves the referral.

8. When the changes to the referral status have been committed to the system, the use case has ended.

• NOTE: DO: talk about setting up a reminder system where items that are due will be flagged for the person.
  Need to sit down with an MOA to see how closely this matches their workflows.

The list of specialist to whom can be referred has to be maintained. This module allows the user to do that. Key information that will be updated will be: name, address, phone, fax, specialty, and staff names.

Expected

Monthly

MOA

1. The user chooses the Manage Specialist List function

2. The user either chooses to add a specialist;

3. or to edit an existing one;

4. The user commits the changes to the system

5. This concludes this use case.

• This list will be shared by the members on the practice server. That is, if one user updates / adds a specialist, all others will benefit from this update / addition.
• At this time only a single list will be maintained for the clinic. Personal lists will not be supported in the first iteration. If there are a significant number of requests, this will be considered in future versions

A common task of medical office assistants and nurses is to request a prescription refill of the physician. These use cases describe this process which should be supported in this system.

This function allows the MOA or nurse to request a refill for (an) existing prescription(s) to an MD.

Essential

Multiple times a day

MOA (+ nurse)

1. A request for a refill comes to the attention of the MOA or nurse. This can come from a number of sources:

   1. A patient attending clinic asks for a refill of (an) existing prescription(s);
   2. A patient phones requesting a refill be faxed to the pharmacy
   3. The pharmacy phones requesting a refill on behalf of the patient as the prescription is about to expire and the patient cannot get into see the MD in time.

2. The user starts the 'UC-CLAPRE02: View Rx' function for this patient;

3. The user selects the Rx(s) in question

4. The user selects an MD to send the message to

5. The user presses the Send Refill Request button;

6. A message is sent to this MD (NOTE: this can be selected from a pick list of MDs, the list defaults to the patients' MD), who has to process the refill in function UC-CLMPRE07
   

7. This concludes this use case.

• There will probably be a link with UC-CLAPRE-02: View RX

This function allows the user to view the patient's active prescriptions Rx PLUS the RxHx (history of prescriptions). it is an key function of a system to allow the user to review medications that a patient is taking. This use case has been separated out as MOAs and nurses are not able to edit the prescription.

Essential

Multiple times a day

MOA, MD, Nurse

1. Whenever the user needs to view a patient's Rx / Rx Hx, the user can select the 'View Rx' function for that particular patient;

2. The system displays the Rx history of the patient;

3. the user can select either the actual or a historical Rx and zoom in into the details

4. This concludes this use case

• The View Rx module can be pulled into other modules, such as the view patient summary or others so prescriptions can be seen when clinically relevant.

A diverse collection of use cases for the management of the system and various clinical / admin tasks such as messaging between providers, etc. These use cases do not discribe the maintenance of any particular patient information.

Administrate the call schedule. The call schedule is the schedule of physicians in a practice who are "on call" for evenings and weekends.  This schedule will need to be edited and accessed on a regular basis by members of the team.

Med. 

Daily - view, weekly - edit

MOA, MD

1. Whenever there is need to change the call schedule the user activates the 'Admin Call Schedule' function;

2. The system displays the call schedule;

3. (The system provides the user with a drop-down list of MDs)

4. The user does the changes to the call schedule;

5. The user commits the changes to the call schedule;

6. The MD(s) in case are notified of the updated schedule

7. When the notifications have been sent AND the changes committed to the system, this use case has ended.

NOTE: Can use the iCalendar system set up for NSMobile for version 1.  Therefore, this may not be integrated into TAPAS initially.

Proper communication is an important part of the workflow in an office. One way to support this workflow is to provide electronic messaging. This use case describes the CAVEing (Create / Archive / View / Edit) of secure messages between providers and users of the system.

PDA: This messaging will be integrated with the PDA so that users can write messages on the PDA and sync them to the server. Messages will be synced bidirectionally.

Expected

Multiple times a day

MOA, MD

1. Create: new messages to other users can be written and sent ;

   1. User(s) is/are selected
   2. A title is written
   3. A message body may be written
   4. The message is sent to the receiving user to by picked up in their in box.

2. Archive: sent messages are stored. Messages are not to be deleted. Archive messages can be viewed later and unarchived. Archived messages will not be stored on the PDA.

3. View: messages that have been sent or received by the user can be viewed later at any time;

   1. The system will flag unread messages
   2. The user can filter messages based on read / unread / archive status.
   3. The user can sort messages based on date, name, and status

4. Reply / forward - NO deleting

   1. Users will be able to easily reply to a message (the title and body will be copied like it would in an email system).
   2. Forward - messages may be forwarded to other users (the title and body will be copied like it would in an email system). The prefix FWD: will be added to the message title.
      
5. When a message has been successfully CAVE'd, the use case has ended.

• Messages sync to the PDA.  Archived messages do not sync to the PDA.  They are stored on the server and can be viewed if the user selects "View Archived Messages"
• It would be a good function to have, especially on the PDA, some "quick text" titles and message templates. This can be explored with some of the users and the Palm's built in "ShortCuts" to see what might be useful before implementing within the system.

The Patient Module contains use cases that pertain to the general management of patient clinical data. Management of this data is restricted to "clinician" users - MDs, nurses, etc. Some of the more detailed modules are described in their own categories. Future modules may be described with expansion of the system.

Users will have to be able to access patient records quickly and intuitively through a search feature from wherever they are in the system. This is a "targeted" clinical information system and will contain onlyl a subset of the patient population for a practice or group. It is not expected in a targeted system, such as TAPAS, that all patients will be recorded in the information system. There will not be a scheduling system for patient encounters in this version of TAPAS. Therefore, the main way of accessing patients will be through a search interface. This interface must be quick and efficient and intuitive to the user.

PDA: On the PDA the user must be able to search for patients as well.

Essential

Multiple times a day

MD

1. Whenever the user sees a patient (or has another reason to access the patient record), the user opens the patient record in the system;

   1. A search screen is entered first and the user can search by name, PHN, ID#
2. Selecting from a list, the patient's record is opened. Depending on the user, the default view will vary:
   1. Clinicians (MDs and Nurses) will open to the medical summary
   2. MOAs will open to the patient demographics

3. For clinicians (MDs and Nurses) when the medical summary is opened, a message is sent to EGADSS (see use case UC-CLMEGA-01: EGADSS actor) which replies with the patient's recommendations; (DESKTOP ONLY)

4. This concludes this use case.
   

• Do we record Medical Imaging history? Cardinality: 0..n

A function to CAVE the Problems portion of the medical summary. Active problems are the list (with description / comments) of current, active conditions that the clinician feels are significant to document in the chart / summary. For example, hypertension is a chronic condition with many ramifications on the patient's health status and should be documented. A "cold" in an otherwise healthy 22 year old may not be significant enough to document in the cumulative summary as it is self limiting. Pneumonia in a frail 92 year old would be worth documenting if they were headed to the hospital and could be archived when the pneumonia resolved. Problems that are no longer active can be archived.

During the arcive process users will need to be able to have the option to "move" the problem to past medical history or not.

PDA: The PDA must have the ability to CAVE active problems.

Essential

MD (Nurse)

1. Cardinality: 0..n

2. Create: the user enters a Problem for this particular patient

1. Select Date of Onset (will default to today's date, but the user will be able to document the date of previous conditions).
2. Diagnosis Category - based on coding system (ICD-9)
3. Add additional details as comments - these are important to provide some extra detail and richness to the summary. NOTE: some categorical coding systems will not capture the correct diagnosis, so these will have to captured in the comments section.
   • Coded elements can be looked up using specified vocabularies for each section
3. Archive: the past Problems are archived automatically - not deleted. 
• Archived problems can be flagged for inclusion into the Medical Hx section during this process.
  NOTE: It is expected that most significant "active problems" that are archived will become part of the the significant past medical history in a summary, however, not all will.
• Problems are archived when the user sets an end date and that date is in the past.
4. View: the system can produce a list of past/archived Problems and these can each be viewed by the user.
• There will need to be two views on each module: a brief and a robust.
• The brief will show what is needed clinically as part of the general summary:
  • Problem Category / Start / Comments
• The robust view will provide the user with more details and the ability to manipulate the list view in more ways:
  • The robust view will show: the above list plus: creation date, last modified date, and most recent author.
  • The list can be filtered on a variety of criteria such as active / inactive status, start date / end date
  • The user will be able to review previous versions of the item on a detail item that will let them scroll through the historical entries to the system on that problem (ie review the audit trail) on the desktop. This could have clinical significance is key comments describe why elements have changed over time.
5. Edit: If the information changes, then this needs to be reflected.  All changes need to be recorded in an audit trail in the system.  Essentially these would be appended to the record.
6. Provider signs off on the updates / additions. NOTE: any changes to the system will be stored with audit information - ie who hanged what elements and when. this will allow for the proper tracking of historical data.
7. When the problem has been successfully CAVE'd, this use case has ended.

• updating the medical summary should never result in lost work during the visit.
• Coded elements will be coded using ICD-9 to support the current eMS standard.
• **Coded elements will always have a key associated with them in case the coding system is changed in the future.
• The very basic scheme will be used here for problem elements. Over time, users may well dictate additions to the problem list description that may be incorporated into future versions.

For the medical Hx list, each element should document a medical diagnosis that the clinician feels is an important part of the patient's history. To CAVE these elements is as you would CAVE a generic element of the medical summary. For the sake of this document this will be described in more detail here. the comment field must be available for users to add comments to the medical history that may be helpful in delivering care.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

Daily

MD (Nurse)

1. Element Cardinality: 0..n
   

2. Create: Elements can be created if the user has sufficient privileges. This should be created on the same screen as viewing the summary (ie summary evidence should not be lost on the screen when an additional element is added). The user will need to be able to document the following categories:
   

   • Diagnosis (from a structured vocabulary) - in this case ICD-9
   • Date of Onset
   • Date of Resolution
   • Comments - comments (free text) are important to provide more detail. not only in the case of the capturing additional clinical richness about an issue, but also to capture information that is not properly captured in the categorical coding systems.
3. • Coded elements can be looked up using specified vocabularies for each section.
   • A free text option is available to add supporting information to the element (eg family history - details can be added about a given condition, etc).

4. Archive: Elements can be archived, removing them from the active list. When archived the user should be prompted to put in a reason for archiving the item. In the case of a historical element, this will not happen often, but it will be important to allow for this if, for example, the wrong element is recorded either by accident or by error in the history (i.e. the historical reference is improved with more details or corrected).

5. View: The list elements can be viewed as part of the medical summary. There will be a brief and robust view

6. Edit: Editing should also occur from the same screen. The above elements can all be edited. The user will have the option to save the changes, committing them to the record (and having an audit trail stored in the process).
7. provider signs off on the updates / additions. . NOTE: any changes to the system will be stored with audit information - ie who hanged what elements and when. this will allow for the proper tracking of historical data.
8. When the problem has been successfully CAVE'd, this use case has ended.

updating the medical summary should never result in lost work during the visit.

The surgical history section of the summary captures details of the procedures performed on the patient. These would include any invasive procedures such as tissue or organ removal, surgical repair, etc. This would not include procedures such as diagnostic imaging which occur elsewhere in the summary. This will capture the basic procedure code and the date it was performed. The free text comment field can be used for extra details such as the surgeon who performed the procedure and for comments about the procedure if needed.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

Daily

MD (Nurse)

1. element cardinality: 0..n

2. Create: Surgical Hx elements can be created if the user has sufficient privileges. This should be created on the same screen as viewing the summary (ie summary evidence should not be lost on the screen when an additional element is added). The user will need to be able to document the following categories:
   

   • Procedure Code (ie the code that describes the surgical procedure). Medical diagnoses, if relevant, may be captured in the medical problems section.
   • Date of procedure
   • Comments - comments (free text) are important to provide more detail. not only in the case of the capturing additional clinical richness about an issue, but also to capture information that is not properly captured in the categorical coding systems.
   • Coded elements can be looked up using specified vocabularies for each section in the TAPAS|Reports Module.

3. Archive: Elements can be archived, removing them from the active list. When archived the user should be prompted to put in a reason for archiving the item. In the case of a historical element, this will not happen often, but it will be important to allow for this if, for example, the wrong element is recorded either by accident or by error in the history (i.e. the historical reference is improved with more details or corrected).

4. View: The list elements can be viewed as part of the medical summary. There will be a brief and robust view

5. Edit: Editing should also occur from the same screen. The above elements can all be edited. The user will have the option to save the changes, committing them to the record (and having an audit trail stored in the process).
6. provider signs off on the updates / additions. . NOTE: any changes to the system will be stored with audit information - ie who hanged what elements and when. this will allow for the proper tracking of historical data.
7. When the surgical Hx has been successfully CAVE'd, this use case has ended.

updating the medical summary should never result in lost work during the visit.

Family history documents the medical conditions that the clinician feels are important from the patients genetic family. These are important conditions that may have an impact on the current patient.

Conditions such as diabetes, heart disease, and some cancers are important. They can increase the patient's risk of these conditions and / or change the management of the patient (increase screening, trigger more aggressive treatment).

It is important to document, beyond the normal elements for a module, the family member who is affected by relationship to the patient.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

Daily

MD (Nurse)

1. element cardinality: 0..n

2. Create: Family Hx elements can be created if the user has sufficient privileges. This should be created on the same screen as viewing the summary (ie summary evidence should not be lost on the screen when an additional element is added). The user will need to be able to document the following categories:
   

   • Diagnosis - ICD-9
   • Family Relationship type (PLEASE REVIEW A STRUCTURED LIST FOR THIS FROM THE EMS DATA)
   • Condition description
   • Age of onset
   • Age of death
   • Cause of death
     
   • Comments - comments (free text) are important to provide more detail. not only in the case of the capturing additional clinical richness about an issue, but also to capture information that is not properly captured in the categorical coding systems.
3. • Coded elements can be looked up using specified vocabularies for each section using the standard look up approach for TAPAS.
   • A free text option is available to add supporting information to the element (eg family history - details can be added about a given condition, etc).

4. Archive: Elements can be archived, removing them from the active list. When archived the user should be prompted to put in a reason for archiving the item. In the case of a historical element, this will not happen often, but it will be important to allow for this if, for example, the wrong element is recorded either by accident or by error in the history (i.e. the historical reference is improved with more details or corrected).
   
   Whenever a patient leaves the clinic, the record is archived, but not deleted

5. View: The list elements can be viewed as part of the medical summary.

6. Edit: Editing should also occur from the same screen. The above elements can all be edited. The user will have the option to save the changes, committing them to the record (and having an audit trail stored in the process).
7. provider signs off on the updates / additions. . NOTE: any changes to the system will be stored with audit information - ie who hanged what elements and when. this will allow for the proper tracking of historical data.
8. When the family Hx has been successfully CAVE'd, this use case has ended.

• updating the medical summary should never result in lost work during the visit.

• NOTE: Family Hx is NOT supported on Level 3 of the Ems

Social history includes elements of a patient's life that are more related to behaviour. These can include housing, exercise, substance abuse, etc.

Documentation will be the same as other sections: code, start date, end date, free text comments.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

Daily

MD (Nurse)

1. Cardinality: 0..n

2. Create: Social Hx elements can be created if the user has sufficient privileges. This should be created on the same screen as viewing the summary (ie summary evidence should not be lost on the screen when an additional element is added). The user will need to be able to document the following data:
   

   • Risk-type:
     
     • Housing
     • Exercise
     • Smoking
     • Drinking
     • Substance abuse
   • Risk start and end dates
   • for version 1 of TAPAS the coding system for social history will be a limited set of ICPC-2e that focuses on social and psychological problems
     
   • Comments - comments (free text) are important to provide more detail. not only in the case of the capturing additional clinical richness about an issue, but also to capture information that is not properly captured in the categorical coding systems.
   • Coded elements can be looked up using specified vocabularies for each section.
   • A free text option is available to add supporting information to the element (eg family history - details can be added about a given condition, etc).

3. Archive: Elements can be archived, removing them from the active list. When archived the user should be prompted to put in a reason for archiving the item. In the case of a historical element, this will not happen often, but it will be important to allow for this if, for example, the wrong element is recorded either by accident or by error in the history (i.e. the historical reference is improved with more details or corrected).

4. View: The list elements can be viewed as part of the medical summary.

5. Edit: Editing should also occur from the same screen. The above elements can all be edited. The user will have the option to save the changes, committing them to the record (and having an audit trail stored in the process).
6. provider signs off on the updates / additions. . NOTE: any changes to the system will be stored with audit information - ie who hanged what elements and when. this will allow for the proper tracking of historical data.
7. When the Social Hx has been successfully CAVE'd, this use case has ended.

• updating the medical summary should never result in lost work during the visit.

MDs within a group practice (or virtual group practice) need a method of communication about patients. TAPAS will support two modes of communication: provider to provider (messaging) and Patient Condition Flags (PCFs). PCFs are designed to provide an active alerting system for pending "to do" elements for a specific patient while care is shared, particularly while on call. for example, if something needs to be followed up while on call (i.e. a patient is in the hospital) that can be documented within an active flag

It is expected that these flags will become more robust in the future, allowing for a variety of alerts and reminders to be tagged to patient charts. For now they will be a simple flag that will allow for author, date activated, category, room for text comment, and a flag for active / inactive (archived).

inactive / archived flags can we seen in the patient summary history but are not synced to the PDA, nor are they shown in lists of active flags.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

Daily

MD/ Nurse

1. element cardinality: 0..n

2. Create: A Patient Flag element can be created if the user has sufficient privileges. This should be created on the same screen as viewing the summary (ie summary evidence should not be lost on the screen when an additional element is added). The user will need to be able to document the following in a patient flag:

   • Set Status (eg Urgency - a subjective number from 1-5)
   • Set Active Date
   • Document Title (Title will be displayed in the list of Patient Flags)
   • Associate flag to a particular problem (this would be a drop down of existing problems) OPTIONAL
   • Comment - comments (free text) are important to provide more detail of the patient flag.
   • Category: Patient Flag is used as a default and hidden from the user. Future flags may be considered for follow up, etc.

3. Archive: Patient Flags can be archived when completed or no longer needed, removing them from the active list. When archived the user should be prompted to put in a reason for archiving the item.

4. View: The list elements can be viewed as part of the medical summary. On the patient's summary screen active flags only are viewed by title. A robust view is available that can show archived elements and flag history.

5. Edit: Editing should also occur from the same screen. The above elements can all be edited. The user will have the option to save the changes, committing them to the record (and having an audit trail stored in the process).
6. provider signs off on the updates / additions. . NOTE: any changes to the system will be stored with audit information - ie who hanged what elements and when. this will allow for the proper tracking of historical data.
7. When the Patient Flag has been successfully CAVE'd, this use case has ended.

MDs will need to review existing, active patient condition flags in a list format. This will act as a to do list and will need to be available on the desktop AND the PDA.

This list will only show active flags. Tapping on a flag will allow the user to CAVE that element.

Essential

Daily

1. open the Active Patient Flag Summary section of the system (on the PDA or the Desktop)

2. View titles of all active flags in a table that includes:
   • Patient Name
   • Date of Birth
   • Title of the Patient Flag
   • Urgency of the Flag
3. User is able to sort flags based on any heading
4. User can select a single flag to view more details. From the view page, the user can edit (eg update) the flag and set it to be archived if it is completed. User can also create a new flag during this process.
5. When the patient flag screen is exited, this use case ends.

Referrals are communications with other MDs, typically specialists (eg surgical) or specialist GPs (eg addictions or obstetrics) when the MD wants to have a second opinion / diagnostic support / therapeutic suggestions / or a transfer of care. Typically, a referral requires a note of some kind from the MD to the specialist. The more detailed the note, the more helpful to the MD. However, due to the time constraints in practice, referral notes often do not have all the information they could have. Much of the information that is needed in the referral note is duplicated from the chart and medical summary.

The referral process should support the workflow of the MDs and write most of the referral by pulling out information from the current medical summary (patient demographics, problem list, medical, surgical, family history, medication, allergies, etc) as well as information about the MDs (address, phone numbers, etc of both the referring and referred MDs). The MD will need to write a note describing the specifics of the reason(s) for referral and any extra detail not captured in the summary.

The status of the referral will need to be set as well by the MD.

Current workflow will be paper based; however, future workflows will need to support health authority electronic procedures when they are established (through the e-MS standard).

Essential

Daily

MD (Nurse)

1. Create: Open New Referrals

2. Select Reason for Referrals

3. Select Referrer from a pick list (this will be broken down by specialty and then by specialist and will auto-populate contact information, address, etc)

4. Write note for referral - this will be brief as the medical summary will populate much of the referral letter -- patient information, demographics, problem list, medications, etc etc. This free text box will allow the user to capture their thoughts quickly and will not require significant duplication.

5. The referral status will be set automatically to first level (see UC-CLMREF-02), although this may be adjusted by the user, if appropriate.

6. The user prints out the referral for paper processing. 
   ** In the future, the e-MS CDA standard will be used to allow for electronic referrals to occur.
   

7. Archive: Referrals are automatically stored / archived in the system once completed.

8. View: It is possible for the user to pick and view a past Referral

9. Edit: The MD can edit a referral - in the case of a change of specialist (the original specialist is not taking on new patients, etc). Through the course of the referral, details may change on the patient history, requiring an updated referral. NOTE:  Referrals can be edited, however, an audit trail will be kept of all changes. 

10. When the referral has been successfully CAVE'd, this use case has ended.

• Once a broker strategy is worked out in VCH to handle e-MS referrals, the option to send the referral note electronically will be provided

The prescription writer will allow MDs to view and manage the daily tasks of medication management in a practice.

The use cases are broken down into component parts so that they can be re-used in the design. It is envisioned that the actual workflow will be a continuous and smooth process.

For version one of TAPAS, we will be using the Health Canada Drug Database (provided with permission for use by UBC in our projects by Health Canada).

MD writes medication prescription for a patient. Choice of medication should be by generic name or by trade name (with generic as the preference). this should be as easily searchable as the patient list.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

10-20 times / day

MD

1. Medications element cardinality: 0..n

2. Searches for Medication (can search by generic (ie active ingredient) or by brand name) by typing in some letters of the name of the medication.  NOTE: It would be ideal if the search would work with a wildcard and also looks for the text phrase embedded in the name.

3. The Drug Identification Number is recorded by the system
4. The Other Name of this drug is recorded

5. The system searches for the medication based on the above criteria

6. The user confirms the medication

7. Date for patient to begin taking this medicine

8. The user then goes to UC-CLMPRE-02 Picking Dose (mg + # tablets)

9. This concludes this use case

• Medication not found in drug database: MD must have the ability to add custom instructions / custom formula for medications (eg specific creams, etc).

MD writes medication prescription for a patient -- picking Dose. Ideally the system will suggest to the user the common dosages of a medication.  This should reduce errors. however, the health Canada database likely does not categorize its information in a way that will allow us to provide this. We will have to look more closely at this when we begin building this module.

number of tablets should be a combo box that allows for common number of tablets (1/4, 1/2, 1, 1.5, 2, 3, 4, and 5 tablets would cover most medications). The user should have the ability to adjust if needed in some manner if it does not fit the drop down box.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

10-20 times / day

MD

1. Based on the picked medication, the system presents the standard dosages for the medication;

2. The user chooses the desired dosage from a picklist ;

3. Dose override: MD must have the ability to override and manually enter own dose ;

4. The user confirms the dose ;

5. The user then goes to UC-CLMPRE-03 Picking Frequency

6. This concludes this use case

MD writes medication prescription for a patient -- picking Frequency.

Common frequencies will be presented in a pick list and the user can overwrite their own.  Common frequencies include: 

• OD - once a day
• BID - twice a day
• TID - three times a day
• QID - four times a day
• Q24h - once every 24 hours
• Q12h - once every 12 hours
• Q8h - once every 8 hours
• q6h
• q4h
• q3h
• q2h
• Common Ranges:  Q6-8H, q4-6h, q3-4h

This is required and could default to the medication's recommended frequency is possible otherwise there should be no default as we do not want to recommend to the user an inappropriate frequency.

The system should also support the "as needed" flag (PRN) for medications that should be used only "when needed".  The PRN flag supports the frequency rates above (ie Q6h PRN = as needed up to a maximum dose of every six hours). These should be taken from the eMS standard.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

10-20 times / day

MD

1. Based on the picked medication, the system presents the standard frequencies for the medication;

2. The user chooses the desired frequency from a picklist ;

3. Frequency override: MD must have the ability to override and manually enter own frequency ;

4. The user confirms the frequency ;

5. The user then goes to UC-CLMPRE-04 Picking Route

6. This concludes this use case

MD writes medication prescription for a patient -- picking Route.

Common routes will include: PO, topical, SC, IM, IV, Inhaled, Nasal, PR, etc. These should be available from a pick list and specific to the medication if possible.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

10-20 times / day

MD

1. Based on the picked medication, the system presents the standard route for the medication;

2. The user confirms the desired route ;

3. The user then goes to UC-CLMPRE-05 Picking Duration

4. This concludes this use case

MD writes medication prescription for a patient -- picking Duration

Duration can be defined in two ways -- by total number of doses or by number of days.  Some MDs prescribe in different ways.  We should consider supporting both. Default to days. No default on the numeric component in this version.

Refills: non-negative integer. Defaults to 0 refills. Alerts if >12 refills.

PDA: The user must have the ability to CAVE these elements on the PDA and sync changes to the server.

Essential

10-20 times / day

MD

1. Based on the picked medication, the system presents the standard duration for the medication;

2. The user chooses the desired duration from a picklist ; This should be specified by # of doses / # of days / # of weeks / # of months.

3. The user chooses the desired #refills from a picklist ;

4. Frequency override: MD must have the ability to override and manually enter own duration time / #refills ;

5. The user confirms the duration ;

6. The user then goes to UC-CLMPRE-06 Print Rx

7. This concludes this use case