Requirements Document v2€¦ · Requirements Document v2.1 Adviser:Sunny Wong Stakeholder:Siemens Healthcare / Robert Neff Group Members:Brian Courtney Daniel Huynh Daniel Molander

Requirements Document v2.1

Adviser: Sunny WongStakeholder: Siemens Healthcare / Robert Neff

Group Members: Brian CourtneyDaniel HuynhDaniel MolanderMichael McLaughlinSunny Patel

Table of Contents 1 Document Information..........................................................................................................1

1.1 General Information.......................................................................................................................1 1.2 Revision History.............................................................................................................................2 1.3 Related Documents........................................................................................................................3

2 Introduction............................................................................................................................ 4 2.1 Purpose...........................................................................................................................................4 2.2 Definition of Terms........................................................................................................................4 2.3 Overview........................................................................................................................................6 2.4 Scanning Technology.....................................................................................................................6 2.5 Scope..............................................................................................................................................6 2.6 Focus..............................................................................................................................................6 2.7 Ashvin EHR....................................................................................................................................8

3 Functional Requirements.......................................................................................................9 3.1 Requirements Priority Scheme.......................................................................................................9 3.2 User Stories..................................................................................................................................10

3.2.1 Must Have Priorities............................................................................................................10 3.2.1.1 Launching the Client Application.................................................................................10 3.2.1.2 Availability of Video Source.........................................................................................10 3.2.1.3 Searching the Environment for a Barcode....................................................................11 3.2.1.4 Acquiring a Barcode.....................................................................................................12 3.2.1.5 Processing a Barcode....................................................................................................13 3.2.1.6 Displaying Information.................................................................................................15

3.2.2 Should Have Priorities.........................................................................................................17 3.2.2.1 User Login....................................................................................................................17 3.2.2.2 Processing Medications Detected in the Environment.................................................17

3.2.3 Could Have Priorities..........................................................................................................19 3.2.4 Deferred Priorities...............................................................................................................20

3.2.4.1 Searching the Environment for Medication Administration Routes.............................20 3.2.4.2 Processing Medication Administration Routes.............................................................21

3.3 Graphical User Interface (GUI)....................................................................................................23 3.3.1 Launching the Client Application........................................................................................23

3.3.1.1 The Ashvin Main Screen...............................................................................................23 3.3.2 Display of Information.........................................................................................................24

3.3.2.1 Patient Information.......................................................................................................24 3.3.2.2 Patient Prescription.......................................................................................................25 3.3.2.3 Input of Medication into System..................................................................................26

4 Non Functional Requirements.............................................................................................28 4.1 Hardware......................................................................................................................................28 4.2 Security.........................................................................................................................................28 4.3 Reliability.....................................................................................................................................28 4.4 Durability.....................................................................................................................................28 4.5 Speed............................................................................................................................................28 4.6 Portability.....................................................................................................................................28 4.7 Expandability...............................................................................................................................28 4.8 Testability.....................................................................................................................................28 4.9 Documentation.............................................................................................................................29

4.9.1 Software Requirement Specifications Document..................................................................29 4.9.2 Design Document.................................................................................................................29 4.9.3 Acceptance Test Plan Document..........................................................................................29

5 System Evolution..................................................................................................................30

Table of FiguresFigure 1: Main Screen with Prescription List..........................................................................................23Figure 2: Main Screen with Scan Results................................................................................................23Figure 3: Expanded View of Patient Information Display (Shown Next to Video Feed)........................24Figure 4: Collapsed View of Patient Information Display (Shown Next to Video Feed)........................24Figure 5: Patient Prescription List View with Medication Details Showing...........................................25Figure 6: Scan Results View....................................................................................................................26Figure 7: Video Feed with Red Box.........................................................................................................27

Table of TablesTable 1 : Ashvin Requirement Document General Information................................................................1Table 2 : Ashvin Requirements Document Revision History....................................................................2Table 3 : Implementation Methods for Scanning Identification Information into an Electronic System..6Table 4 : Functional Requirements Priority Scheme.................................................................................9

Ashvin Software Requirement Specifications Document Document Information

1 Document Information 1.1 General InformationTable 1 shows general information regarding the Ashvin Requirements Document.

Version v2.1

Title Ashvin Software Requirement Specifications Document

Authors Michael McLaughlin, Daniel Molander, Dan Huynh, Sunny Patel, Brian Courtney

Reviewers Michael McLaughlin, Daniel Molander, Dan Huynh, Sunny Patel, Brian Courtney

Table 1 : Ashvin Requirement Document General Information

1


1.2 Revision HistoryTable 2 shows the revision history the Ashvin Requirements Document.

Version Date Editor(s) Commentsv2.1 04/28/14 Michael McLaughlin Added screen shots and added some

requirements to go with them.v2.0 03/24/2014 Michael McLaughlin Changed requirements to reflect new

direction of project and fixed formatting errors.

v1.7 02/04/2014 Michael McLaughlin, Daniel Molander, Dan Huynh, Sunny Patel, Brian Courtney

Completed the missing contents and formatted style and layout.

v1.6 02/01/2014 Daniel Molander Added non-functional requirements.v1.5 01/03/2014 Michael McLaughlin Started adjusting functional

requirements to match them up with the test cases being created in the Acceptance Test Plan.

v1.4 01/02/2014 Michael McLaughlin Added description of different types of scans.

v1.3 12/29/2013 Michael McLaughlin Converted functional requirement structure/use cases to user story structure. Created user stories.

v1.2 12/22/2013 Michael McLaughlin Added use cases. Restructured headings. Added priority definitions.

v1.1 12/20/2013 Michael McLaughlin Added figures in GUI section, as well as configured captioning/Table of Figures.

v1.0 12/17/2013 Michael McLaughlin Initial draft / outline of document.

Table 2 : Ashvin Requirements Document Revision History

2


1.3 Related DocumentsThe following documents contain further information related to this document.

• Ashvin abstract – Abstract Google doc.

• Ashvin Acceptance Test Plan Document – Ashvin_Acceptance_Test_Plan.pdf.

• Ashvin Design Document – Ashvin_Design.pdf.

3

Ashvin Software Requirement Specifications Document Introduction

2 Introduction 2.1 PurposeThis document outlines the functional and non-functional requirements of the Ashvin WorkflowMonitoring System.

2.2 Definition of Terms• Active Scanning System – Electronic system where the clinician present in a patient care

setting explicitly scans his/her environment for input. E.g., a nurse explicitly clicks a button on a hand held scanner to read a barcode. See also: Passive Scanning System.

• Android – Mobile operating system maintained by Google. See also: Mobile Device, Smart Device.

• Barcode – Machine readable label placed on an object used to import data into a computer. Barcodes can be read optically via a LASER scanner or a camera.

• Clinician – Hospital staff member, typically a nurse or doctor, charged with patient care.

• Electronic Health Records (EHR) System – Hospital storage system for patient information. In regards to this document, the term EHR refers to the mock database designed to showcase the Ashvin scanning system. EHR data is usually stored in an HIS.

• Five Rights of Medication Administration – Medical industry standard for ensuring the accurate administration of medication to a patient. The rights are:

◦ Right Patient◦ Right Medication◦ Right Dose◦ Right Time◦ Right Route of Administration

• General Route – A medication general route refers to the manner of administration for the medication. An example of an incorrect general route would be if a patient has to receive a medication in pill form as per the medication's instructions but receives the medication in liquid form.

• Google Glass – Interactive glasses worn by a person that allows him/her to digitize the world around him/her through the use of an attached camera. The glasses also display information onto the glasses for the wearer to view as if looking at a computer monitor.

• Graphical User Interface (GUI) – Interface used by a user to graphically interact with a hardware or software system.

• Healthcare Information System (HIS) – The hospital database system containing information

4


such as the EHR of a patient, among other healthcare data.

• Image Recognition – Technology involving optical recognition by a computer of a real world object.

• Information Technology (IT) Administrator – Person charged with administrative duties regarding a computer system.

• Infrared (IR) – Wavelength of light just outside of the visible range.

• Intravenous (IV) Medication Administration – Route of administering medication to a patient via the vein using a needle.

• Medication Administration Time – The time when a medication either is or has to be administered to a patient. For the purposes of this document, Medication Administration Time is assumed to be defined to have certain tolerances in each direction of time prior to patient care such that if a clinician administers a medication to a patient at 11:59 PM and the prescription calls for the medication to be administered at 12:00 AM – technically the next day – the administration event is not recognized as an error by Ashvin.

• Mobile Device – A digital device contained on the person of a user and used to receive output from the EHR or video source, as well as to input information into the EHR.

• Passive Scanning System – Electronic system where the devices present in a patient care setting autonomously scan their environments for input without the need for a human to initiate the scanning processes, named so because the clinician on duty has an passive role in regards to scanning data. E.g., a computer program parses live camera images for barcodes and scans them into the computer on its own. See also: Active Scanning System.

• Prescription – Formal, physician implemented medication plan directly related to a given patient.

• Radio Frequency Identification (RFID) – Wireless system for passing information between objects using an RF.

• Real-time Locating Systems (RTLS) – System used to identify and track objects in a live environment. An RTLS may be implemented via RFID, IR, or other form of technology.

• RF – Radio Frequency.

• Smart Device – See Mobile Device.

• Specific Route – An example of an incorrect specific route would be if a patient has to receive a medication via IV form in a specific IV but receives the medication in the incorrect IV.

• User – Any person, typically a clinician or IT administrator, who uses that Ashvin system.

5


2.3 OverviewThe Ashvin Workflow Monitoring System is a software-based solution used to monitor a patient care setting. The system is an RTLS that consists of one or more input technologies used to detect pertinent patient care related data that exist in a particular care setting. Ashvin v2.1 currently features a mock EHR in lieu of an interface to an actual hospital HIS. The mock EHR is used as a vehicle to showcase the passive data collecting capabilities of the system. Future releases will be capable of interfacing with a hospital HIS.

2.4 Scanning TechnologyTable 3 shows common technologies typically used to scan real time information into a computer system. Ashvin uses active and passive scan barcode systems.

Scan Type Description Transfer Technology

Barcode: Active Scan

The user explicitly scans a barcode into the client using an active system. Camera or LASER

Barcode: Passive Scan

System autonomously scans a barcode using a passive system. Camera

RFID: Passive Scan

System autonomously reads in an RFID signal using an passive system. RF

Table 3 : Implementation Methods for Scanning Identification Information into an Electronic System

2.5 ScopeThis document describes the software requirements for the Ashvin Workflow System. Attention is given both to the requirements needed to implement a passive scanning system and the GUI that provides a clinician access to the system.

The intended audience of this document includes software developers and end-users, specifically the clinicians and IT administrators who will work with the software.

2.6 FocusPrimary focus of the Ashvin Workflow Monitoring System is on the input of patient identification data, as well as the medications associated with the patient, into the HIS present in the care setting using a passive scan system. This focus leads to an effective implementation of the first two of the Five Rights of Medication Administration, Right Patient and Right Medication. Proper identification of objects in the patient care setting also leads to implementation of Right Route of Administration, however image recognition technology that can accurately recognize clinician activity is not currently available.

Ashvin's passive scan system detects information about a patient and medication dynamically. Use of a passive system provides the clinician on duty freedom to focus his/her attention on patient care without

6


having to scan barcodes into his/her mobile device.

Most image recognition software libraries currently available implement an active system in that the user needs to line up and focus an image on a mobile device screen and then explicitly click a button to scan the item in the question. There are no readily available libraries that can achieve the passive scanning required of the Ashvin Workflow Monitoring System. It is for this reason that design of Ashvin focuses primarily on the complex algorithms needed to passively scan information into the system, with tertiary focus on the alert system that processes the scanned data. The Ashvin passive scan requirements are broken down into three main components.

1. Search – The client must passively search for what appears to be an object of interest in the patient care environment.

2. Acquisition – The client must resolve whether a detected object is or is not an object of interest.

3. Process – The client must process an object of interest once it has been resolved.

The Must Have Search, Acquisition and Process requirements are detailed in section 3.2.1 Must HavePriorities.

Two passive scanning technologies are listed in Table 3, one that utilizes barcodes and another that employs RFID technology. While passive scanning RFID exists and is in widespread use in many professional environments, it is disadvantageous in small areas such as hospital rooms. In particular, discrimination of which bed a clinician is paying attention to is not readily achieved with RFID. In addition, RFID can not be used to identify whether a clinician is crushing pills before administering them to his/her patient. Since Ashvin must eventually meet the need for discriminating this type of action in the future in order to fully implement the Right Route of Administration line item of the Five Rights of Medication Administration, RFID is not currently supported by the system.

Image recognition, while not as widespread and easy to implement as RFID, is a passive system potentially capable of not only recognizing objects such as medication bottles or patient wristbands, but activities such as the crushing of pills. The need for a smart and extensible system is the catalyst behind the decision to focus Ashvin on passive scanning.

Since medication administration alerts can not be effectively processed without accurate data, the image recognition algorithms responsible for obtaining the data from a patient care setting must be accurate. The complexity of the image recognition-based passive system mandates lesser focus on the alert system that will be attached to Ashvin in the future. The alert system is responsible for the Right Dose and Right Time line items of the Five Rights of Medication Administration. Requirements related to Right Dose and Right Time are currently Should Have requirements and remain the focus of future releases of Ashvin.

7


2.7 Ashvin EHRThe Ashvin mock EHR, described in detail in the Ashvin Design Document, is a basic database used to showcase the scanning abilities of Ashvin. It features basic information such as patient and medication information that is pertinent to a scanning event, such as a patient or medication identification number, patient and medication name, a patient's current list of prescribed medications, etc. Constraints on access to an actual hospital HIS during development mandate the use of this system. However, future versions of Ashvin will interface directly with an actual hospital HIS.

8

Ashvin Software Requirement Specifications Document Functional Requirements

3 Functional RequirementsThe Ashvin system implements, at minimum, one of the technologies defined in Table 3 of section 2.4 Scanning Technology.

3.1 Requirements Priority SchemeEach Ashvin functional requirement is assigned a priority which dictates how important it is that the requirement be implemented. Priorities are defined in Table 4.

Priority Description

Must Have Requirement must be successfully implemented as agreed upon by all parties before the software is released.

Should Have Requirement is not expected to be implemented with first release but expected to be implemented with next release.

Could Have Requirement is not judged to be in the scope of the current design. Requirement may be implemented within a future release.

Deferred Requirement was originally judged to be in the scope of the current design but was set aside for future considerations.

Table 4 : Functional Requirements Priority Scheme

9


3.2 User StoriesThe functional requirements of the Ashvin system are described as user stories. This section describes each user story. Each user story is assigned a unique identifier for reference purposes. User stories are organized by priority. Priorities are defined in section 3.1 Requirements Priority Scheme.

3.2.1 Must Have PrioritiesThe Must Have priority requirements listed in this section represent features that must be present in the first release of the Ashvin Workflow Monitoring System. These requirements are responsible for basic client features and the implementations of the scanning system that make patient and medication scanning possible.

3.2.1.1 Launching the Client Application

FR-001 Launching the Client

As a clinician, I want to launch the Ashvin client so that I can access the Ashvin system.

Priority Must HaveAssumptions The Ashvin client application is installed on the mobile device on which it is to

run.

3.2.1.2 Availability of Video Source

FR-003 Availability of a Video Source to the Ashvin Client

As a clinician, I want the Ashvin client to access a video input source so that I can actively or passively scan objects present in the patient care setting.

Priority Must HaveAssumptions • The clinician can launch the Ashvin client application as per FR-001.

• A video feed is accessible to the mobile device running the client.

10


3.2.1.3 Searching the Environment for a Barcode

3.2.1.3.1 Detecting a Patient

FR-007 Passive Detection of a Patient in Environment Via BarcodeAs a clinician, I want the Ashvin client device to autonomously detect the patient closest to me so that I can focus on patient care without having to explicitly scan information into the client.


• The client has access to a video source as per FR-003.

3.2.1.3.2 Detecting a Medication

FR-002 Passive Detection of a Medication Bottle in Environment Via Barcode when Medication Is Not in the Center of the Video FeedAs a clinician, I want the client device to autonomously detect a medication bottle that is not directly in front of me so that I don't have to look away from the task that I am currently doing in order to scan a medication into the client.

Priority Must HaveAssumptions • The user can launch the Ashvin client application as per FR-001.

• The client is connected to a video source as per FR-003.

FR-008 Passive Detection of a Medication in Environment Via Barcode within Four FeetAs a clinician, I want the client device to autonomously detect a medication within four feet of me so that I can focus on patient care without having to explicitly scan medications into the client.



11


FR-024 Passive Detection of a Medication Bottle in Environment Via Barcode with Bottle Turned On Its SideAs a clinician, I want the client device to autonomously detect a medication bottle that is turned on its side so that I can focus on patient care without having to pick up the bottle and explicitly scan the medication into the client.



3.2.1.4 Acquiring a Barcode

3.2.1.4.1 Acquiring a Patient ID

FR-004 Active Input of a Patient ID into the Ashvin Client Via BarcodeAs a clinician, I want to read a patient ID into the Ashvin client by explicitly scanning a barcode so that the Ashvin client discriminates which patient in the current patient care setting I am currently focusing on.


• The client has access to a video source as per FR-003.

FR-005 System Successfully Recognizes a Patient IDAs a clinician, I want to import EHR data into the Ashvin client for a specific patient from the EHR so that I can have the most recent healthcare information regarding the patient readily at hand.


• The clinician can input a patient ID into the client as per FR-004 or FR-007.

• The client is logged in to the EHR.• A patient with the scanned patient ID exists in the EHR.

12


3.2.1.4.2 Acquiring a Medication ID

FR-009 Active Input of a Medication ID into the Ashvin Client Via BarcodeAs a clinician, I want to read a medication ID into the Ashvin client by explicitly scanning a barcode so that the Ashvin client discriminates which medication in the current patient care setting I am currently focusing on.



FR-011 System Successfully Recognizes a Medication IDAs a clinician, I want to import EHR data into the Ashvin client for a specific medication from the EHR so that I can be aware of potentially dangerous drugs in the patient care setting.


• The user can input a medication ID into the client as per FR-008 or FR-009

• The client is logged in to the EHR.• A medication with the scanned medication ID exists in the EHR.

3.2.1.5 Processing a Barcode

3.2.1.5.1 System Scans Object but Can Not Identify as a Patient or Medication

FR-012 System Scans Object But Unsuccessfully Recognizes the ScanAs a clinician, I want the client to alert me if a scanned item is not recognized as a patient or medication so that I can know that there is an item in the environment that is a potential impediment to the scanning system.


• The user can input a patient into the client as per FR-004 or FR-007.• The user can input a medication into the client as per FR-008 or FR-009• The client is logged in to the EHR.• There is an item in the patient care setting that does not represent a

patient or medication.

13


3.2.1.5.2 System Scans Patient but No Such Patient Exists in the EHR

FR-013 System Scans Patient But Patient Does Not Exist in the EHR

As a clinician, I want the client to alert me if a scanned patient does not relate to a patient in the EHR so that I can alert a hospital administrator of the issue.


• The user can input a patient into the client as per FR-004 or FR-007.• The client is logged in to the EHR.• The patient scanned is a legitimate patient but the patient is not present

in the EHR.

3.2.1.5.3 System Scans Medication but No Such Medication Exists in the EHR

FR-014 System Scans Medication But Medication Does Not Exist in the EHRAs a clinician, I want the client to alert me if the scanned medication does not relate to a medication in the EHR so that I can consult the doctor on duty to make sure that the medication does not harm my patient.


• The client is connected to the Ashvin server.• The user can input a medication into the client as per FR-008 or FR-009.• The client is connected to an EHR.• The medication scanned is a legitimate medication but the medication is

not present in the EHR.

14


3.2.1.6 Displaying Information

3.2.1.6.1 Displaying Patient Information

FR-006 Client Displays Patient Information

As a clinician, I want to see my patient's personal information on my mobile device so that I know I am administering care to the correct patient.


• The client is connected to the Ashvin server.• The user can input a patient into the client as per FR-004 or FR-007.• The client is connected to an EHR.• The patient scanned is a legitimate patient in the EHR.

3.2.1.6.2 Displaying Prescription Information

FR-021 Client Displays Prescription Information

As a clinician, I want to see my patient's prescription information on my mobile device so that I know I am administering the correct medication to my patient.


• The client is connected to the Ashvin server.• The user can input a medication into the client as per FR-008 or FR-009.• The client is connected to an EHR.• The medication scanned is a legitimate medication in the EHR.

15


3.2.1.6.3 Displaying Medication Information

FR-010 Client Displays Medication InformationAs a clinician, I want to see a scanned medication's information displayed on my mobile device so that I know I am administering the correct medication to my patient.


• The client is connected to the Ashvin server.• The user can input a medication into the client as per FR-008 or FR-009.• The client is connected to an EHR.• The medication scanned is a legitimate medication in the EHR.

16


