Use Cases, Requirements, and Workflows—Clinical Swift Series, III

by Jerome Carter on December 14, 2015 · 0 comments

After last week’s aside into the data vs. processes dilemma, it is time to get back to how one defines requirements for a clinical care system.  Requirements gathering has to proceed along a few different paths simultaneously, and for any completely new system, it is a messy activity.  There are four main requirement pathways: user interface (UI), functions/features, data, and non-functional.

UI requirements are best collected using an interface mock-up or simulator—the “a picture is worth a thousand words” concept.  Data requirements often start with forms; however, electronic systems often have data requirements that exceed what can be gleaned from forms.  For example, keeping an audit trail for a form requires meta-data that are not obvious from the form itself.  Non-functional requirements address the infrastructure that a software system needs to perform optimally.  Security, response times, scalability, etc., are examples of non-functional requirements.  Functional requirements, those that address what the system must be able to do, along with UI requirements, depend heavily on user input to get them right.

Since any clinical system will have many functional requirements, a systematic means of collecting and organizing them is essential.   In the realm of object-oriented analysis and design, use cases are the starting point for collecting functional requirements.

Here is the clearest definition of a use case I have come across (1):

A use case is a technique for capturing the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific goal.


Notice that use cases emphasize interactions and goals.  Use cases are a type of workflow!!! In case the reason for the three exclamation points is not obvious, allow me to explain.   The dilemma over choosing between processes and data does not have to mean a permanent parting at some arbitrary fork in the road.   Every use case is a workflow, and in fleshing out use cases, one has time to determine if the system under design must be process-based.  Many of you reading this may be asking how use cases are like workflows.  If so, the likely source of your confusion is how uses cases are presented in the informatics literature. 

Use cases are narratives that detail the steps a user performs when interacting with a system.  Use cases have a specific starting point and a specific stopping point.  Between these two points are the specific interactions—ergo, use cases are workflows.  Use cases should have a formal name and description (i.e., “add a new patient”; “This use case covers the addition of a new patient to the prn: CIM-OnCall database”). Sometimes use case names are given in a shortened form (“New Patient”), and the narrative describing the steps is omitted, which obscures the process aspects.  However, now you know (if you did not before)  what a use case is,  and that is what matters. 

prn: CIM-OnCall keeps track of off-hours patient contacts.  As such, it is necessary to add new patients to the app.  Below is the use case for this function.

Use Case Name: Add new patient
Description: Describes the process for adding a new patient to prn: CIM-OnCall

  1. New patient calls
  2. Clinician accesses app
    1. Selects “New Patient”
    2. Enters patient’s Last Name
      1. System displays all patients with same or similar last names along with MR#
      2. Clinician reviews list and determines whether patient is already in system
        1. If in system
          1. Selects patient
        2. If not in system
          1. Resume adding demographics
      3. Add First Name
      4. Add MedRecNo
        1. Add location for MedRecNo (office, hospital, etc.)
        2. System checks if MedRecNo already in database for location given and patient with same Last and First Names
          1. If in System
            1. Flag patient for review of possible duplicate
          2. If not in System
            1. Resume adding demographics
      5. Add Gender
      6. Add Date of Birth
      7. Add Phone Numbers
      8. Add Email Addresses
      9. Add Introductory Note (optional)
      10. Save patient
        1. Patient added to database

This use case begins with a patient call and ends when the system adds the patient to the database. 

From a workflow standpoint, two workflows are presented—the user’s interaction with the system and the system’s actions.   Some system actions are automatic (it always displays a list of patients with similar names) and some are triggered by the clinician (accepting entered data).

However, for both the clinician and the system, much occurs that is not explicitly listed.  For example, the system will have validation routines for all data entered for both data quality and security purposes.  Likewise, for the clinician, there may be additional checks for information obtained from the patient (e.g., looking up the exact name of the hospital they were discharged from earlier).   Details can be added to make the use case more detailed for extracting requirements. 

Looking at use cases is one way of seeing the design differences between data-centric (DC) and process-centric (PC) systems.  A major feature of process-centric systems is their awareness of the next step.  PC systems have a sense of state.  As such, a PC system knows the next step and what data are required because those steps are made explicit in a workflow model.  Workflow models can be examined and altered (from a console or dashboard perhaps) if a new system behavior is required.  In DC systems, these behaviors are compiled into code.  The only way to change them would be to have a programmer write or alter code, then recompile the app.  PC system changes are much easier to effect than those for DC systems.

The similarities between workflows and use cases can be exploited in a few ways.  The most obvious is that any use case can be used to create a sub-process in a workflow model.  Doing so would require rendering the use case in a workflow language (e.g., BPMN or YAWL), which points to a second exploitable feature—use cases can be studied and created using a formal workflow notation.  Often,  I have lamented the lack of crossover among the groups involved in clinical care software design (see Workflows with Friends).  Well, use cases are a specific point where these groups could meet. 

Use cases are a starting point for gathering requirements, and going over the scenarios in a use case can help to identify every requirement type. In the New Patient use case, UI requirements are present in terms of patient list displays and data entry requirements.  Data requirements appear in the form of information collected from the patient. Finally, non-functional requirements will be evident in the form of HIPAA security conformance (e.g., app should log-out clinician after a specified time period).   While these requirements may not be obvious from the above use case, continued interactions with clinicians during the design process would bring them out.   

Requirements are the step before coding starts, so they have to be detailed in order to be useful to programmers.  In the next post, I will discuss how to get those details. 

See you next year!

1. McLaughlin BD, Pollice G, West D. Head First Object-Oriented Analysis and Design. 2006

Facebooktwitterpinterestlinkedinmail

Leave a Comment

{ 0 comments… add one now }

Previous post:

Next post: