Group Red
From SoftwarePractice.org
This is our Team Red document
Contents |
Introduction
Overview
The Smart Hospital System (SHS): Patient Information Management System has objectives to enhance the existent system in St. George Hospital to support the patient information by having a computer system built. Allowing medical staffs more comfortable to acquire information by using PDA/Mobile. Moreover, this system would exterminate all existent problems in the old system such as; data misinterpreted and data entry time consuming. Therefore, St. George Hospital could be handling much more patients without any error.
Abbreviation Table
SHS - Smart Hospital System (the software this Architecture is for)
PDA – personal digital assistant
Stakeholder needs
The stakeholder needs is one of the most important issues need to be concerned in order to implement software system. In this chapter, the stakeholder needs for SHS will be examined with personas and scenarios approach which is classified into usage narratives and system narratives.
Usage narratives
Nikki, who currently works as a secretary in St. George Hospital for a couple of months, she is very young and has got a very good typing skill. When a new patient visits the hospital, she needs to entry all significant demographic informations from the patient into her personal computer by using SHS in order to store those informations.
When a patient has been decided to be admitted, she need to use SHS in her personal computer to create patient's admission record from patient identification number and assign a medical staff to be a primary doctor for that patient.
When a patient has discharged, she needs to record discharge date and time to the system by using SHS in her personal computer.
When new staffs have joined the hospital, she needs to record that staff information by using SHS in her personal computer.
Ryan, who currently works as a doctor in St. George Hospital for ten years, does not know much about how to use the computer especially the PDA/Mobile.
When he needs to decide whether his patient needs to be admitted or not, he would like to know more information about his patient. Therefore, he search and obtain his patient data with SHS in his PDA/Mobile by using patient name or patient identification number.
When he has finished diagnosing his admitted patient in ward, he needs to record his general comments, date and time by using SHS in his PDA/Mobile.
Debra currently works as a nurse in St. George Hospital. She would be 55 years old this year. She is not so very keen using any technology equipments before. Anyhow, she really likes to try SHS in both PDA/Mobile and personal computer. Therefore the system should be ease to be used.
When she observes the patient vital signs such as blood pressure, temperature, respiratory, heart rate, therefore she needs to record that information into the patient's admission record by using SHS in her PDA/Mobile.
When she needs to inject the glucose to the patient, she needs to check the glucose balance summary from her PDA/Mobile before intake to the patient. Therefore, she needs to record the new balance of the glucose by using SHS in her PDA/Mobile as well.
When she has finished giving patient medication, she needs to record that information by using SHS in his PDA/Mobile as well.
System narratives
Smart Software Company was established in 2002 to serve the growth of small to large enterprise business needs for network infrastructures and business applications. Within months of operation, Smart Software Company has evolved into one of Sydney's leading providers of complete solutions for network computing and e-business. With strategy to focus on building clients' relationship as the Partner' and proven quality of work and service mind, Smart Software Company have been able to aggressively and continuously expand services arenas as well as our market reach cross border since early days. SHS is one of the newest projects in the company which will be implementing soon.
Emma currently works as a developer in Smart Software Company. She just finished her university three months ago and joins the company. She is very young and does not have so much experience in IT industry. She has been assigned to be a developer in this SHS project.
Emma wants to implement SHS which would be able to support the patient information by having a computer system built to help St. George Hospital gather patient information from the manual information with the help of data entry in the hospital. Moreover, SHS would allows medical staffs to acquire medical and patient information by using both personal computer and PDA/Mobile which would then be synchronized with a server through wireless means.
Contextual factors
This chapter is to present all those factors relative to the SHS that belong to the real world setting of the System and there is need to account for when designing the System itself and its Architecture, but which are external to the actual project since they are not a part of the software or its realization process.
General view
The SHS is to replace the old paper-based documentation system of a hospital. In particular it will have to keep track of all patients' records, allow medical staff to update them quickly and easily through the use of a PDA, automatically keep track of patients vitals such as body temperature and let the medical staff dispose of them at their fingertips.
Being the system designed to keep most of a hospital's sensible information, it is important that it abides to high standards of reliability, security and efficiency since system failures may lead to ineffective or damaging work of staff and ultimately have heavy repercussions on the economy of the hospital and the health or even survival of patients.
Specific Contextual Factors
An analysis of the SHS context led to the identification of the following factors:
Constraints:
- PDA related - A PDA device is not a portable computer: the screen is much smaller, the computing power is significantly less, and the input of data is time consuming and often unnatural. The PDAs should thus have interfaces allowing users to have at their fingertips as much information as possible in a compact and well structured easy to access way, and to efficiently input data, but the design must acknowledge that in no way will be possible to effectively replace all functionalities of a desktop computer with a PDA.
- Uniqueness of central Server – There must be only one Central Server (as abstraction) which is able to keep up with the workload and keep coherency of data and guarantee against lost of data through proper recovery systems.
- Work required moving the new system – This is not technical constraints, but is important to consider the cost of moving to the new system since staff has to be trained and old paper records need to be manually copied on the system, introducing risk of mistakes.
Enablers:
- Market presence of all supporting technology and development tools – Everything needed to backup the realisation of SHS is already on the market: PDAs, computers, database software, Wireless hardware and drivers and development platforms to support programmers such as Microsoft .NET and Java development tools. Nevertheless it is important to carefully choose the platforms and tools to use since this may heavily affect the performance of the system and other non functional aspects such costs of realisation, security, scalability, maintainability and so on.
- Gains from the replacement of the old paper-bases system with SHS – Advantages of a SHS-like system versus old paper are certainly the main drive to the built of the system: there is a broad and rich market for a system like SHS since soon nearly all hospitals will realise they need to move to the electronic world to stay competitive and give the best service, in a field where better service can mean survival of patients.
Risks:
- PDA Related – A PDA can crash, break, be stolen and so on. It is important that the SHS seriously takes into account all of those possibilities. A proper Architectural Design, aimed at minimizing the responsibilities of PDAs, can significantly reduce the damages associated with the arise of PDA-relates risks. This category of risks ranges from low to moderate: with a good design most times rebooting or replacing the PDA will be a good response to the problem, costing a little time and possibly few hundred dollars. It is nevertheless possible a PDA accident slows the access to urgent critical data. It is thus important to care about having reliable and secure PDA software and hardware in order to minimise risks of dangerous occurrences and misuse.
- Server Crash – This is critical risk. A crash of the server will likely stop the system for possibly long time before the whole system is restored and operative. This may lead to wast of time that is often a key factor in saving lives and having successful operations. Server Crashes should not occur, and an efficient backup plan is needed in case one happens.
- Loss of Data – Data stored in a hospital archive is often very important and critical of doctors to make accurate diagnosis. Besides the economical damage, loss of data can thus lead to health risk hospital's patients.
- Typos – This is mostly a minor risk, but can still cost in terms of time needed to understand the corrupted information. The SHS decreases the chance of typos respect to an old paper-based system, but the initial copy in the system of previous data is likely to produce many mistakes. Some mistakes can also lead to misinterpretations with deriving risks similar to those for the loss of data.
- WiFi Interference with Medical Instrumentation – This is a risk unlikely to occur, since the WiFi signal are normally too weak to interfere with most instrumentation, but further research might be required.
- Malicious Security Violation – This is a social risk. Medical data are often confidential and client's privacy and hospital's internal information are to be seriously taken into account. Theft of data can lead to heavy economical loss and legal actions.
Functional requirements
This section present what are the main behaviors of Smart Hospital system. In content, the main requirements are show as table of requirement as well as two kind of use cases diagram including essential use cases and use cases diagram.From information in document called User Requirement Specification, there are many services such as patient profile, staff profile,observation, medication and diagnosis etc. This system seperate main users to be four types, which are admin staff, data entry, nurse and doctor, that all of them are descrbed in Stakeholder saction.
Function Requirement overview
Functional requirements define the work or service provided by software system. The program will do any activities such as display, process and data management based on functional requirements. They specify the behaviors of program or what system will do. Typically, non-functional requirements are conditions to make functional requirements. The following table presents main function requirements of Smart Hospital System.
| Ref No. | Requirement |
| F01 | A secretary shall be allowed to manage information inside main function including demographic and staff. |
| F02 | A nurse shall be allowed to organize function including observation, medication, fluid balance. |
| F03 | A doctor shall be allowed to mange function including observation, medication, diagnosis, fluid balance and discharge. |
| F04 | The message shall be allowed to show when username or password is not verified. |
| F05 | All staff shall be authenticated through their usernames and passwords. |
| F06 | A doctor shall be allowed to view every function |
| F07 | A nurse shall be allowed to view any functions |
| F08 | The system shall allow observation function to provide Date, time and detail. |
| F09 | The system shall allow diagnosis function to provide Date, time, doctor and purpose. |
| F10 | The system shall allow medication function to provide Date, time and detail. |
| F11 | The system shall allow staffs function to provide identification number, name, type and detail. |
Use cases
Use case is a part of object-oriented analysis and design, although it is not refer in object-oriented content. Use case provides black box diagram of the functional requirement. In the content, two kinds of use case, which are essential use case and use case map, are provided to understand overall structure of hospital system. Essential use case is a use case that focuses on simple, general and essential structure. Use case diagram is applied because it is a basis for architecture design.
1. SHS as essential use case
| User action | System responsibility |
| Log in | |
| Connect to server | |
| Valify ID and password | |
| Identify user | |
| Provide choice service | |
| Choose service | |
| Show service | |
| Manage data | |
| Update data | |
| Log out |
Table 4.1: Essentail use case of Smart Hospital System
2. SHS as use case diagram
The use case digram for SHS are shown in Figure 4.2, 4.3 and 4.4.
Figure 4.2: Use case diagram of Smart Hospital System for secretary
Figure 4.2: Use case diagram of Smart Hospital System for doctor and nurse
Figure 4.2: Use case diagram of Smart Hospital System for doctor and nurse (Cont)
Non-functional requirement
Non-functional requirements commonly are the quality attributes of the system or the constraints on the services or functions offered by the system that would help in order to meet with the client needs. This chapter will emphasize on the non-functional requirements for SHS which divide into runtime quality attributes and non-runtime quality attributes.
Runtime quality attributes
Functional requirements capturing what the system must do, and the run-time qualities as describing how well these functional requirements are satisfied, Run-time qualities attributes are as follows (PURS):
Performance
Performance constrains the speed of operation of the system. The performance quality allows user to be more productive.
- The response time between PDA/Mobile and Smart Hospital Server should not be greater than 5 seconds.
- The response time between personal computer and Smart Hospital Server should not be greater than 2 seconds.
Usability
Usability is the ease with which the system can be learned or used. It is very importance because mostly user in the hospital may not be familiar with using the application on PDA/Mobile.
- SHS should allow users to install and operate it with little or no training.
- SHS should not allow to have a interface that user have to enter more than ten data.
Reliability
Reliability typically refers to availability including, mean time between failures, mean time to repair, accuracy, and maximum acceptable bugs.
- The system shall meet the terms of a Service Level Agreement.
Security
Security refers to the ability to prevent and/or forbid access to the system by unauthorized parties. The patient information must be kept secretly because of the privacy.
- User authentication shall be via the corporate Single Sign-on system.
Non-runtime quality attributes
For those requirements which are not effect on the operation of the SHS are as follows (MeTRiCS):
Maintainability
Maintainability is the ease with which a system can be fixed or add new components.
- SHS shall provide document for the system maintenance.
- SHS shall have maintenance time once a week.
Testability
Testability is the ease with which a system can be tested.
- SHS shall be able to be tested anytime at different levels during before or after deploys the system.
Reusability
Reusability is the ease with which a system or components have ability to (re)use in future such as libraries, classes, databases, web servers and middleware.
- SHS shall have well design and good document to collect all software components in order to be use in the future.
Configurability
Configurability is the ease with which a system can be configured for diversity purpose or installation.
- SHS shall provide a set of configuration files in order to specify system parameters.
Scalability
Scalability is the ease with which a system or component can be modified to handle a large increase in users, workload or transactions.
- SHS shall be able to extend the system in order to handle with high workload situation or handle with more patients.
Additional quality attributes
Robustness
Robustness is the resilience or ability to recover quickly from change, or misfortune. It is one of the most important attribute that need to be concerned in SHS. For example, when the computer or server have been crashed, technically procedure need to be prepared in order to handle this situation.
- SHS shall have the patient data backup every day.
- SHS shall have the substituted server and computer.
Focusing quality attributes
In order to successfully design good software architecture, the main focusing non-functional requirements should be focused on. In SHS, the main focusing quality attributes are robustness, performance and scalability.
The reason why performance attribute need to be focused on because, when the clients operate SHS and found out that it was not as fast as they are expected, the client would probably not satisfy with the system. Therefore, scalability would allow the system to be extended in order to handle much more patient in the future and improving system performance as well. Moreover, accident in SHS could be occurred anytime, for example server has been crashed and database had been lost. If SHS has robustness, it would leads SHS be able to work up on this kind of situation. All of these non-fictional attributes would be considered and mentioned along this paper in order to improve the software architecture design.
Conceptual architecture
This Paragraph aims to present an overview of the architecture for the SHS: the components which build the system and how they should interact with each other and interface to the external world.
General View
The SHS is a system which aims at easing the handle of paperwork and recordings needed by a Hospital. The following figure shows how this is achieved through the use of a number of devices: the central Server which holds the database with all stored information, the PDAs and PCs which furnish UIs to access the DB and record new information, the (temperature) sensors which are programmed by the medical staff through the PDAs and PCs which send them signals through the Server, and which send to the Server read data to be stored in the DB.
Figure 6.1: the central Server gets information about data requests and data updates from PDAs and PCs, which provide UIs for different types of users, and sends requested data. The sensors just send data to the Server which is responsible for storing it properly.
High Level Architectural Model
An application to handle Hospital's sensitive data must be reliable, secure, robust. For this reasons a Fat Server - Thin Client Architecture will be used: The server is to store all the data and the only part of the system to store data, while the Clients are to simply be a through between the Server and the Users, furnishing UIs and efficient connectivity to the Server. This approach minimizes risks of data inconsistency and survival of obsolete data, it makes easier to back-up the system, relives Clients from heavy workload (crucial for PDAs), allows to easily block any possibility of malicious actions from a stolen PDA. The only computation left to the Clients is the one needed by the UI to work, build graphs from read data, and so on. To ease the maintenance and future improvements of the system, an N-Tier Architectural model is used. The following figure shows the layered structure of the System. Note how the Sensor Controller is implemented on the server as a separate entity since in programming the sensors the Server is simply a convenient through (saves the built of a direct connection between Clients and the sensor).
Figure 6.2: the N-Tier Conceptual Archetectural Schema
Data Model
Before showing the final Architectural Model, we show a figure with the Database's model, so that it is possible to get a better understanding on exactly what the system does, and what kind of data are stored/handled by the different parts.
The following figure shows an approximate Database Schema for the SHS.
Figure 6.3: the Data Model for SHS
The Architectural Model
The Following Figure shows the complete Architectural Model for the SHS. The set of all Components (non-coloured rectangles) excluding the 'Sensor Programmer', 'Sensor Listner' and 'View Hospital Proc. Doc' ones, constitute what we called the 'Data Organiser' level in the High Level Architecture.
Figure 6.4: SHS extensive Conceptual Architecture
Use Case Maps
This paragraph shows the execution flow of significative Use Cases (misssing ones are nearly all the same) through the components of the Conceptual Architecture. This works as a test of the Conceptual Architecture itself since shows that it is effective in backupping a system able to respond to the identified user needs. Notice the more complex Use Case 'Modify Patient Demographic Data' in which 'View Patient Demographic Record' is automatically called in order to retrieve the present data which will be shown to the User who can than modify it.
Figure 6.5: Use Case maps
Execution architecture
This chapter will be focused on an execution architecture which is how to view the system in terms of its runtime structure by capturing all components that exist during system execution into a set of models.
Execution architecture design
Concurrent subsystems
The reasons why this topic chooses to be focused on a concurrent subsystems view rather than a process view because of the scalability of the system which the components are located on different processors. For example, many clients including personal computer and PDA/Mobile are operated by requesting the data from other subsystem. Anyhow, there are two concurrent subsystems for SHS. The first one is concurrent subsystems for typically operation, and the second one is concurrent subsystems for temperature sensors operation.
Consider the concurrent subsystems model of typically operation in SHS as shown in Figure 7.1, it consists of four concurrent subsystems; one containing the user interface for personal computer client; other one that contains user interface for PDA/Mobile client; one is SHS data organize that has responsibility to handle request from all clients and retrieves patient data from SHS database subsystem; and the last one is SHS database which is collecting all patient data and handle data request from SHS data organize subsystem.
Figure 7.1: Concurrent subsystems of typically operation in SHS
Another concurrent subsystems model for SHS is shown in Figure 7.2. It shows the Physician's and Nurse's UIs, which both can both message the Sensor Controller and Interact with the Data Organizer, and the Temperature Sensor's Listener, which also uses the Data Organizer's services, working concurrently and ho they relate to each other. The UIs other than all other functions, allow the Users to control the Sensor's activity, the sensor sends readings to its Listener, with calls the Data Organizer to create a DB entry about the reading.
Figure 7.2: Concurrent subsystems of temperature sensors operation in SHS
Detailed concurrency models
In order to have more clearly view of the concurrency activities in the system, detailed concurrency models would be able to help. This topic will be focused on concurrent object of SHS.
A concurrent object is used to identify a component framework which would be able to support the architecture. As shown in Figure 7.3, it represent the concurrent objects of SHS. There are four remote objects, PC ClientX, PC ClientY, PDA/Mobile ClientX and PDA/Mobile Client; all of these are implemented as concurrent objects and they are requesting or accessing the services. And all services are implemented by a middleware framework which provides a thread pool in order to dynamically allocated service requests to these service objects.
Figure 7.3: Detailed concurrency model for SHS
Behavior
As for consistency between execution architecture with conceptual architecture, Use-case maps need to be used to outline the behavior of the execution architecture. Therefore, this chapter will be analyzed on the behavior of the execution architecture in SHS with runtime quality attribute which is performance.
Runtime quality attributes
Considering runtime quality atrt
Figure 7.4 shows two use-case maps which is CreatePatientObservation and SendTemperatureReading of SHS. CreatePatientObservation use-case map would not have rigorous time-performance demands while SendTemperatureReading activity is real-time component and may require rigorous time-performance demands with constant processing load. There two use-case maps are actually collide in component CreatePatientObservation, therefore the SHS would probably not operating with good performance if those activities are collide.
Figure 7.4: Two use-case map colliding component for sensor operation in SHS
In order to improve performance in SHS, the component that have more than one activities execute on it would be replicated. As shown in Figure 7.5, component CreatePatientObservation has been spilt into two component which is CreatePatientObservation1 and CreatePatientObservation2. Therefore, the use-case maps for real-time activity and user activity are not dependency anymore. The SHS would operate with higher performance. Anyhow, this would be called that SHS is scalability as well.
Figure 7.5: Component splitting based on behavior of use-case maps in SHS
Deployment
Deployment models could be able to show physical components from the allocation of concurrent components. The deployment diagram for SHS is shown in Figure 7.6. There are two server nodes. The first single server node is consists of web service and database server. As well as temperature sensor listener and sensor controller are sited on another single server node. Therefore, multiple nodes would be able to be replicated as many as necessary in order to increase the performance. Client node could be PDA/Mobile client or PC client. They are connected to web service via HTTP.
Figure 7.6: A simple deployment diagram for SHS
Implementation architecture
Implementation archiecture design
This chapter presents Implementation architecture that provides the key technologies for building hospital project. From all of information above, we decide to adapt three-tier architecture, which consist of presentation tier, business logic tier and data tier, to this system. Thus there are three servers of Smart Hospital System including web server, application server and database server.
Figure 8.1: The implementation architecture of SHS
Technology
1. Intersystems Cache: is a post-relational database management required in User Requirement Specification document. It can run on Windows platform and be supported by direct access database tools such as ODBC.
2. ASP.NET: is a set of web development technology requested in User Requirement Specification document. Currently, ASP.NET is integrated completely in IIS version 7.0 made by Microsoft.
3. IIS (Internet Information Services): is Microsoft's Web Server that manages request from client, in this document refer to PDA and PC, and delivers HTTP documents and other file in response.
4. ODBC (Open Database Connectivity): is database programming interface produced by Microsoft that provides link to access database from application layer.
5. .NET Compact Framework: is a version of .NET Framework that is developed for run on mobile device such as PDA. In addition, its applications can be run on PC with full .NET Framework.
6. Mica2 MTS300 sensor: is a type of Crossbow sensor that is required in requirement document.
7. MIB510: is device to capture wireless signal from Crossbow sensor, then transforming it and sending to NC.
8. NC: is program to process data from NC and transfer it to application layer.
9. WAP (Wireless access point): The technology can link together between wired devices and unwired devices. Typically, WAP will receive data with WIFI protocol from wireless devices such as PDA, transforming data to be HTTP request, sending to Server. As well as it can do opposite way since Hospitals are bigger than the area that can be covered by a single Access Point, multiple Accees Points are required, and a routing system which allows PDA to stay connected while moving through areas covered by different Acces Points. System of this kind have been successfully implemented and can be bought as 'off the shelf' products by a choice of producers.
Recovery System
Robustness is one of the three key Quality Attributes we recognized as priorities in the realization of our system. Performance and Scalability have already been addressed in the Conceptual and Execution Architecture, we will now describe the Crash Recovery and Handling System.
An software of the SHS like should ideally be always able to work properly and never lose any data since Data stored are critical and its availability might be determinant in allowing Doctors and Nurses to work at best of their possibilities.
The following picture shows how the System is implemented in order to Guarantee an up-time of nearly 100%.
Figure 8.2: Recovery System
As shown by the picture, the robustness of the system is guaranteed by a number of ‘extra’ separated machines who back up the server and for the server when needed. The circle represents the point all data goes through just before reaching the server / leaving from the server, basically is the sum of the data moving through the Wi-Fi network and the cable connection to and from the Server. The whole traffic is captured by a Transaction Tracker that stores on its Hard Drive all the signifying traffic since the last DB backup. The server is Cloned by another identical machine which keeps in the same ‘state’ of the original Server, except that does not send requested information out (since the main server does it). Another extra machine backs up the DB from the main server every fixed amount of time (for example 24h), using the DB backup functionalities. If the main Server crashes, the Clone Server immediately takes its place as new main Server, while the corrupted Server can be restored and updated using whatever needed (new hardware, SHS Server installation) and the back upped DB and the Transaction Tracked by the Transaction Tracker. This system ensures that no single failure can block the SHS, and no double failure can lead to a loss of stored data.
Unfortunately this system has a cost in terms of scalability, especially is the main Server is stored on many physical machines. This might be partially resolved by using an undersized Clone Server, which would still keep the System up, but with worse performances, in case of a failure of the Main server. Anyway, most likely modern computers are fast enough to handle the amount of data needed by SHS users, with only expensive resource being (potentially) the DB which might grow considerably.
Implementation architecture design with recovery system
Therefore, the implementation architecture after improve robustness by including recovery system is as shown in Figure 8.3.
Figure 8.3: Implementation architecture design with recovery system for SHS
Reference
- Constantine L L. and Lockwood L A. D.(2000),"Software for Use",published by ACM Press.
chapter 5: Working Structures: Task Modeling with Essential Use Cases
- Reekie J. and McAdam R.(2006),"A Software Architecture Primer,published by Angophora Press.
chapter 1: An Introduction to Architecture
chapter 2: Architecture Analysis
chapter 3: Architecture Design
chapter 4: Conceptual Architecture
chapter 5: Execution Architecture
chapter 6: Implement Architecture
- John Wood (2006), "How personas and scenarios can change your website for the better", http://www.iqcontent.com/publications/features/article_75/
http://www.iqcontent.com/publications/features/article_77/
