Use Case ID: - Research
[pic]
Healthcare, Bar-coding and Safety – Beyond Medication
Authors: Ross Morrison, Lauren Knish, Stuart Reasons
Advisors: Patrick Harris, David Roth – PharmaSys Hospital Solutions, Cary, NC
Department of Biomedical Engineering, Vanderbilt University, Nashville, TN
April 22, 2008
Abstract
Point-of-care bedside bar code verification systems have been proven to significantly reduce medication errors as a means of administering medications to patients. There are several limitations to these systems, but there are endless possibilities beyond medication management and administration verification using barcode, RFID, infrared or other related automated technologies, which represent the platform for our current system. The purpose of this design project will include expanding the capabilities and applications of the PharmaSys eMEDSTM system, which is a system provided by PharmaSys, Inc. for the administration of medication based on barcode technology. There are many application extensions and objectives of this design project, including but are not limited to the following. The first objective is to extend the functionality of the system to provide a means of automatic and validated specimen collection as well as a point-of-care and automated technology for blood transfusions. Also, another objective is to provide a user-friendly workflow tool to improve communication and increase the productivity of the current system. This project serves as a unique opportunity to help provide a current eMEDSTM hospital customer with expanded functionality that could set eMEDSTM and the hospital client apart from their competitors.
Introduction
Point-of-care bedside bar code verification systems have proven to significantly reduce medication errors as a means of administering medications to patients. Currently mistakes are often made in the administration of medication, blood and in the process of specimen collection. These mistakes can lead to the administration of the wrong medicine, blood or the collection of the wrong sample from a patient. The consequence of these mistakes can range from minor to drastic and can even include loss of life. Furthermore, healthcare companies and hospitals can often lose large amounts of money due to lawsuits as a result of these mistakes as well as from losses in productivity. Many hospitals are often reluctant to switch to electronic verification methods due to increased workflow, documentation and time. Because of this hospitals are in need of excellent electronic workflow management systems.
Our goals are for our system to meet both of these needs. The software we will develop will solve the problem of verification in blood transfusions and specimen collection reducing risk and saving time and money. Furthermore our system will provide easy documentation and manage workflow seamlessly meeting the needs of both users and hospitals.
The benefits of the system are vast and include both patient safety as well as cost savings for the hospital and a reduction both in paperwork and mal-practice lawsuits. Furthermore the system ensures the patients “five rights” before medication or transfusion administration. These rights include: “right patient, right drug, right time, right dose, right administration route” (Effective Patient Care). This wireless, mobile technology also allows nursing personnel to document information about the transfusion, including start and stop time and vital signs. The system ensures that the operations of the pharmacy, physician, nurses and administration are all connected. The specimen collection system assists laboratory technicians in improving safety by providing positive patient identification for the patient and the lab test and ensuring that specimens are correctly bar-coded and labeled.
This project is being designed under the supervision of PharmaSys, Inc. PharamSys is an international full service contract compliance and validation firm specializing in industries that must comply with 21 CFR including Pharmaceuticals, Bioscience,Medical Devices and Clinical Trials located in Cary, North Carolina (21 CFR). They are currently developing the system, expanding the functionality, and testing the eMEDs system in a hospital environment.
Fitts Law
Fitts Law represents and describes the time taken to acquire a visual target using some type of manual input device. This manual input device can represent a finger, a mouse associated with a computer, in addition to many other devices. Although there are many variants on the equation used for Fitt’s Law, the most commonly used equation can be seen in Equation 1 (Fitts’s Law).
[pic] (EQ: 1)
In this equation, T is the average time it takes to reach the selected target, D represents the distance to the center of the target, W represents the width of the target, and C1 and C2 are experimentally determined constants. Therefore, we were able to model our system based upon the correlation of distance to the target as a function of the size of the target. This is based upon the concept that a larger target with a shorter target distance will be easier to hit with a manual input device in contrast to a smaller target with a longer target distance.
Software Design Requirements
There are many different software design requirements that we had to follow in accordance to the development of our software prototypes. The first is the Software Quality Assurance Plan, or the SQAP, which represents planned systematic patterns of activities performed to assure the procedures, tools and techniques used during software development are adequate to provide the desired level of confidence in the final product (King 78). The SQAP includes many checks and balances and assures that the software is of such quality that it does not reduce the reliability of the hardware device. A typical SQAP will include the following: “Purpose Statement, Reference Documents, Management, Documentation, Standards, Practices, Conventions, and Metrics, Review and Audits, Test, Problem Reporting and Corrective Action, Tools, Techniques, and Methodologies, Code Control, Media Control, Supplier Control, Records Collection, Maintenance, and Retention, Training, and Risk Management” (King 80).
Another design requirement includes the Software Requirements Specification, or the SRS. The SRS is a specification for a particular software product, program or set of programs that perform certain functions. A good SRS is unambiguous, complete, verifiable, consistent, modifiable, traceable, and usable during the Operation and Maintenance phase. A typical SRS includes the following: “Purpose, Scope, Definitions, Acronyms, and Abbreviations, References, an Overview, Product Perspective, Product Functions, User characteristics, General constrains, Assumptions and dependencies, and Specific Requirements.”
Lastly, we also followed the Six Essentials of Software testing as described my Edward Kit. These include the ideas that the equality of the testing process is determined by the success of the test effort, that it is possible to prevent defect migration by using testing techniques early in the life-cycle process, that the time for software testing is now, that a real person must be considered responsible for improving the testing process, that testing requires skilled, trained people, and that it is necessary to develop a positive team attitude (King 374). Therefore, it was these design rules and specification that helped foster the development of our software prototypes and hardware specifications.
Methodology
The methodology must be planned ahead and mapped out in order for the system to verify blood transfusions and specimen collections. We begin selecting solution concepts by running through Innovation WorkBench. We list the criteria to be that the final software must be a robust, universal solution. The software should practically eliminate consequences from human errors. There is already a standard workflow set in place in hospitals that our product must align with. The software must also be user friendly for the nurse to quickly and easily enter data. It must also be designed for use on computers already implemented by the bedside and the better option for use on a PDA.
The system structure must be simple and accessible. The hardware must contain a barcode scanner capable of reading ISBT-128 barcodes (our scanner used during design was the Symbol LS2208 General Purpose Bar Code Scanner). The PDA must be lightweight and pocket sized. It must have wireless technology for instant updates into databases for every patient’s track record and billing purposes. The hardware and software must not interfere with other medical equipment or processes.
The first research was to discuss and understand the current flow of blood samples in the hospital from the doctor’s order to the transfusion. Dr. Quinn, a local process engineer and registered nurse, Aggie Read, were our go-to contacts to assist us in completing a flow chart as shown on the following page. Although verification will only be active at the bedside, we were able to improve out understanding of the entirety of the process this way.
[pic]
Following completion of the flow charts in Visio, we began to research and design what activity we wanted the software to accomplish encompassing the verification process. In order to do this in an organized fashion, Use Cases were designed for blood transfusions, specimen collections and database record activity. A Use Case describes how the system reacts to a user’s input actions. The Use Case includes a list of possible user inputs with the following software outputs/responses to any given situation along each step of verification. Use Cases include exceptions in verification for cases when barcode items do not match and alternative actions; such as when the doctor or nurse utilizes their option of attaching a note. A fraction of the Blood Transfusion Use Case is shown below.
|Use Case Name: |Blood Transfusion |
|Actors: |Logged In Users |
|Description: |Users will have the ability to record and verify blood samples |
|Pre-Conditions: |Users must be logged into the system. |
|Post-Conditions: |Blood Sample(s) will be recorded as administered or not administered with a date/time stamp, name of |
| |User, and notes. |
|Normal Flow: |Label Blood Sample Administered |
| |Actor Actions |System Responses |
| |The User scans the patient barcode. |System displays Patient Scan number |
| |The User scans the blood type barcode. |System displays Blood Type scan number. |
| |The User scans the blood donor barcode |System displays Blood Donor scan number |
| |The User scans the blood expiration date barcode |System displays Blood Expiration date scan number |
| |The User scans the blood antibodies (if |System displays Blood Antibodies scan number |
| |necessary) |System displays “Sample matches Patient” on |
| |The User selects the Verify action. |Transfusion Page |
| | |System displays “Patient consent recorded.” |
| |Patient electronically signs consent form. |System displays “Confirm Transfusion” (button) or |
| |The User administers transfusion and clicks the |“Transfusion Not Given” |
| |confirmation button which saves. |System displays “Activity Recorded and saved.” |
|Alternative Courses: |Label Blood Sample Administered with Physician Note |
| |Label Blood Sample Not Administered |
| |Label Blood Sample Not Administered with Note |
|Exceptions: |Wrong Patient Number |
| |Wrong Blood Type Number |
| |Wrong Blood Donor Number |
| |Wrong Blood Expiration Date Number |
| |Wrong Blood Antibody Number |
|Assumptions: |The User will have a scanner. |
| |All barcodes can be scanned and read. |
| |The curser will be in the highest field to be populated in standard reading sequence |
| |The ‘location code’ will take the curser to the correct verification code box |
“Actor Actions” and “System Responses” are also included and numbered out step-by-step for each grey box case listed. Full Use Cases may be found in Appendix I.
All blood transfusions and specimen collections must be recorded in electronic databases. We therefore designed the eTAR (electronic Transfusion Activity Record) and the eSCAR (electronic Specimen Collection Activity Record). These records must contain patient information, date, time, and vitals. Vitals are taken fifteen minutes before and fifteen minutes after transfusions have begun and therefore tagged with the patient activity number for the specific transfusion in the record. Records of the vitals will prove easily accessible when records need to be located for past patient activity.
The entire system will is designed to be compatible with the new “global standard for the identification, labeling and information processing of human blood, tissue and organ products across international borders and disparate health care systems,” the ISBT-128 (ICCBBA 2007). The American Red Cross is currently switching to this barcode system as they are in the final approval steps from the FDA. An example of a standard blood sample label is shown below.
[pic]
1. Donation Identification Number 4. Expiration Date and Time
2. ABO/Rh Blood Groups 5. Special Testing
3. Product Code
The ISBT 128 is critical in selection for specimen verifications for a variety of reasons. These linear barcodes specify (1) a donation numbering system that ensures globally unique identification; (2) the information to be transferred, using internationally agreed reference tables; (3) an international product reference database; (4) the data structures in which this information is placed; (5) a bar coding system for transfer of the information on the product label; (6) a standard layout for the product label; (7) a standard reference for use in electronic messaging (ICCBBA 2007). One of the important characteristics listed, the data structures, use a ‘location code’ which allows the reading system to identify the item from which a code was read; hence it is possible to electronically distinguish between a patient identifier scanned from a wrist band or from a cross match label. This permits a high degree of control over the verification process and speeds up scan time as barcodes may automatically place themselves in the correct verification box type (i.e. patient number will not be accidentally compared with blood type).
Results
After research on blood transfusion and specimen collection workflow work began on creating the Use Cases. Use Cases were created for Blood Transfusion, Specimen Collection, logging in to the system and workflow. Once again, the use cases are can be found in Appendix 1. The Blood Transfusion Use Case, the use case details the steps taken for a nurse using the system to record and verify blood samples. The use case begins with the standard workflow where nothing goes wrong in the system and the transfusion is verified correctly. It begins with the user logging into the system, scanning the blood type, scanning the blood donor barcode, scanning the expiration date, and scanning antibodies (if necessary). Next the system reacts to the scans by displaying the scan data and when the nurse clicks verify providing information on whether or not the information is correctly verified for the patient. All of the blood transfusion information is then stored in the eTAR (electronic Transfusion activation record) which can be viewed later.
The next parts of the use case are the alternative cases. Alternative cases deal with when notes need to be attached to the administration of blood or blood cannot be administered due to complications with the patient. The use cases once again show what happens with each situation when after the user interacts with the system.
The specimen collection use case just like the transfusion use case goes through the workflow of the software showing where users interact and how the system responds. In the Normal Action Use Case the user first logs in then can view the specimen collection order. After logging in the patient is scanned. Next the user selects which order is being collected and the patient consents with an electronic signature. Finally the user collects the specimen and tells the system that the collection is finished. This information is then saved by the system creating a record of the collection which can be viewed later in the eSCAR (electronic specimen collection record). Once again as with blood transfusion alternate use cases have been created for instances when notes need to be added to the specimen collection or if the collection cannot take place.
After the use cases were created the next step was to create prototypes of the system. Prototypes are html websites that look and react exactly as the real system will work. The only difference is that our prototypes are not set up with the hospitals information management system and the patient databases. Because of this our systems react just as in the use cases however they do not contain the data of all patients in the hospital. The prototypes are contained in Appendix 2. The first prototype that was created was based on the blood transfusion prototypes. The prototypes also utilize the symbol barcode scanner and are able to read ISBT 128 from the blood bags. Prototypes of the eTAR have also been created to see how information is stored and presented by the system.
After the blood transfusion prototype was created the next to be created was the specimen collection prototype. This prototype works by scanning the patient data which then brings up a list of the patients ordered work. Next the correct test is selected and the specimen is collected. As with the eTAR, the eSCAR was also prototyped in order to see how the system stores and displays the specimen collection data.
Two versions of the system have been designed one for use with a desktop computer and one for use with a personal digital assistant (PDA). Depending on hospitals current setup the system will be chosen. In hospitals that already have computers in every room or at nurses station the software for the desktop will be chosen. This will help to reduce cost to the hospital by utilizing the technology that is already in place. With this system wireless barcode scanners will be used. The second option of using PDA's will be the choice for hospitals with no preexisting system of computers. The PDA's will present a cheaper alternative than buying full computer systems for the entire hospital. The PDA systems will also allow for greater mobility and information access from anywhere in the hospital (Figure 2).
Once our system has been implemented into a hospital it will be able to cut costs in multiple ways. The first will be in a reduction of paperwork thanks to the all electronic system. Secondly, productivity will be increased thanks to the improved hospital workflow that will be implemented. Another improvement will be the ability to have clear and concise records of every blood transfusion and specimen collection that takes place in the hospital. Finally, the system will be able to help alleviate mistakes that are made in the collection of specimen and the administration of blood. Since mistakes in this matter can be lethal there is almost always litigation connected to these mistakes. These lawsuits can cost hospitals a substantial amount of money and the Pharmasys eMeds system can help to stop these mistakes and save the hospital money.
Conclusions
In conclusion, our team has succeeded in expansion of a system that already helps reduce medication administration errors at the patient bedside, but now also includes verification for specimen collection and blood transfusion. Since we have a fully functional prototype that meets specifications, the next step would be to pilot and implement the eMEDS system into a hospital environment in order to test the software and its corresponding hardware. For future direction, it will be important to expand the system to include verification for breast milk delivery, as well as to make the system compatible for the emergency room (ER) and the operating room (OR) environments. In the new future, PharmaSys Hospital Solutions plans on piloting our prototype system for use in a hospital setting. In conclusion, our prototypes and the expansion of the eMEDS system are just a starting point for future design and development of this bar-coding system.
Recommendations
Therefore, even though we completed all our pre-set goals, there are many continuations and changes that could be implemented in the future to improve the final product. First, it would be necessary to fully polish and finish both the Blood Transfusion and Specimen Collection prototypes, adding vitals records and other necessary additions, as well as integrating other total system requirements. Also, there are many additional tabs that may wish to be added. These include what to do when a patient denies action, administration location, and whether or not the patient has an adverse reaction in the case of the blood transfusion. Other possible software modifications include potentially incorporating patient photographs into the patient record pages, having a background color changing indicator to the boxes that contains mismatching scans, color changing indicator on the “Notes” tab if there are notes attached, automatic updates to the databases, the eTAR and eSCAR, having compatibility with RFID technology, incorporate daily calendar to schedule reminders for pre/post transfusion vital checks, and verifying that vitals are within acceptable range to continue with the necessary course of action. Lastly, this point-of-care bedside verification system represents an ongoing process that can be constantly updated and improved, and therefore it will be necessary to integrate the eMEDS system into a real-life hospital environment, as well as to continue a user friendly prototype design.
It is also important to consider the medical ethics when producing and polishing a final product. One of the biggest problems when taking specimen collections and blood transfusions is to accurately label and track the laboratory specimens. Even though this is not an “exact science”, we hope that this bar-coding system will help the effort to enhance and ensure patient safety (Moher).
In conclusion, our prototypes and the expansion of the eMEDS system are just a starting point for future design and development of this point-of-care bar-coding system.
References
"21 CFR." U.S. Food and Drug Administration. 05 June 2003. Department of Health and
Human Services. 21 Apr 2008 .
"Effective Patient Care." Five Rights Consulting. 04-12-2008.
.
"Fitts' Law and Reaching Tasks." CCOM-JHC. University of New Hampshire. 21 Apr
2008 .
ISBT 128: More than Identification. (2007, December 05). Retrieved December 2007, from ICCBBA: .
King, Paul, Richard C. Fries . Design of Biomedical Devices and Systems. New York:
Marcel Dekker, 2003.
Moher, Ralph. "Labeling and Tracking Preventing Errors in the Lab." Patient Safety and
Quality Healthcare. Lionheart Publishing. 21 Apr 2008 .
Appendix I – Use Cases
|Use Case ID: | |
|Use Case Name: |Log into system |
|Created By: | |Last Updated By: | |
|Date Created: |Last year’s group |Date Last Updated: | |
|Actors: |User |
|Description: |User will have the ability to log in to the system. |
|Pre-Conditions: |User will have a username and/or a badge with a barcode. |
| |User must be on Log in Page |
|Post-Conditions: |User is logged in. |
|Normal Flow: |Log In to System with Barcode |
| |Actor Actions |System Responses |
| | 1. The User scans his badge barcode. | 1. System displays badge number. |
| |2. The User types in his domain. |2. System displays domain. |
| |3. The User types in his password. |3. System does not display the password. |
| |4. The User selects the Submit action. |4. System displays “Welcome ” at the top of |
| | |the Workflow Page. |
|Alternative Courses: |Log In to System with Username |
| |Actor Actions |System Responses |
| | 1. The User types in his username. | 1. System displays user name. |
| |2. The User types in his domain. |2. System displays domain. |
| |3. The User types in his password. |3. System does not display the password. |
| |4. The User selects the Submit action. |4. System displays “Welcome ” at the top of |
| | |the Workflow Page. |
|Exceptions: |Wrong User Barcode, Password or Domain |
| |Actor Actions |System Responses |
| | 1. The User scans his badge barcode. | 1. System displays badge number. |
| |2. The User types in his domain. |2. System displays domain. |
| |3. The User types in his password. |3. System does not display the password. |
| |4. The User selects the Submit action. |4. System displays “Login Failed” on the Login |
| | |Page. |
| |Wrong Username, Password or Domain |
| |Actor Actions |System Responses |
| | 1. The User types in his user name. | 1. System displays user name. |
| |2. The User types in his domain. |2. System displays domain. |
| |3. The User types in his password. |3. System does not display the password. |
| |4. The User selects the Submit action. |4. System displays “Login Failed” on the Login |
| | |Page. |
|Priority: |High |
|Frequency of Use: |Frequent. Users must log into the system in order to access information in the system and to complete tasks |
| |using the system. |
|Special Requirements: |None |
|Assumptions: |All barcodes can be scanned and read. |
| |The curser will be in the field to be populated. If it is not in the correct field it will be moved by the |
| |user. |
|Use Case ID: | |
|Use Case Name: |Manage Workflow |
|Created By: |Last Year |Last Updated By: | |
|Date Created: | |Date Last Updated: | |
|Actors: |Logged In User |
|Description: |Logged In Users can use the workflow to view patient information and sort patients. |
|Pre-Conditions: |Logged In Users are logged into the system. |
|Post-Conditions: |Patients are sorted and viewed in Workflow. |
|Normal Flow: |View and Sort Workflow |
| |Actor Actions |System Responses |
| | 1. The Logged In User sees the Workflow Page | 1. System displays Workflow page. Alerts |
| |on Log In. |are listed at the top of the page; patients by |
| | |default are listed by room/bed number. |
| |2. The Logged In User sorts patients by choosing a |2. System displays patients in the order selected|
| |heading: patient name, unit/room/bed number, and time |by the Logged In User. |
| |of next med. | |
| |3. The Logged In User views a patient by selecting |3. System expands patient information including |
| |patient name. |patient identifiers, drug information for drugs |
| | |prescribed, and any alert(s) pertaining to the |
| | |patient below the patient selected. |
|Alternative Courses: |View Warnings and Alerts |
| |Actor Actions |System Responses |
| | 1. The Logged In User sees the Workflow Page | 1. System displays Workflow page. Alerts |
| |on Log In. |are listed at the top of the page; patients by |
| | |default are listed by room/bed number. |
| |2. The Logged In User selects the alert to be |2. System displays patient(s) to whom the alert |
| |viewed. |corresponds. Patients have icons corresponding to |
| | |alerts next to their names in the workflow. |
| |3. The Logged In User views a patient by selecting |3. System expands patient information including |
| |patient name. |patient identifiers, drug information for drugs |
| | |prescribed, and any alert(s) pertaining to the |
| | |patient below the patient selected. |
| |View and Sort Workflow from Another Page |
| |Actor Actions |System Responses |
| | 1. The Logged In User selects the Workflow | 1. System displays Workflow page. Alerts |
| |tab. |are listed at the top of the page; patients by |
| | |default are listed by room/bed number. |
| | |2. System displays patients in the order selected|
| |2. The Logged In User sorts patients by choosing a |by the Logged In User. |
| |heading: patient name, room/bed number, and time of | |
| |next med. |3. System expands patient information including |
| |3. The Logged In User views a patient by selecting |patient identifiers, drug information for drugs |
| |patient name. |prescribed, and any alert(s) pertaining to the |
| | |patient below the patient selected. |
|Exceptions: |NONE |
|Priority: |High |
|Frequency of Use: |Frequent. |
|Special Requirements: |None |
|Assumptions: |All barcodes can be scanned and read. |
| |The curser will be in the field to be populated. If it is not in the correct field it will be moved by the |
| |user. |
|Notes and Issues: | |
|Use Case ID: | |
|Use Case Name: |Blood Transfusion |
|Created By: |Stuart Reasons, Ross Morrison, Lauren |Last Updated By: |Ross and Stuart |
| |Knish | | |
|Date Created: |12/16/07 |Date Last Updated: |2/8/08 |
|Actors: |Logged In Users |
|Description: |Logged In Users will have the ability to record and verify blood samples |
|Pre-Conditions: |Logged In Users must be logged into the system. |
|Post-Conditions: |Blood Sample(s) will be recorded as administered or not administered with a date/time stamp, name of Logged In |
| |User, and notes. |
|Normal Flow: |Label Blood Sample Administered |
| |Actor Actions |System Responses |
| |The Logged In User scans the patient barcode. |System displays Patient Scan number |
| |The Logged In User scans the blood type barcode. |System displays Blood Type scan number. |
| |The Logged In User scans the blood donor barcode | |
| |The Logged In User scans the blood expiration date |System displays Blood Donor scan number |
| |barcode | |
| |The Logged In User scans the blood antibodies (if |System displays Blood Expiration date scan number |
| |necessary) |System displays Blood Antibodies scan number |
| |The Logged In User selects the Verify action. | |
| | |System displays “Sample matches Patient” on |
| | |Transfusion Page |
| |Patient electronically signs consent form. | |
| | |System displays “Patient consent recorded.” |
| |The Logged In User administers transfusion and clicks | |
| |the confirmation button which saves. |System displays “Confirm Transfusion” (button) or |
| | |“Transfusion Not Given” |
| | | |
| | |System displays “Activity Recorded and saved.” |
|Alternative Courses: |Label Blood Sample Administered with Physician Note |
| |Actor Actions |System Responses |
| |The Logged In User scans the patient barcode. |System displays Patient Scan number |
| |The Logged In User scans the blood type |System displays Blood Type scan number. |
| |barcode | |
| |The Logged In User scans the blood donor barcode |System displays Blood Donor scan number |
| |The Logged In User scans the blood expiration date | |
| |barcode |System displays Blood Expiration date scan number |
| |The Logged In User scans the blood antibodies (if |System displays Blood Antibodies scan number |
| |necessary) | |
| |The Logged In User selects the Verify action. |System displays ““Sample matches Patient” on |
| | |Transfusion Page and “Click to view attached note.” |
| | | |
| | |Note is displayed |
| |The Logged In User clicks to view note | |
| | |System displays “Patient consent recorded.” |
| |Patient electronically signs consent form. | |
| | |System displays “Confirm Transfusion” (button) or |
| |The Logged In User administers transfusion and clicks |“Transfusion Not Given” |
| |the confirmation button which saves. | |
| | |System displays Note Page. |
| |The Logged In User composes a note by typing in the | |
| |spaces or using the drop down menus. |System displays note and confirms save, making the |
| |The Logged In User selects the Save action. |note tab active, or filled |
| |Label Blood Sample Not Administered |
| |Actor Actions |System Responses |
| | 1. The Logged In User scans the patient | 1. System displays Patient Scan number |
| |barcode. | |
| |2. The Logged In User scans the blood type |2. System displays Blood Type scan number. |
| | | |
| |barcode. |3. System displays Blood Donor scan number |
| |3. The Logged In User scans the blood donor | |
| |barcode |4. System displays Blood Expiration date scan |
| |4. The Logged In User scans the blood expiration |number |
| |date barcode |5. System displays Blood Antibodies scan number |
| |The Logged In User scans the blood antibodies | |
| |(if necessary) |6. System displays “Patient Found” on Transfusion |
| |6. The Logged In User selects the Verify action. |Page |
| | |7. System highlights the Transfusion and |
| |7. The Logged In User selects the Don’t Administer |changes the Don’t Administer action to Administer. |
| | |8. System displays “Activity Recorded.” |
| |action. | |
| |8. The Logged In User selects the Save Action. | |
| |Label Blood Sample Not Administered with Note |
| |Actor Actions |System Responses |
| | 1. The Logged In User scans the patient | 1. System displays Patient Scan number |
| |barcode. | |
| |2. The Logged In User scans the blood type |2. System displays Blood Type scan number. |
| | | |
| |barcode. |3. System displays Blood Donor scan number |
| |3. The Logged In User scans the blood donor | |
| |barcode |4. System displays Blood Expiration date scan |
| |4. The Logged In User scans the blood expiration |number |
| |date barcode |5. System displays Blood Antibodies scan number |
| |The Logged In User scans the blood antibodies | |
| |(if necessary) |6. System displays “Patient Found” on Transfusion |
| |6. The Logged In User selects the Verify action. |Page |
| | |7. System displays Note Page. |
| |7. The Logged In User selects the Note action. |8. System displays note. |
| |8. The Logged In User composes a note by typing | |
| |in the spaces or using the drop down menus. |9. System displays a note icon on the Drug |
| |9. The Logged In User selects the Save action. |Information Page. |
| | |10. System highlights the Transfusion and |
| |10. The Logged In User selects the Don’t |changes the Don’t Administer action to Administer. |
| |Administer action. |11. System displays “Activity Recorded.” |
| |11. The Logged In User selects the Save Action. | |
|Exceptions: |Wrong Patient Number |
| |Actor Actions |System Responses |
| | 1. The Logged In User scans the patient | 1. System displays Patient Scan number |
| |barcode. |2. System displays Blood Type scan number. |
| |2. The Logged In User scans the blood type | |
| | |3. System displays Blood Donor scan number |
| |barcode. | |
| |3. The Logged In User scans the blood donor |4. System displays Blood Expiration date scan |
| |barcode |number |
| |4. The Logged In User scans the blood expiration |5. System displays Blood Antibodies scan number |
| |date barcode | |
| |The Logged In User scans the blood antibodies |6. System displays “!Patient Not Found.” |
| |(if necessary) | |
| |6. The Logged In User selects the Verify action. | |
| | | |
| |Wrong Blood Type Number |
| |Actor Actions |System Responses |
| | 1. The Logged In User scans the patient | 1. System displays Patient Scan number |
| |barcode. |2. System displays Blood Type scan number. |
| |2. The Logged In User scans the blood type | |
| | |3. System displays Blood Donor scan number |
| |barcode. | |
| |3. The Logged In User scans the blood donor |4. System displays Blood Expiration date scan |
| |barcode |number |
| |4. The Logged In User scans the blood expiration |5. System displays Blood Antibodies scan number |
| |date barcode | |
| |The Logged In User scans the blood antibodies |6. System displays “!Patient Not Found” and |
| |(if necessary) |“!Could |
| |6. The Logged In User selects the Verify action. |not find blood sample with ID of ” on Enter Blood Type Page |
| |Wrong Blood Donor Number |
| |Actor Actions |System Responses |
| | 1. The Logged In User scans the patient | 1. System displays Patient Scan number |
| |barcode. |2. System displays Blood Type scan number. |
| |2. The Logged In User scans the blood type | |
| | |3. System displays Blood Donor scan number |
| |barcode. | |
| |3. The Logged In User scans the blood donor |4. System displays Blood Expiration date scan |
| |barcode |number |
| |4. The Logged In User scans the blood expiration |5. System displays Blood Antibodies scan number |
| |date barcode | |
| |The Logged In User scans the blood antibodies |6. System displays “!Patient Not Found” and |
| |(if necessary) |“!Could |
| |6. The Logged In User selects the Verify action. |not find blood sample with ID of ” on Enter Blood Donor Page |
| |Wrong Blood Expiration Date Number |
| |Actor Actions |System Responses |
| | 1. The Logged In User scans the patient barcode.| 1. System displays Patient Scan number |
| | |2. System displays Blood Type scan number. |
| |2. The Logged In User scans the blood type | |
| | |3. System displays Blood Donor scan number |
| |barcode. | |
| |3. The Logged In User scans the blood donor |4. System displays Blood Expiration date scan |
| |barcode |number |
| |4. The Logged In User scans the blood expiration |5. System displays Blood Antibodies scan number |
| |date barcode | |
| |The Logged In User scans the blood antibodies |6. System displays “!Patient Not Found” and |
| |(if necessary) |“!Could |
| |6. The Logged In User selects the Verify action. |not find blood sample with ID of ” on Enter Blood Expiration Date Page |
| |Wrong Blood Antibody Number |
| |Actor Actions |System Responses |
| | 1. The Logged In User scans the patient barcode.| 1. System displays Patient Scan number |
| | |2. System displays Blood Type scan number. |
| |2. The Logged In User scans the blood type | |
| | |3. System displays Blood Donor scan number |
| |barcode. | |
| |3. The Logged In User scans the blood donor |4. System displays Blood Expiration date scan |
| |barcode |number |
| |4. The Logged In User scans the blood expiration |5. System displays Blood Antibodies scan number |
| |date barcode | |
| |The Logged In User scans the blood antibodies |6. System displays “!Patient Not Found” and |
| |(if necessary) |“!Could |
| |6. The Logged In User selects the Verify action. |not find blood sample with ID of ” on Enter Blood Antibody Page |
|Priority: |High |
|Frequency of Use: |Frequent. Logged In Users will be using the system to record the administration of blood samples as part of |
| |their daily workflow. |
|Special Requirements: |None |
|Assumptions: |The Logged In User will have a scanner. |
| |All barcodes can be scanned and read. |
| |The curser will be in the field to be populated. If it is not in the correct field it will be moved by the |
| |user. |
|Notes and Issues: | |
|Use Case ID: | |
|Use Case Name: |Blood Transfusion |
|Created By: |Stuart Reasons, Ross Morrison, Lauren |Last Updated By: |Ross and Stuart and Lauren |
| |Knish | | |
|Date Created: |12/16/07 |Date Last Updated: |2/8/08 |
|Actors: |Logged In Users |
|Description: |Logged In Users will have the ability to record and verify blood samples |
|Pre-Conditions: |Logged In Users must be logged into the system. |
|Post-Conditions: |Blood Sample(s) will be recorded as administered or not administered with a date/time stamp, name of Logged In |
| |User, and notes. |
|Normal Flow: |Collecting Specimen |
| |Actor Actions |System Responses |
| |The Logged In User scans the patient barcode. |System displays Patient Scan number |
| |User clicks verify patient has been ordered to give a |System displays ‘Patient Verified’ |
| |specimen collection | |
| |User clicks ‘View order’ |System displays doctors specimen orders in a list |
| | |(Patient name, date ordered, deadline, specimen type, |
| | |amount, notes) |
| |User selects order to be completed |System jumps to consent form |
| |Patient electronically signs consent form, and clicks |System displays ‘Patient consent recorded’. |
| |‘Done’. | |
| |User clicks ‘print labels’ (Patient ID #, specimen |System displays ‘printing labels to printer #___’’ |
| |type, amount, date) |(wirelessly?) |
| | | |
| |(User sticks labels on container) | |
| |(User collects specimen) | |
| | | |
| |User selects the ‘Collection Complete’. |System displays ‘Action for patient ______ has been |
| | |saved’ |
| |(optional) User selects ‘add a collection’ (static |System returns to step two |
| |button on bottom bar | |
| | | |
|Alternative Courses: |Collecting Specimen and adding note |
| |Actor Actions |System Responses |
| |The Logged In User scans the patient barcode. |System displays Patient Scan number |
| |User clicks verify patient has been ordered to give a |System displays ‘Patient Verified’ |
| |specimen collection |System displays doctors specimen order (Patient name, |
| |User clicks ‘View order’ |date ordered, deadline, specimen type, amount, notes) |
| |Patient electronically signs consent form, and clicks |System displays ‘Patient consent recorded’. |
| |‘Done’ |System displays ‘printing labels to printer #___’’ |
| |User clicks ‘print labels’ (Patient ID #, specimen |(wirelessly?) |
| |type, amount, date) | |
| |(User sticks labels on container) | |
| |(User collects specimen) |System displays note box and ‘Save note button’ |
| |User has the option of adding a note in the note tab | |
| |(click tab) |System displays ‘note saved’. |
| |User clicks ‘Save’ |System displays ‘Action for patient ______ has been |
| |User selects the ‘Collection Complete’. |saved’ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| |Specimen not Collected |
| |Actor Actions |System Responses |
| |The Logged In User scans the patient barcode. |System displays Patient Scan number |
| |User clicks verify patient has been ordered to give a |System displays ‘no order for this patient |
| |specimen collection |System displays ‘no specimen collected’ |
| |The Logged In User selects the Don’t collect Action |System displays main menu |
| |The Logged In User selects the Return to ?main menu? Or| |
| |work flow? (some sort of front page). | |
|Exceptions: |Wrong Patient Number |
| |Actor Actions |System Responses |
| | 1. The Logged In User scans the patient | 1. System displays Patient Scan number |
| |barcode. | |
| | |6. System displays “!Patient Not Found.” |
| |6. The Logged In User selects the Verify action. | |
| | | |
|Priority: |High |
|Frequency of Use: |Frequent. Logged In Users will be using the system to record the administration of blood samples as part of |
| |their daily workflow. |
|Special Requirements: |None |
|Assumptions: |The Logged In User will have a scanner. |
| |All barcodes can be scanned and read. |
| |The curser will be in the field to be populated. If it is not in the correct field it will be moved by the user.|
|Notes and Issues: | |
Appendix 2 – Prototype Screen Shots
[pic]
Blood Transfusion Verification Page
[pic]
Specimen Collection – Patient scan before printing label
[pic]
eSCAR - Database
[pic]
eTAR - Database
Appendix III – Innovation WorkBench
Ideation Processurl_IPS/Ideation_Process.htm
Project Initiationurl_IPS/IPS/1_Project.htm
Project name:Healthcare, Barcoding and Safety – Beyond Medication
Project timeline: 12/5/2007-4/22/2008
Project team: Lauren Knish, Ross Morrison, Stuart Reasons
Innovation Situation Questionnaireurl_IPS/IPS/2_Isq.htm
Brief description of the situationurl_IPS/IPS/21_Brief_descr.htm
The system is designed to verify that the correct blood trasnsfusion is given to the correct patient or that the correct sample is taken from the correct patient.
Detailed description of the situationurl_IPS/IPS/22_Sys_App.htm
Supersystem - System - Subsystemsurl_IPS/IPS/221_Sup_Sub.htm
System name url_IPS/IPS/2211_System_name.htm
* Workflow
* Software
* Hardware
For the workflow, the problem is: has to work with what is already going on in the hospital.
For the software, the problem is: has to be user friendly for the nurse to quickly and easily enter data.
For the hardware, the problem is: must be able to quickly and easily scan at the bedside.
System structure url_IPS/IPS/2212_System_structure.htm
The hardware must contain the following elements:
* IB-128 scanner
* light weight and small
* wireless technology
* software embedded
12/5/2007 2:56:01 PM Idea #1
Possibly use bluetooth or wifi for wireless
Supersystems and environment url_IPS/IPS/2213_System_environment.htm
Other parts of the hospital:
* blood bank
* labs
* administration
Other systems:
* Send info to billing
Conditions around the system:
* must work with existing workflow
* cannot interfer with other medical equipment
Systems with similar problems url_IPS/IPS/2214_Other_systems.htm
Similar problem existed with previous eMeds modules. We do not have any information on how these problems have been addressed.
Input - Process - Outputurl_IPS/IPS/222_In_Out.htm
Functioning of the system url_IPS/IPS/2221_Functioning.htm
The primary useful function of the system is to verify proper specimen and blood.
System inputs url_IPS/IPS/2222_Input.htm
* Patient information
* blood or specimen information
* time
* date
* doctor or nurse id
System outputs url_IPS/IPS/2223_Output.htm
* confomation of administration
* logs of what of what has been done
* information to be sent to billing
Cause - Problem - Effecturl_IPS/IPS/223_Cause_Eff.htm
Problem to be resolved url_IPS/IPS/2231_Problem.htm
The system is designed to verify that the correct blood trasnsfusion is given to the correct patient or that the correct sample is taken from the correct patient.
Mechanism causing the problem url_IPS/IPS/2232_Mechanism_causing_the_problem.htm
Human error, handwritten orders and validation are not good enough. Too much paperwork, cumbersome to do
Undesirable consequences if the problem is not resolved url_IPS/IPS/2233_Undesirable_consequences.htm
DEATH
Other problems to be solved url_IPS/IPS/2244_Other_problems.htm
none
Past - Present - Futureurl_IPS/IPS/224_Past_Future.htm
History of the problem url_IPS/IPS/2241_History.htm
With the advent of the digital age doctors and nurses no longer want to use paper systems to verify their work. Also the old methods are no longer working.
Pre-process time url_IPS/IPS/2242_Pre_proc.htm
Before patient has any work done
Post-process time url_IPS/IPS/2243_Post_proc.htm
After patient has work done
Resources, constraints and limitationsurl_IPS/IPS/23_Resources.htm
Available resources url_IPS/IPS/231_Available_resources.htm
Informational Resources:
* Blood transfusion and specimen collection workflows
Substance Resources:
* wireless technologies
* bar code reader
* small pda's
Human Resources:
* nurses
* doctors
Allowable changes to the system url_IPS/IPS/232_Allowable_changes.htm
* Small changes are allowed
* Cannot go out of way of nurses and doctors
Constraints and limitations url_IPS/IPS/233_Constraints.htm
* Must be done by 4/22
* Making sure it is a universal system
Criteria for selecting solution concepts url_IPS/IPS/234_Criteria.htm
* Must be a robust universal solution
* Few to no human consequences
Problem Formulation and Brainstormingurl_IPS/IPS/3_Functional_Modeling.htm
eMedsdgr__url_IPS/Diagram.htm
[pic]
-----------------------
[pic]
Figure 1. Specimen collection prototypes are shown. Also included in Appendix 2.
[pic]
Figure 2. A screenshot of the software implemented on a touch screen PDA is shown.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.