T8
From SoftwarePractice.org
Contents |
Inception
In this phase we will determine the business case for the system.
Group Members
| Group Member | Student ID |
| Steven White | 10308157 |
| David Tong | 10600171 |
| Brendan Walsh | 10460158 |
Project Decision
Team 8 decided on Topic A. Tagged Object Finder (TOF), primarily because we had several ideas for the TOF and also found it to be an interesting technology.
Meeting time
10-12 Thursday: Only met when group decides that it's needed. ]] Otherwise, group work should be discussed, reviewed and assigned in tutorial times and finished over the weekend for possible revision by other group members early the following week.
Project Logs
Each group member can option to use the below online Project log for this assignment so other group members can utilize it as a project resource.
This will give other group members an insight into what is being done by the rest of the team to prevent overlapping of work and to aid in creativity due to a different perspective.
Project Books
Functional Requirement
The aim is to develop a software that interfaces with a mobile device to track, and create a list of items that have been tagged with radio frequency transmitters (RFID).
The usage of the application and hardware will enable departments within hospitals to locate and keep a record of surgical instruments by providing the following value proposition:
- Increased patient safety: surgical instrument contaminations and infectious diseases can now be isolated
- Hospital financial benefits: tracking of surgical instruments will save hospital hundreds of thousands of dollars as they are now able to isolate which instruments are contaminated and destroy only those ones, as opposed to all surgical instruments
System Elements
In order to implement the project, the following resources will be needed:
- Server: to act as a data warehouse for primary information
- Mobile scanning devices: to effectively scan for Radio Frequency Identification (RFID) tags. These devices will also contain the software developed to scan for the RFID tags
- Users: consisting of theater staff, Central Sterilizing Department (CSD) staff, doctors and nurses
- Surgical instruments: these include trays which all have to be marked with RFID tags
Stakeholders
To utilize the RFID tag on surgical instruments within private practices and hospital groups. This will be used to track and perform inventory management of surgical instruments.
The primary beneficiary will be of the Central Sterilization Departments (CSD) within hospitals. Their primary objective is the cleaning, packing and distribution of surgical trays and surgical instruments. They are also responsible of infection control which they manage by overseeing the sterilizing and maintenance of the surgical instruments.
The personnel that will be utilizing this product will be:
- Theatre nurses
- CSD Staff
- Surgeons
Key Risks
The following are a list of key risks that could cause the project to fail:
- Cooperation from users is limited
- Lack of acceptance by users due to change of workflow
- Application can not function in reasonable timeframe
- Lack of financial funding for hardware, software and training
- Surgical instruments are unable to be marked by RFID tags
Elaboration
In this section we will determine the architecture and requirements.
Usage Scenarios
Instrument Detection
A surgery is completed on a patient in the operating room and all surgical trays and surgical instruments are placed back on the trolley. The mobile device is activated by a theater nurse and placed above the patients head. The device is then moved down towards the patients feet. This process detects any RFID-marked surgical instruments that can be left in or around the patient.
Locate Instruments
A case of Bovine Spongiform Encephalopathy (BSE), otherwise known as Mad Cow Disease is detected in an autopsy on a patient who passes away a few days after recovering from a neurosurgery. As BSE consists of infectious proteins, they can not be removed through means of the sterilization process performed by the CSD. If this occurs, all instruments that are at risk of being contaminated will need to be recalled from inventory and destroyed. This is just one case of infectious disease that can contaminate surgical instruments that results in the need to track the surgical trays and surgical instruments.
How the mobile device will assist in this process is that the user will be given a list of surgical trays and instruments and they will then enter these RFID numbers into the mobile device. The user then walks through the CSD, storage rooms and surgical theaters to locate these items for recall.
Inventory Stocktake
A stock-take of surgical trays and surgical instruments can be performed by scanning the CSD, store rooms and theaters. This will count the total number of trays and surgical instruments for inventory management purposes.
Usage Scenario Assumptions
- Recalled instruments: as part of the process of recalling all instruments at risk of contamination, all patients that have been exposed to the surgical instruments also have to be informed that they are at risk of contracting BSE. However, for the scope of this project, we will not cover this aspect because the mobile device will not hold confidential patient data. We assume that the hospital will be able to track the surgical trays and instruments to the pateints.
- Locate instruments - Loan items: the hospital will locate the surgical trays and instruments that are on loan to other hospitals and be responsible for their recall.
- Locate instruments - Search area: the CSD, store rooms and theaters are approximately 3575 square meters in total and a complete walk-through of this area for detection purposes will take five minutes. This time frame does not include the time it takes for instrument or tray collection. This search area is based on the floor plans of the CSD, store rooms and theaters of the Children's Hospital, Westmead.
Use cases
| Usage Scenario | User Action | System Responsibility |
|---|---|---|
| Locating Instruments (Example: Finding possibly contaminated surgical instruments) | 1. Select search mode 2. Enter tray/item numbers. 5. Run scan analysis 6. Verify item/tray for each new tray/item added. 8. User stops search | 3. System validates tag ID. 4. Add all items to a list and display the radar 7.Remove ID numbers from search list once validated. |
| Instrument Detection (Example: Surgical instruments lost in a patient) | 2. User moves detector over desired search location. 3. User validates located items and stops the search. | 1. Display radar and begin scan analysis, display list of found item(s). |
| Inventory Stocktake (Example: Accounting for possible loss of instruments) | 1. Select multiple search mode. 4. User validates located items/trays and either stops or continues search. | 2. System runs scan and displays radar. 3. Displays list of all located items/trays. |
Use case diagrams
CRC
| Class Item: | |
|---|---|
| Responsibilities | Collaboration |
| Store tag information | |
| Class Tray: | |
|---|---|
| Responsibilities | Collaboration |
| Store tray information | |
| Class Sensor: | |
|---|---|
| Responsibilities | Collaboration |
| Identify tags and trays in the region | Tells the tag manager about the tags and trays in the region |
| Class TagManager: | |
|---|---|
| Responsibilities | Collaboration |
| Receives events from sensor | Tells main what it wants to know about the tags/trays. |
| Manages tags | Gets tag info |
| Class MainFrame: | |
|---|---|
| Responsibilities | Collaboration |
| Interprets the user interface and manages the state of the program | Receives user instructions Tells the Manager what it wants to listen to |
| Class Display: | |
|---|---|
| Responsibilities | Collaboration |
| Shows the user the tags in the range | |
| Prompts the user for instruction | |
Diagram of how prototype fits into overall device
The main components of this system, software and hardware, are linked in a main box as they are the center link in the prototype system. The software side contains several components such as user input and a set of classes. These software components link directly to the hardware as classes become visible in tangible form. Hardware is made up of several elements: the interface a user interacts with and the devices' sensor and the tags which the sensor is used to find.
UI Sketches - Initial
Picture 1 and 2 show the tags in the immediate region as a radar view and as a list view
Picture 3 shows the found tags as a list
Picture 4 shows the unfound tags as a list
Picture 5 shows the form for adding a new item to the database
Picture 6 shows the item description
Picture 7 shows the screen to start a new screen
Picture 8 is the about screen
Main Menu:
- Manage
- Add Item
- Del Item
- Find Item
- New Search
- About
- Quit
Search Menu:
- Cancel Search
- Show found Tags
- Show unfound Tags
- Show Unknown Tags
- Quit
Initial Class Diagram
This is an initial class diagram of all key functional elements
Source file[1] created with ArgoUML [2]
Initial Sequence diagrams
The following is an initial sequence diagram of the important interaction which is of the use case " Locating Instruments"
Source file[3] created with ArgoUML [4]
"Instrument detection": searches for any devices within the 10 meter radius and displays the tags on the radar and found/unfound item lists. These tags are updated as more are found. This use case is different from "location of instruments" as it searches for any tags within the area as apposed to tags specified by the user.
Flagging items: this does the normal search for either specific or any tags, but once found, the user has the ability to update the tags as found or unfound which adds or deletes them from the radar and list views.
Construction
Final Class Diagrams
Below is an image of the final version of the class diagram.
Source file created with ArgoUML
Source Code
The source code will be under Subversion (svn) control and is hosted at https://www.steveqazs.info/svn/OOD
To view the code in a web browser click here
To access the code download and install an svn client like TortoiseSVN or scplugin for macs (I don't have a mac so I haven't test this...)
Once installed, create a folder on your computer where you want the source.
Right-click on the folder and choose checkout.
Type in "https://www.steveqazs.info/svn/OOD" for the url of repository.
Hit OK.
Enter in your username and password.
Commands:
Update - get newest copy of source
Commit - save any changes you've made to the server
Revert - undo any changes you've made
Setup details
The following tools were used to control the code, manage the repositories and users, and to host the code on the web.
SVN: The source was managed with subversion.
Web View: The web view (WebSVN)was used to display the latest copy of the code with history and log details. The code can be viewed, nicley formated with colorization. It was was configured to run on apache with multiview support.
USVN: Userfriendly SVN is a web management system for SVN. It can be used to create repositories, mange users and groups, and to configure repository permissions. This was also run on apache.
Apache: Apache is a web server that was used to host all the tools listed above, and was installed on Windows 2003.
Ask or email me if you have any questions on the setup or configurations for the above tools.
Final Application
Below contains screen shots of the final application and a brief description as to the purpose and functionality of the screen.
About Screen
This screen was made to provide the user with a brief description of the origins of the application.
Find Item Screen
The instrument RFID tag is entered into this screen which adds the item to the list of items to be searched for.
Found Items Screen
Provides a list of all items that have been marked as found by the user. This screen offers the functionality to mark an instrument "Unfound" in the event of human error or the misplacement of the instrument.
Item Description Screen
When a user is on the radar screen searching for items to be found from the list, the blue markers will appear on the radar for instruments that coincide with the instruments on the list. The user is then able to click on the blue marker on the screen and they are taken to this screen which displays the full details of the instrument.
Known Search Screen
This is the main radar screen that shows the ten meter vicinity of the scanning area. The center of the radar represents the user with the device and each ring represents two meters. All items that have been marked to be found will be displayed as blue markers on this screen.
New Search Screen
To conduct a new search, the user must enter in the desired instrument/tray RFID tag numbers. These tags will be appended to a list which will be used for searching purposes in the Radar Known Search screen.
Test Sensor Module
To emulate the system test cases, we developed this Test Sensor module which if used to mimic items that may appear in the area. This module is utilized by entering the item which is added to an independent list. In the main application, the user needs to enter this same item to be searched for. The Test Sensor will then provide the blue marker on the radar screen if both of these item ID's correspond.
Unfound Items Screen
When an item is found from the radar screen, the user can flag this item as being found by entering this screen, the Unfound Items screen. In this screen the user is able to flag the item as Mark as Found.
Radar - Unknown Search Screen
The Radar Unknown Search screen displays items in the vicinity that have not been marked to be found. This is particularly useful in the event that an operation has finished on a patient and the Theater nurse performs a scan over the patient to detect if any instruments are present, where the detail of the instrument is irrelevant. The unknown items are displayed as orange markers on the radar screen.
Transition
System Test Cases
The system test cases are based on the Usage Scenarios Use Cases and are designed as a walk-through for the prototype application to test the overall system. Below are the following system test cases:
- Instrument detection: the theater nurse places the mobile device over a patient in the Operating Room (OR) and activates the device. The radar is initiated which detects any RFID marked surgical instruments in the vicinity. These markings appear as orange markers on the radar screen (refer to T8#Radar_-_Unknown_Search_Screen)
- Locating items: the theater nurse will provide a list of surgical items and tray RFID tags to the CSD staff who will enter these tag ID's into the application (refer to T8#New_Search_Screen). This will generate a list of items to be flagged to be found and appear as blue markers on the Radar search screen (refer to T8#Known_Search_Screen)
- Flagging items: the user is able to mark an item as found or lost. This is done through the following screens, T8#Found_Items_Screen and T8#Unfound_Items_Screen
Contracts
The contracts were designed defensively, we chose to do this to help reduce the number of bugs during the development phase. This choice allowed the caller to not need valid data to have a defined output, it also allowed the error checking to be in one place, the callee. This helped reduce the amount of code, the complexity and the likelihood of undefined output causing bugs.
Item Class
| Method | Pre Condition | Post Condition |
|---|---|---|
| addChild(item : Item):boolean | null | returns true and adds item to list if its an item, otherwise returns false |
| contains(ID : String):boolean | null | returns true if the this item contains a child item with the ID |
| getChild(ID : String): Item | null | returns the child item with the ID if it contains it, otherwise returns null |
| getChildIDs():List<String> | null | Return a list of child IDs |
| removeChild(ID : String):boolean | null | removes the child if it contains it |
| readObject(stream : ObjectInputStream):void | ObjectInputStream is a valid stream for an item | loads the item object from the stream |
| writeObject(Stream : ObjectInputStream):void | ObjectInputStream is a valid stream object | saves the item object to the stream |
Instrument Class
| Method | Pre Condition | Post Condition |
|---|---|---|
| addChild(item : Item):boolean | null | returns false |
| contains(ID : String):boolean | null | return false |
| getChild(ID : String):Item | null | return null |
| getChildIDs(): List<String> | null | returns an empty list of IDs |
| removeChild(ID : String):boolean | null | Return false |
Tray Class
| Method | Pre Condition | Post Condition |
|---|---|---|
| addChild(item : Item):boolean | null | returns true and adds item to list if its an instrument, otherwise returns false |
Util Class
| Method | Pre Condition | Post Condition |
|---|---|---|
| load(fileName : String):Object | null | returns an object if the file points to a valid serialized object, otherwise return null |
| save(object : Object,filename : String):void | null | saves the object to the file pointed by filename |
Test Cases
| Test Case | User Action | System Responsibility | Expected | PASS/FAIL |
|---|---|---|---|---|
| Locating Instruments | 1. Enter tray/item numbers and select the "Add Item" button 4. Run scan analysis 5. Verify item/tray for each new tray/item added using the found and unfound items panels 7. User stops search by pressing the "cancel search" button in the main menu | 2. System validates tag ID. 3. Add all items to found/unfound items lists and display the radar 6.Remove ID numbers from search list once validated. | 1. Item is read and added to search database 2. Tag is checked to see if it exists 3. Items are added to found/unfound items lists and the radar is displays with the specified points marked in red or blue. 4. Starts search. 5. Found/Unfound items verified 6. Once validated, ID numbers removed from search list 7. Search is stopped | PASS |
| Instrument Detection | 2. User moves detector over desired search location. 3. User validates located items in found items panel and stops the search by pressing the "cancel search" button. | 1. Display radar and begin scan analysis, display list of found item(s). | 1. Radar is displayed and searches for any present tags and displays a list of the found item(s) 2. User moves detector over desired search location to find new tags 3. Located items validated and search is stopped on request. | PASS |
| Flagging items | 3. User selects found/unfound items and marks them as found or unfound | 1. Display radar and begin scan analysis. 2. Populate lists of found and unfound items. 4. Remove designated items and adds/deletes the items from the radar and respective lists. | 1. Radar is displayed and searches for any present tags 2. Found/unfound item lists populated 3. Items will be removed from search list or changed to a found or unfound item 4. Items removed/added to respective found/unfound lists. | PASS |
Collaboration
All team members contributed to the assignment as a whole equally.
- Steven took lead of the development tasks and had the assistance of David and Brendan
- David took lead of the documentation and maintenance of the wiki with efforts from Brendan and Steven
- Brendan took lead of the GUI layout and was assisted by Steven and David
All team members contributed to every aspect of the assignment but had group leaders for each aspect of the assignment to ensure quality, direction and timelines were maintained.
References
- Wikipedia, 2007. Bovine Spongiform Encephalopathy, viewed 31 August 2007, <http://en.wikipedia.org/wiki/Bovine_spongiform_encephalopathy>
- Wikipedia, 2007. Surgical instruments, viewed 31 August 2007, <http://en.wikipedia.org/wiki/Surgical_Instruments>
- Sterilizing Research Advisory Council of Australia, 2007. Sterilizing Research Advisory Council of Australia - SRACA New South Wales, viewed 31 August 2007, <http://www.sraca.org.au/content/blogsection/3/17/>
Archive
The following link displays all work that has been replaced due to iterative design and collaboration.
