Group Green
From SoftwarePractice.org
Contents |
Introduction
The Smart Hospital project aims to eliminate inefficiencies in St George Hospital's patient information management system by developing a computer-based system using cutting edge technology. St George's current system leaves room for slow, misplaced and misinterpreted work, it is both error-prone and de-centralised, the Smart Hostpital solves all of these problems through the use of PDA/mobile devices, a centralised server and an advanced system architechture.
The benefits of the Smart Hospital project go beyond just eliminating existing problems, the new technology will provide advantages to the hospital such as more relevent information for physicians, more efficient and portable access to patient information, security and privacy of patient information and access to external sources of information through the internet.
Through careful research and planning by Zenon Chaczko and through the observation of existing hospital technologies with similar features we present below a system architecture for the Smart Hospital project which will dramatically improve the storage and management of patient information for St George Hospital.
System Overview
The system developed as the resultant of this project a PDA based medical IS will specifically target the hospital industry, where there is a need for accessing the available information in a particular domain, from any diversified location in the building or area. It will assist the staff members of the St. George Hospital located at NSW, Australia to communicate with the centralized database server that holds patients records through the means of a PDA (Client).
We are developing an archetype of the system which basically describes the architecture and the underlying object oriented design. There is also a brief description on the latest technologies that will help us in developing the eventual system.
Purpose & Objectives
The purpose of the project is to develop a PDA/Mobile based medical information system. The main motive behind the project is to picture a system that would allow simultaneous accessibility of centralized information in the server to the numerous clients (PDA’s) located at different sectors of the building or domain. The added advantage of centralizing the data is reduction of misinterpretation by the examiner on the data or notes left by the previous examiner.
At present the data entry of the patient’s diagnosis is done manually, this consumes a lot of labour hours. If the portrayed system is laid out to use it will drastically reduce the time spent on entering the data into the system, which inturn can be utilized to attend the patients. There are different other issues that have to be taken care off while designing the system like reducing the:
• Data misinterpretation
• Data entry errors
• Time lag
• Data storage
• Manual entry of data.
The foremost objective of the project is to allow the GP, the administrative staff to deal with the admission of the patient using a PDA. The various other tasks to be performed are:
• Enter patient information
• Write clinical notes
This information then has to be transferred on to the centralized database server which inturn can be accessible by any physician at any diverse location in the domain using his/her PDA device. They must have the privileges to perform various tasks such as:
• View data regarding admission
• View patient information
• View medical information
• Access to internet based information database
There is a set of project management documents designed that encloses the work done over a period as a report written by the member to assist them in understanding how the discipline of Project Management shall be conducted on the project. It defines the responsibilities for Project Management to be conducted during the project.
• Detailed Project Schedule
• Tracking Progress against the Schedule
• Risk Mitigation Plans
• Quality Control Plans
• Change Request Reports
• Weekly Meeting Reports
• Weekly Progress Reports
Scope
The scope of the project is to integrate the electronic systems in the hospital most of which are disjoint and to allow authenticated entry of patient information on to the hospital server through the means of a PDA device. This information should be transmitted to the authorized PDA device or a PC located at any point within the domain whenever required.
The main hardware interfaces in the system and their association with the users are shown below in a descriptive form,
• Hospital server (SMART)
• PDA client (used by physicians, staff)
• PC client (used by staff)
• Sensors (carried around by the patient to transmit vital stats)
• Wi-Fi (to act as a mode of transmitter between the various hardware’s)
Benefits
The system will follow particular templates for all the data & records. These templates can help doctors/physician to monitor the patient status. Doctors can also change the templates as per their need. This will prevent the misinterpretation of the record or diagnosis.
System will have the up to date information about the patients. That will help the doctors to look at past/current information about the patient being diagnosed.
centralized information will be available from any feasible place in hospital that will help the dictors' to save their time as all the information will be available easily.
issues like data managment and lose of data can be easily solved by the system as all the data will be electronically available. On the other hand issues like security and privacy of the data will also be solved. as it is a hospital system sometimes patients' data is very confidential.
Acronyms, Abbrevations
PDA – Personal Digital Assistance
IS – Information System
GP – General Practitioner
PC – Personal Computer (Desktop in this case)
Wi-Fi – Wireless Technology (IEEE 802.11b protocol)
Stakeholders and Perspectives
Stakeholders are those who are affected by the system directly or indirectly. Here in the smart hospital project we can categorise them mainly into two
Direct stakeholders who include users of the new system, development team, project sponsor/hospital, administrative staff etc Indirect stakeholders include System maintainers, Software providers, Equipment providers, Hardware/ Network implementation team etc
Direct Stakeholders
3.1.1 Users
This is the largest group that is affected by the system and they include mainly Physicians/Doctors, Nurses, Other Medical personnel and Patients.
3.1.1.1 Physicians/ Doctors
They are the main user category, who needs to view / enter patient information using PDA, to view Patients’ admission data, to make clinical notes, to view general medical information including medications to be prescribed, symptoms of various diseases, to connect to internet, to get other data about patients from various sensors and medical equipments connected across. Associate with these functional requirements they expect various non functional requirements like good performance, easy access and usability and more over a 24/7 availability
3.1.1.2 Nurses
They are the user group who depend on the system mainly for monitoring purposes. This includes frequently monitored and vital data like patient’s blood pressure, heartbeat rate, temperature, respiration etc. Also they have to gather a summary of patient’s fluid balance. Non functional requirements stated in previous user group apply here as well.
3.1.1.3 Other medical personnel
They comprises of other medical staffs beside the former groups which uses the system either for monitoring the data or adding information about patient to the system. They may be laboratory staff, medical equipment expertise etc. Non functional requirements stated in previous user group apply here as well.
3.1.1.4 Patients
They are affected by the benefits of the system in various ways like quick admission and discharges, security of the information and their confidentiality, better medical services which are more quick and accurate from the side of physicians and nurses etc
3.1.2 Hospital
They can be called as the ultimate user of the system and also the main sponsor. The whole system is developed considering the software requirements that are handed by this user group. By implementing the new system they can provide a fast, reliable and secure network between their medical equipments, staff and patients thereby improving the overall operational performance as an organisation. They can also keep various records regarding patients and staff and keep track of them using the database of the system. All sorts of non functional requirements imply on their perspectives like Availability, Performance, Scalability, Reliability, Security etc
3.1.3 Administrative staff
They belong to the direct stake holder class as they are interacting with system for Patient and staff administration. Admission, discharge, medical record retrievals, Staff data access are the various tasks that are related to them for which they use the new system. The process like admission and discharge has to be faster and simple when compared to conventional systems.
3.1.4 Development team
The reason for including them as a direct stakeholder is that, ultimately they are going to implement the system and the whole performance and functionalities depend on how they are going to analyse, design, test and implement the system. Their expectations can include maintainability of the system, performance issues, testability, coding and reusability, packages used, software platforms required, user acceptance etc.
Indirect Stakeholders
They belong to a small group of people who have an indirect participation in both system development and maintenance. They can be classified as the following
3.2.1 System maintainers
This is a group of people who are responsible for future system maintenance. They expect proper documentation of the software system, scalable and reusable components, System integrity and design clarity etc
3.2.2 Software providers
They are the group of people who can get monetary benefits upon implementing the system. As the system requires certain operating system platforms to work on, they will be supplying the required. Same is the case with the database packages.
3.2.3 Equipment providers
These are the other set of people who have the monetary benefits by providing various medical equipments as well as computer systems for the complete implementation of the project. Existing sensors and equipments may need to be changed for meeting the requirements of the system. Also there is a need for a s et of Servers, Client stations, networking equipments along with a number of PDA s for the new system.
3.2.4 Hardware/ Network implementation team
They are responsible for the lay out and implementation of all hardware and Network related equipments along with their networking. They work along with the software development team hand to hand in implementation phase.
Contextual factors
Constraints
1) Reduced screen layout size on PDA/Mobile
2) Low processing power and storage space on PDA/ Mobile
3) Software development to be compatible for Mobile based OS
4) Limited data entry capability through mobile devices especially for writing clinical notes
5) Linking the new WiFi-system to the existing legacy system
Enabler
1) IEEE 802.11.b Wireless technology for mobility that is compatible for PDA/ Mobile
2) Mobile Operating system- Mobile windows 5 which can support and run certain softwares
3) Database packages like Oracle or SQL Server
4) WiFi supported PDA/Mobile
5) Wireless sensors and Actuators
6) Middle ware technologies
Risk
1) Performance issues due to low signal strength
2) Malfunction of computers/ Mobile devices/Sensors
3) Data loss due to the failure in database systems
4) Potential intruders/ hackers to the system
5) Corrupted transactions
6) Denial of Service caused by system overload
Criticality
There are different classifications that could be done when considering as system. The system that has to be implemented is a real time critical system, where every malfunction can be viewed as highly critical. These include most of the conditions that are described above in Risk.
Time performance
This is purely a real time system and hence possesses all the qualities needed especially in performance time and response. It has components like sensors, actuators and other equipments that works real-time and perform well consistently.
Functional Requirements
There are mainly three users of the Patient Information Management System. Doctor/Physician, Nurses and the administrative staff [admin staff]. All the users need to login using username & password to use all other functions of the system. Admin staff can perform all the administrative functions like add details for patient/staff, discharge any patient, and edit details. Doctor/Physicians and nurses can look for any particular patient; and record/edit the data like observation chart, Fluid Balance summary, Medication charts, diagnosis for particular patient. They can also look for all the details for any patient like diagnosis, charts and staff members that are connected with the patient.
Tables
Admin Staff, Doctor & Nurse
Login
Username
Password
Admit Patient (Hidden For Doctor& Nurse)
Issue MRN
Admission Date
Admission Time
Create Patient Data (Hidden For Doctor& Nurse)
Patient name
Last name
Contact no
Address
D.O.B
Age
Sex
Add/Edit Staff (Hidden For Doctor& Nurse)
Add/Edit Staff ID
Add/Edit First Name
Add/Edit Last Name
Add/Edit Department
Add/Edit Contact No
Add/Edit Staff Type
Add/Edit Responsibilities
View/Search Patient Data
By MRN
By Name
Edit Patient Data (Hidden For Doctor& Nurse)
Patient name
Last name
Contact no
Address
D.O.B
Age
Sex
Discharge Patient (Hidden For Nurse)
Fill-up Discharge Form
Discharge Date and Time
Logout
Doctor/Physician & Nurse
Login
Username
Password
View Medication Data
View once-only
View Recurring
Add/Edit Medication Data(Hidden for Nurse)
Add Once-only
Edit Once-only
Edit Recurring
Add Reccuring
Clinical Notes(Hidden for Nurse)
Add Clinical Notes
View Clinical Notes
Edit Clinical Notes
Diagnosis(Hidden for Nurse)
Add Diagnosis
View Diagnosis
Edit Diagnosis
View as Graph
View as Chart
View All
View Vital Info
View Temperature
View Pressure
View Pulse
View Staff Info
Listed by Departments
Listed by Types
Logout
Usecase Diagrams
Usecase 1
Usecase 2
Non-Functional Requirements
Accessibility
For the mobility of the system to be effective it must be accessible from all points in the hospital. This will mean having a big enough antenna or multiple antennas on the wireless access point(s) to ensure that doctors, nurses and other medical staff can access the system at all times. There should also be no interference between the PDAs and external signals in either direction: i.e. PDAs should not interfere with the readings of medical equipment and any other nearby technology and visa versa.
Privacy
Since the system will be storing the full medical history, symptoms and vital signs of patients it is critically important that their data be kept as private as possible. This means that personal data transmitted over the wireless network must not be intercepted or hijacked by malicious users within the hospital or surrounding the hospital (since the wireless signal may extend slightly beyond the hospital walls).
Security
The system must have a high level of security and only allow authorised access to the system.
Availability
Because the full medical history, admission details and all vital signs of the patients will be stored on the system, it is critically important that the system be available constantly and have systems in place to handle unforseen events such as power failures, server downtime or crashes and other events. Additionally, the system must be accessible at all times so that doctors always have the required information available to them, there cannot be times where the doctor cannot rely on their PDA, or a fast replacement.
Reliability
There must be a high level of data integrity, all the information in the system must be trustworthy by doctors and nurses at all times, or patient's lives will be at risk.
Usability
The size of a PDA means that the methods of input are limited to a stylus and an on-screen keyboard, this means that entering large amounts of data is too time consuming for doctors and nurses. The system must require the user to only ever enter small amounts of data in order to fully operate the system.
Additionally the system must be able to be operated with minimal training.
Economical
The software must be able to run on the lowest common denominator PDAs so that the individual unit cost of the devices is minimal. The software must work on standard hardware and standard software and not require large processors or memory to operate.
Supportability
The PDA hardware and software chosen must be easy to develop for to make the creation of the software and its future maintenance as easy as possible for the developers.
Additionally The client software for the PDA must be easy to install on standard PDA hardware and software.
Conceptual Architecture
The system can be accessed in two seperate ways; there is a PC interface and a PDA interface. Both interfaces connect and communicate using the same structured data, they communicate with the Smart Hospital Server.
The server is connected to several persistent storage components. The Staff Data component stores the staff directory, the Patient Data component stores patient personal details, admission information and all other patient related data and the Frequently update data component stores all patient vital information.
The Smart Hospital Server has two external interfaces. One is a HTTP connection which provides a connection with the Internet including medical databases for the doctor to access. The data is requested from the Smart Hospital server via the PDA or the PC and the server then uses the external HTTP interface to retrieve the requested data.
The second external interface is a connection to sensors and actuators which provide patient vital information to the Smart Hospital Server. This vital information is real-time and is stored in the frequently updated persistent storage data component to be accessed indirectly through the server on the doctor's request.
Use case maps for events
The figure below shows 3 major user events:
1) View/edit Vital patient data ( frequently monitored data);
- The doctor uses the PDA to request the patient's vital data
- The PDA sends a request to the Smart Hospital server for the vital data
- The Smart Server retrives the requested data from the frequently updated data persistent storage
- The Smart Server structures the data and returns it to the PDA
- The PDA formats the data for the screen and displays it to the doctor
Please note: Although it is not specifically part of this use case, this use case is dependant on the server constantly updating the frequently updated data persistent storage from the external sensor interface.
As the system development progresses it might become more practical to directly relay the vital data from the sensor interface through the server directly to the PDA, this will be decided after further testing.
2) Write clinical notes about a patient/ view admission data or any general information about patient
- The doctor uses the PDA to write clinical notes or request information about a patient
- The PDA sends a request to the Smart Server to retrieve/write the data
- The Smart Server retrieves from or updates the persistent patient information as applicable
- The Smart Server returns the structured data or status report to the PDA
- The PDA displays the requested patient data or confirms the writing of data as appropriate
3) View/update staff data.
This is the same as the previous use case except with staff data
The figure below shows other 3 general events like
1) Viewing medical information
2) HTTP connectivity for finding details about medication and various other purposes
3) Viewing/updating staff data from PC client.
Data Models
The following diagrams show in detail the nature of data passes between components and various responsibilities of the components. Smart Hosptial server which is the key componnent in this system interacts with both persistant data objects as well was other user interface components.
Frequently updated data consists of observation data with different categories as well as fluid summary of the patients. In the figure below a total aggregation is shown for the class category with class observation, which also has an association with class fluid summary.
Data model showing associations between smart server and patient data classes Here the patient (data)class contains diagnosis, admission and discharge which are associated.An aggregation is shown between SmartHosptial class and Patient class as it has patient data as its component.
Execution Architecture
The Conceptual Architecture explained the domain level functions and responsibilities of the system. In this section we are discussing the run time structure of the Smart hospital system. The Execution Architechture basically centers around testing the non functional requirements (quality) of the system. It describes about the system execution structure and how the activities are generated by the components in the system. It also explains the communication between the components.
The smart hospital system is a complex system (which can be broken down in to smaller subsystems that combines to form the system as a whole). So with the hint of the subsystems within the system and understanding that they are concurrent we use the concurrent subsystem to express our choice. Now in the following sections we discuss about the various subsytems (concurrent), the processes within the subsystems that have the high degree of internal concurrency, the various concurrently accessible objects, the dynamic concurrencies in the system, the runtime behaviour of the system and a basic deployment model corresponding to the proposed system.
Concurrent Subsystems
The above diagram explains a particular scenario in the system where the PDA client (user) requests certain information about the patient from the PATIENT DATA (active) component synchronously. This particular component then interacts with the Database server (service), retrieves the information that was requested and relays it to the PDA client. The PC client can also retrieves the information in the above depicted approach.
In this scenario the PC client (user) requests an asynchronous call back from the FREQUENTLY MONITORED DATA (active) component about the vital readings from the sensor. This is basically an active component which keeps track of the latest sensor readings with the help of the SMART HOSPITAL SERVER (service) which has an interface with the sensors. Similarly the PDA client can also retrieve the above mentioned information.
Concurrent Objects
The above diagram explains how the PDA client and the PC client are accessing the services that are concurrent like the ENTER PATIENT INFO, VIEW PATIENT INFO, WRITE CLINICAL NOTES and LOOK UP MEDICAL INFO and many more.Due to space constraints we restrict ourselves with the above 4 Objects.
Dynamic Concurrency
We have already discussed about the concurrent subsystems in which the components come into view and vanish during execution time. Now we take into the account the dynamic concurrencies within the system, the server in the smart hospital system has to handle multiple requests which may be numerous at some point. So, this section describes how the system caters to the user expectations.
In case of multiple requests from the PDA or the PC client (Parent) a passive component prioritizes the requests and passes it on to the Creation Port (circle) of the Look Medical Info (Acceptor), which holds the server socket to connect to the HTTP INTERFACE and when a connection is received, the Acceptor starts processing the simultaneous requests until termination(Cross), while the response to the requests is forwarded to the Database Server (Handler) and then it connects to the passive component that prioritized the request from the PDA and the PC clients which forwards the results to the righteous client.
Runtime Behavior
This section clearly shows the Runtime behavior of all the above discussed executions and the execution architecture as a whole. Now you can clearly discriminate between the behavior of the conceptual architecture which just contained the components and the executable architecture which deals with the components along with their related objects.
Concurrent Subsystems:
Dynamic Concurrencies:
Deployment Model
Implementation Architecture
Initial Implementation Architecture
Components:
Application components:
A source code package that have domain level responsibilities of the system described in Conceptual level architecture. Here the coding will be done in C # using name space.
Subsystem:
1)A database subsystem is added to the architecture which is an off-the-shelf MySQL database.
2)A web service subsystem which has IIS server, .net frameworks, GUI templates and SmartHos namespace.
Containers:
ASP.net framework for PC client, OpenNetCF for PDA, InterSystems Cache for Database
Key types of technologies
Wi-fi Access Point – Use modern wireless technology to allow the PDA devices to operate anywhere in the hospital.
.Net Framework – This will allow a use of a common framework for all elements of the system including the PC Client, PDA Client, Web Services and sensor data. More compatibility means more code reuse and faster development.
IIS – Internet Information Service is Microsoft’s web server and will be used because of its integration within the .NET framework.
VB.NET – VB.NET was chosen because of its integration within the .NET framework and its suitability for creating Web Services. Additionally this allows the same language to be used to develop the PC client and the PDA client.
GUI Templates – Templates will be used to avoid repetition in producing the Web and PDA interfaces, by using templates, display components of the system can be reused.
InterSystems Cache – An OO relational database used to store all the patient data, sensor data and staff directory. This database is already used in hospitals so is well suited for the purpose.
OpenNetCF – This technology will be used to provide a simple GUI interface on the PDA.
Mica 2 MTS 300/310 – This sensor was chosen because it is wireless and can exploit the use of the existing Wi-fi access point to transmit data back to the Smart Hospital server.
Architectural Decisions
The decisions made on each architecture views were mainly based on the requirements given in the context for Smart hospital system.
In conceptual view, we have tried to include the essential components of the required system consisting of PC & PDA client, a centralized server system having a database and interfaces to various sensors that could be attached. We have not shown the Sensor as a component taking into consideration that any sensor could be attached to the provided interface. We have shown two kinds of persistent data, Patient data and frequently monitored data which include all the necessary information that have to be tracked by the system.
In Execution Architecture, we have clearly maintained our conceptual view of the architecture, since we felt that this was a complex system and basically through analysis of the requirements we came to a conclusion on implementing the Concurrent Subsystem View to our architecture. This idea mainly centered on the main subsystems that formed up the SHS (Smart Hospital System). We also made it a point to refer to the concurrent objects within the system. Were as our choice of Dynamic Concurrency which basically affects the Performance, Scalability and Responsiveness of the system can be considered as a delicate one that caters the user requirements.
In Implementation architecture, the components are included according to user specifications. We have included InterSystem Cache; a database subsystem for implementing centralized database, IIS server for loading the SmartHos web service, GUI templates for structured GUI s ( for PDA & PC ) , .net frameworks for both PC and PDA client environments and Mica 2 Sensor. This is a rough draft of the architecture based on the client requirement and will be enhanced later for real implementation.
References
1)Reekie and McAdam, A Software Architecture Primer,Angophora Press, Mar 2006.
2)Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, Addison-Wesley Longman Inc, April 2000.
3)Leture slides on Software Architecture and Middle ware by Dr.Zenon Chaczko,Dr John Reekie, Spring 2006
4)AngoPhoraPress, "Softwarepractices" July 2006[Online].Available: http://www.softwarepractice.org/wiki/Initial_architectural_design [Accessed Sept 15, 2006].
5)GROUP BLUE, [Online]. http://www.softwarepractice.org/wiki/Group_Blue [Accessed Sept 16,2006].
6)GROUP RED, [Online]. http://www.softwarepractice.org/wiki/Group_Red [Accessed Sept 17,2006].