3.2.2 Should Have PrioritiesThe Should Have priority requirements listed in this section represent features that should be present in the current release of the Ashvin Workflow Monitoring System but were deemed beyond the scope of the first release. These requirements are part of the server, EHR and alert system. Since primary focus of the first release is implementing the passive scanning system, it has been determined that the implementations of the Should Have priorities in the first Ashvin release are not mandatory.

3.2.2.1 User Login

FR-022 Authentication and Authorization of Client Access to ServerAs an IT administrator, I want the Ashvin system to authenticate all users and allow client access to the server exclusively to those who are authorized to use the system so that patient data is kept accurate and confidential.

Priority Should HaveAssumptions The EHR is accessible to the mobile client via a wireless connection.

3.2.2.2 Processing Medications Detected in the Environment

3.2.2.2.1 System Detects Incorrect Match to Medication vs. Prescription

FR-015 System Scans Medication But Medication Does Not Match Any Medication in the Patient Prescription Defined by the EHRAs a clinician, I want the client to alert me if the scanned medication does not relate to any medication in the patient prescription from the EHR so that I do not harm my patient by accidentally administering the wrong drug.

Priority Should HaveAssumptions • The user can launch the Ashvin client application as per FR-001.

• There is a patient entered into the client.• The user can input a medication ID into the client as per FR-008 or FR-

009.• The client is logged in to the EHR.• The patient has an active prescription in the EHR.

17


3.2.2.2.2 System Detects Incorrect Match to Medication Dose vs. Prescription

FR-016 System Detects Medication Administration Event but the Medication Dose Does Not Match the Prescribed Dose in the Patient Prescription Defined by the EHRAs a clinician, I want the client to alert me if the scanned medication's dosage does not match the dosage prescribed in the patient prescription from the EHR so that I do not harm my patient by accidentally administering the wrong drug dosage.


• There is a patient entered into the client.• The scanned medication matches a medication in the EHR.• The user can input a medication into the client as per FR-008 or FR-009.• The client is logged in to the EHR.• The patient has an active prescription in the EHR.

3.2.2.2.3 System Detects Incorrect Match to Medication Administration Time vs. Prescription

FR-018 System Detects Medication Administration Event and the Current Time Clashes with the Medication Administration Time Defined in the Prescription's Instructions As Per the EHR DataAs a clinician, I want the client to alert me if I administer a medication at the incorrect time defined by my patient's prescription so that I do not harm the him/her.


• There is a patient entered into the client.• The scanned medication matches a medication in the EHR.• The user can input a medication into the client as per FR-008 or FR-009.• The client is logged in to the EHR.• The medication has specific instructions relating to the administration

time.

18


3.2.3 Could Have PrioritiesThe Could Have priority requirements listed in this section represent features that could be present in a future release of the Ashvin Workflow Monitoring System. These requirements supplement the video scanning system with alternative ways to scan data from within the patient care setting. Since these requirements are merely supplemental, it has been determined that the implementations of the Could Have priorities in the first Ashvin release are not mandatory. The Could Have requirements in this section all pertain to searching for an object of interest in the environment.

3.2.3.1.1 RFID Receiving

FR-027 Ability of Ashvin Client to Receive an RFID SignalAs a clinician, I want the Ashvin client to have access to RFID signals so that I can focus on patient care without having to explicitly face my patient as is the case with a head-mounted video camera.

Priority Could HaveAssumptions The clinician can launch the Ashvin client application as per FR-001.

3.2.3.1.2 Detecting a Patient in the Environment

FR-026 Passive Detection of a Patient in Environment Via RFIDAs a clinician, I want the Ashvin client device to autonomously detect the patient closest to me into the client so that I can focus on patient care without having to explicitly scan information into the client.

Priority Could HaveAssumptions • The clinician can launch the Ashvin client application as per FR-001.

• The client can receive RFID signals as per FR-027.

3.2.3.1.3 Detecting a Medication in the Environment

FR-028 Passive Detection of a Medication in Environment Via RFIDAs a clinician, I want the client device to autonomously detect a medication bottle within four feet of me so that I can be aware of the medications that are around me and my patient without having to explicitly scan them into the client, allowing me to focus on caring for my patient.

Priority Could HaveAssumptions • The clinician can launch the Ashvin client application as per FR-001.

• The client can receive RFID signals as per FR-027.

19


3.2.4 Deferred PrioritiesThe Deferred priority requirements listed in this section represent features that could be present in a future release of the Ashvin Workflow Monitoring System. What distinguishes the Deferred priority requirements in this section from Could Have priority requirements is that these Deferred requirements are needed for an effective implementation of the Five Rights of Medication Administration. The reason they have been deferred is because the technology needed to implement them is still in the research phase and outside the scope of the current Ashvin design. The future release of Ashvin that implements these requirements will succeed in implementing a tool effectively capable of helping clinicians with the Five Rights of Medication Administration.

3.2.4.1 Searching the Environment for Medication Administration Routes

FR-029 Passive Detection of a General Medication Administration RouteAs a clinician, I want the client device to autonomously detect a general administration route of a medication so that I can have an extra set of eyes on my actions.

Priority DeferredAssumptions • The user can launch the Ashvin client application as per FR-001.


FR-030 Passive Detection of a Specific Medication Administration RouteAs a clinician, I want the client device to autonomously detect a specific administration route of a medication so that I can have an extra set of eyes on my actions.



20


3.2.4.2 Processing Medication Administration Routes

3.2.4.2.1 System Detects Incorrect Match of Medication Route vs. Prescription

FR-017 System Detects Medication Administration Event but the Medication Route Does Not Match the Recommended Route Defined in the Prescription's Instructions As Per the EHR Data

As a clinician, I want the client to alert me if I am administering a medication via the wrong route defined by the prescription so that I do not harm my patient.


• There is a patient entered into the client.• The scanned medication matches a medication in the EHR.• The user can input a medication into the client as per FR-008 or FR-009.• The client is logged in to the EHR.• The prescription has specific instructions relating to the administration

route.

3.2.4.2.2 System Detects Incorrect General Route

FR-019 System Detects Medication Administration Event but the Administration General Route Does Not Match the General Route Defined in the Medication's Instructions As Per the EHR Data

As a clinician, I want the client to alert me if I administer a medication via the incorrect general route so that I do not harm my patient.


• There is a patient entered into the client.• The scanned medication matches a medication in the EHR.• The user can input a medication into the client as per FR-008 or FR-009.• The client is logged in to the EHR.• The medication has general instructions relating to the administration

route.

21


3.2.4.2.3 System Detects Correct General Route but Incorrect Specific Route

FR-020 System Detects Medication Administration Event but Even Though the Administration General Route Matches the General Route Defined in the Medication's Instructions As Per the EHR Data, the Specific Route Does Not MatchAs a clinician, I want the client to alert me if I administer a medication via the correct general route but incorrect specific route so that I do not harm my patient.


• There is a patient entered into the client.• The scanned medication matches a medication in the EHR.• The user can input a medication into the client as per FR-008 or FR-009.• The client is logged in to the EHR.• The medication has general instructions relating to the administration

route.

22


3.3 Graphical User Interface (GUI)

3.3.1 Launching the Client Application

3.3.1.1 The Ashvin Main Screen

Figure 1 shows the main screen of the Ashvin Workflow Monitoring System with the prescriptions view focused and Figure 2 shows the main screen of the Ashvin Workflow Monitoring System with the scan results view focused. The patient information view is located at the top left, with the camera feed view to the top right. The prescription and scan results views are toggled by tapping a finger on the appropriate tab.

Functional Requirements Satisfied: FR-001

23

Figure 1: Main Screen with Prescription List Figure 2: Main Screen with Scan Results


3.3.2 Display of Information

3.3.2.1 Patient Information

The Ashvin client GUI displays the results of any input event that results in a patient ID being entered into the mobile device running the client. The visual display of vital patient identification information is shown in Figure 6. Data in the patient information display are obtained from the EHR. The patient information display can be expanded (Figure 3) or contracted (Figure 4) as necessary by tapping the view with a finger.


24

Figure 3: Expanded View of Patient Information Display (Shown Next to Video Feed)

Figure 4: Collapsed View of Patient Information Display (Shown Next to Video Feed)


3.3.2.2 Patient Prescription

The Ashvin client GUI features a visual display of the patient's current medication prescription in the form of a list (Figure 5). Data in the prescription display are obtained from the EHR. The prescription list is accessed by tapping on the Prescriptions tab. Detailed information for a medication can be obtained by tapping on a medication name with a finger. This action expands the medication description. Tapping a second time on the medication will collapse the details.


25

Figure 5: Patient Prescription List View with Medication Details Showing


3.3.2.3 Input of Medication into System

3.3.2.3.1 Scan Results View

The Ashvin client GUI features a visual display of the current activity of the camera scanning system in the form of a list. This list, the scan results list (Figure 6), is similar to the patient prescription list described in Section 3.3.2.2 - Patient Prescription. Data in the scan results display are obtained from passive barcode scans obtained by the video camera. The scan results list is accessed by tapping on the Scan Results tab. Detailed information for a medication can be obtained by tapping on a medication name with a finger. This action expands the medication description. Tapping a second time on the medication will collapse the details.


26

Figure 6: Scan Results View


3.3.2.3.2 Video Camera Feed

The Ashvin client GUI features a visual display of the current camera feed in the form of an image next to the patient information display (See Figure 3). When an object of interest appears in the video feed, a red box will appear, showing the location of the suspected barcode representing the object (Figure 7).


27

Figure 7: Video Feed with Red Box

Ashvin Software Requirement Specifications Document Non Functional Requirements

4 Non Functional Requirements 4.1 HardwareAshvin v2.1 is a testbed system that runs on a single, mobile device. The device runs on the Android operating system. The mobile device features a back-facing camera.

4.2 Security• Sensitive information passed over the network must be encrypted to ensure that the data is not

available to unauthorized parties.

• User cannot modify EHR data that he/she does not have authorization to change.

• User cannot view EHR data that he/she is not authorized to view.

• User cannot log in to the HIS if his/her user name is already in use.

4.3 ReliabilityThe server must be able to guarantee 99.9 percent up-time. The medical information provided by the system is vital, and the system must be able to recover from failures.

4.4 DurabilityThe battery on the client device – e.g. mobile device or Google glass – should be able to last for the entire length of a clinician's shift, which can be ~12 hours long.

4.5 Speed• The client must be able to scan a bar code within one second of fully entering the camera’s

view.

• Requests to the server must be responded to within one second.

4.6 Portability• The client application must be able to be run on Google Glass, as well as other common

Android devices.

• The GUI should be able to adapt to the glasses, tablet, and phone form.

4.7 ExpandabilityMultiple Ashvin clients must be able to access the same EHR concurrently.

4.8 TestabilityEach individual component of the system must be tested to ensure that it performs as intended.

28

Ashvin Software Requirement Specifications Document Non Functional Requirements

4.9 Documentation

4.9.1 Software Requirement Specifications DocumentThe Ashvin team will provide a Software Requirement Specifications document outlining the functional and non-functional requirements of the Ashvin system (this document).

4.9.2 Design DocumentThe Ashvin team will provide a Software Design document detailing design requirements of the Ashvin system.

4.9.3 Acceptance Test Plan DocumentThe Ashvin team will provide an Acceptance Test Plan document detailing the acceptance tests designed to test the functional requirements of the Ashvin system.

29

Ashvin Software Requirement Specifications Document System Evolution

5 System EvolutionThe Ashvin system is built to allow dynamic recognition of objects to analyze medication administration, therefore helping the clinician on duty prevent errors in patient care. The current system employs image recognition methods that passively detects barcodes representing patient and medication IDs. See section 2.6 Focus for details regarding the focus of the current Ashvin release.

In order to fulfill the Right Dose, Right Time and Right Route of Administration line items of the Five Rights of Medication Administration, future releases of the Ashvin system should include:

• A fully implemented interface to a real EHR.

• Secure login to the server.

• Fully implemented alert system that alerts the clinician to medication administration events including, but not limited to:

◦ Clinician crushes pills when he/she should not.◦ Clinician administers medication orally when he/she should use IV.◦ Clinician administers medication into the incorrect IV.◦ Clinician administers medication at incorrect time as per the patient's prescription.◦ Clinician administers incorrect medication dose as per the patient's prescription.

Future releases of the Ashvin system could include:

• RFID Technology – Can be used to complement the video-based image recognition capabilities of the current system.

• Facial Recognition – Can be used to identify a patient, ensuring that medication is administered to the correct person.

• Multiple Cameras – Can be used as a hardware-based solution to the complexity of object and event recognition and resolution problem or as a supplement to the current, software-based solution.

30