Group Blue

From SoftwarePractice.org

THIS TOP SECTION IS TO BE DELETED:

        Purpose  (Harpreet) 

        Objectives (Harpreet)

        Scope (Harpreet)

        Definitions, Acronyms, Abbreviations (Harpreet)

        Standards (Harpreet)
   

       Use Cases (Harpreet)

       Components and their responsibilities (Ling)

       Data Model (Ling)

       Runtime and life cycle Events (Harpreet)

       Behaviour (Ling) (Harpreet) (Enrique)

                Use case Maps (Ling) (Harpreet) (Enrique)

       Conceptual view of architecture (Ling)
    
       Architecture style (Enrique)

       Process view (Enrique)

       Concurrency objects(Ling)

       Behavior (Enrique)

            Use-case maps (Enrique)

       Deployment view (Ling)

       Types of technologies & affecting factors  (Enrique)
       
       User Interfaces (Enrique)

References (Harpreet)

Smart Hospital Project: Patient Information Management System Version: 0.1 Initial Software Architecture Design Document Date: 02/09/06

Revision History

Version Author(s) Description of Version Complete Date 1.0 Harpreet. K ¨ Started Initial Software Architecture Design Document, created all sections (Draft) 02/09/06 1.1 Ling Jin ¨ Create Use-case diagram,Components and responsibility,

                               Conceptual architecture,Use-case maps,Deployment model 	        03/09/06

1.2 Ling Jin ¨ Update Deployment model¨ Write diagrams descriptions 04/09/06 1.3 Harpreet. K ¨ Updated the wiki page. Created and Upload all Use-case diagrams,

                               Use-case maps (staff) with description                          06/09/06

1.4 Harpreet. K ¨ Create all Use-case diagrams , Use-case maps (staff, diagnosis,

                               medication, observation ect) and updated admission discharge 
                               use cases, (Draft)	                                        16/09/06

1.5 Harpreet. K ¨ created & uploaded Use-case maps (Diagnosis & Clinical Notes)

                               with description, did formatting and added Life cycle and 
                               runtime events, NFR                           	                17/09/06

1.6 Ling Jin ¨ Create Concurrency Objects, Adjust Deployment model, add

                               description for them	                                        18/09/06

1.7 Enrique T. ¨ Create conceptual use-case maps for medication¨ Create process

                               view create execution use-case maps,Write implementation view¨	
                               Write Justification	                                        18/09/06

1.8 Harpreet. K ¨ Updated the Concurrency Objects, Did formatting on Wiki,

                               Added Use case for diagnosis	                                18/09/06

1.9 Ling Jin ¨ Adjust concurrency objects¨ Add performance concerns for

                               execution Do final check and correct some faults¨Format 
                               the document                                             	19/09/06

1.10 Ling Jin, Enrique Edited use case maps 19/09/06 1.11 Enrique ¨ Edited Process Diagrams 19/09/06 1.12 Harpreet ¨ Wrote text for all use case maps with behavior steps,

                               rectified the minor mistake in diagrams, and formatted  
                               the whole document. 	                                        19/09/06

The Cover Letter

The Software Architecture and Middleware Group Blue

University of Technology, Sydney

PO Box 123, Broadway

NSW 2007

Australia

                                                  Sydney, 19/09/2006

Mr. Zenon Chaczko Chief Executive Officer 49266 Software Architecture and Middleware Corporation University of Technology, Sydney PO Box 123, Broadway NSW 2007 Australia

Dear Mr. Chaczko:

The Software Architecture and Middleware Group Blue, Group Blue, has, according to your specifications developed an initial architectural design, in regards to the Smart Hospital Project: Patient Information Management System. Group Blue will provide you with a report and presentation on the project.

The initial architectural design defines a concrete artifact that contains the initial assessment and design of the architecture. It captures the architectural context, and includes a reasonably well-developed architecture in conceptual, execution and implementation views.

The report will be delivered to you no later than 19 September, 6.00 PM. Our consultants prefer to attend and present the project on your conference on 7 November.

If any questions or dissatisfaction occurs in regards to the developing work undertaken by Group Blue for your company, please do not hesitate to contact Group Blue. We will ensure that every aspect of the project and its deliverables will meet your needs and expectations.

Sincerely,

Ling Jin Group Blue representative

Abstract

As the rapid development of the computer technology, a more convenient environment for the design of personal information system can be easily achieved. Several personalised applications have been widely deployed in a lot of categories. In this document, we introduce the design of a system named as smart hospital for use in the hospital by using emerging mobile and computer technologies. In addition to making the retrieving of clinical information fast and practical, the proposed system has many benefits such as shortening the time used to read chart, decreasing the number of mistakes of paper work and improving the hospital management so that the health-care quality can be guaranteed. The proposed system, which consists of several communication interface components, uses a modular design. And in order to overcome the synchronisation issue among these components, the SyncML mechanism has been adopted to guarantee consistency of the data and content. The consistency shall also be achieved between the mobile devices and the hospital information system.

Project Overview

The system to be developed revolves around the needs to gather information within a particular hospital environment and to make it available easily anywhere. This system is aimed to the hospital industry.

The project supports the day-by-day activities of doctors and nurses within a hospital ward by providing approaches for workgroup collaboration and wireless access to the patient’s clinical records for St. George Hospital (Kogarah, NSW, Australia). The project, which is at present experiencing its first prototype, is based on accessing the information system from the patients’ bedsides, with a wireless connection through PDA clients.

Potential users of Health Information Systems include General Practioners, Pharmacists, Hospital Staff and Nurses. Ideally an infrastructure for such a system will support the integration of data and processing as well as a diverse range of user interface technologies and devices. We describe a system that uses a range of current object-oriented technologies to achieve these. We present architecture views for this system, key parts of its object-oriented design, examples of some of its user interfaces, and report on our experiences of building and evaluating this system. We identify strengths and weaknesses with these technologies that will be useful for others considering adding a range of web- and mobile-interfaces to enterprise systems.

Purpose

The purpose of the system is to envisage a system that allows all health professionals at a hospital to share their information in a timely manner, integrated via a central "brokering" health system. This has the key advantages of permitting different professionals to access an integrated, consistent history of patient information and to be aware of a patient's complete medical history.

Currently entering of data regarding the diagnosis of patients is done manually. This results in an large amount of manual work. Bedside information recorded on parchments is prone to being misplaced.

Various other issues are likely when information is being manually recorded including (but not limited to):

· Information recorded manually is prone to getting misinterpreted.

· Processing of manual information into electronic means introduces time lag and increases the chance of error.

· Clinical Reports and diagnosis/clinical data is stored separately either through manual or electronic means.

· Recording of patient diagnosis and observations takes a substantial amount of time.

Objectives

The main Objective of the system is to allow physicians and other staff to manage patients’ admissions by using PDAs or Mobiles (personal digital assistant). The information will then be synchronized with a server through wireless means, which enables information to be accessed by any physicians using PDAs. In general, the system will allow the physician to perform the following tasks:

· Entry/viewing of patient information using a PDA.

· Viewing data regarding a patient’s admission

· Writing clinical notes

· Viewing of medical info i.e. information on medication/illnesses/symptoms.

· May allow access to Internet based information databases.

The project plan supports the following objectives. (Project management Objectives)

· Details of the scheduling required in managing project.

· Details of managing risks and assets in the project.

· Details of the planning and control ensuring the effective operation of the process.

· Determines and manage the work environment needed to achieve conformity to development plans.

· Determines development strategy.

· Defines the sources of the information used to prepare the plan.

Scope

This section shall aim to set a generalized boundary on the functionality and internal and external interface of the system. As such, the core functionality of the system shall revolve around being able to:

· Allow safely recording of inpatient information

· Synchronization with the central database

· Help with planning

· Allow use of sensors to detect vitals

The main hardware interfaces the system shall deal with shall include:

· Database server

· PDA/Mobile

· PC

· Wireless Link (using 802.11b protocol)

· Sensor interface.

The main users of this system shall include:

· Physicians

· Nurses

. Other Medical personnel

Definitions, Acronyms, Abbreviations

PDA – personal digital assistant

PC- Personal Computer

SHS - Smart Hospital System

NFR - Non Functional Requirements

FR - Functional Requirements

Standards

We have not used any specific standard for this document.

Stakeholder and their perspectives

Stakeholder needs are divided in two parts as usage narratives and system narratives according to the personas and scenarios approaches. All the personas under usage narratives are the people who are directly using the system, and the personas under system narratives are the persons who are not directly using the system but somehow interested in the system.

Usage Narrative

                  Personas	                        Scenario

               Ø  General Practitioner and Doctor      Needs
                                                            · To View Patient’s Information like Vitals 
                                                              Medications, Charts etc.
                                                            · To View, add and update patients diagnosis and   
                                                              notes.  
                                                            · To Enter Data like Notes, chart and Vitals etc.	
                                                            · To View, add & Update Procedures·	
                                                            · To View Staff Information·	
                                                            · Fast Processing	
                                                            · Mobility	
                                                            · Friendliness	
                                                            · Availability

               Ø  Nurse	                        Needs
                                                            ·	To View Patient’s Information like Vitals
                                                               Medications, Charts, diagnosis, notes etc. 
                                                            ·	To Enter Data like  chart and Vitals etc.
                                                            ·	To View Staff Information
                                                            ·	Fast Processing
                                                            ·	Mobility
                                                            ·	Friendliness
                                                            ·	Availability

              Ø  Patient	                        Needs
                                                            ·	To get Admitted 
                                                            ·	To get Discharged
                                                            ·	To Request Information
                                                            ·	Privacy/Security
                                                            ·	Safety
                                                            ·	Quality Service

              Ø  Administrative staff	                Needs
                                                            ·	To enter or update Admission details of patients
                                                            ·	To enter or update Discharge details of patients
                                                            ·	To View staff Information  
                                                            ·	To add and Manage staff information
                                                            ·	Fast Processing
                                                            ·	Fast Data entry
                                                            ·	Friendliness
                                                            ·	Availability

System Narrative

                 Personas	                        Scenario

              Ø  Software development team	        Needs
                                                            ·	Testability
                                                            ·	Maintainability
                                                            ·	Scalability
                                                            ·	Configurability
                                                            ·	Reusability
                                                            ·	Importing Legacy Data
                                                            ·	Standardized D/B
                                                            ·	Programming Tools
                                                            ·	Extensibility

              Ø  Other suppliers                     	Need
                                                            ·	Communication

              Ø  QA team	                        Needs
                                                            ·	Testability
                                                            ·	Auditability
                                                            ·	Compliance
                                                            ·	Verifiability
                                                            ·	Predictability

              Ø  Top level management & directors	Need
                                                            ·	Feasibility
                                                            ·	Quality System
                                                            ·	Financial Returns
                                                            ·	Scalability
                                                            ·	Security
                                                            ·	Reliability 

              Ø  Project Manager	                Needs
                                                            ·	To Communication with project team
                                                            ·	Cost estimation
                                                            ·	Schedule estimation
                                                            ·	Risk analysis

              Ø  Maintenance People 	               Needs
                                                            ·	Maintainability
                                                            ·	Configurability

              Ø  Designers                             Need
                                                            · Analysability 
                                                            · Modifiability
                                                            · Flexibility
                                                            · Reusability

              Ø  Testers	                        Need
                                                            ·	Testability
                                                            ·	Auditability
                                                            ·	Compliance
                                                            ·	Verifiability
                                                            ·	Predictability

Contextual Factors

Opportunities

The following opportunities have been identified that the new system will provide to the hospital.

• Improved efficiency By using a completely computerised data entry and retrieval system staff will waste less time with the existing paper based methods. This is mostly achieved from removing the need for double data entry and allowing any authorised staff to instantly access the required data.

• Saving doctors’ and other staff’s time Time currently spent retrieving patient information is reduced by using this system. Instant access to all authorised medical data is available from any locations. It even saves time of staff going to their PCs.

• Reduce errors and mistakes By removing the current process of transferring paper-based data to computers, the opportunity to introduce errors is eliminated.

• Reduce operating costs By saving time and improving efficiency operating costs can be reduced.

• Improve accuracy of information Diagnosis data such as temperatures can be entered automatically, greatly improving accuracy. Also the availability of all the data in one central repository allows for errors such as faulty sensors to be identified, e.g. by looking for “idle” temperature sensor data that’s vastly different to other idle sensors. (Idle here refers to a sensor that isn’t attached to a patient and is reading room temperature data).

• Securely transferring data from PDA to server and vice versa. The opportunity to introduce security at the architectural level means it doesn’t need to be retro fitted at a later stage, and allows for all equipment to support the required standards. In this case the WPA2 protocol will encrypt wireless data and restrict access to the wireless network, and all PDAs and wireless access points will support it. Because this is a strong and comprehensive security protocol it eliminates the need for redundant security layers to be introduced (such as SSL over HTTP).

• Comply with government & industry regulations Data security and privacy regulations can be addressed by using this system. It forces all users to adopt these regulations instead of relying on staff to follow correct procedures.

• Information can be accessed from anywhere – increases mobility The opportunity to access data from anywhere within the hospital and increase mobility is provided by this system and has a flow on of other benefits (such as increased efficiency).

• Scalability – can grow with the size of the hospital By adopting the architecture presented here scalability can be achieved to allow the system to cope with larger hospitals, and larger number of patients and staff. This is most important in allowing for the system to be sold to other hospitals which may vary greatly in sizes.

• Reuse – can be sold to other hospitals By keeping functions modular and scalable the system can be reused and sold to other hospitals.

• Reduces waiting time for patients By reducing the time patients waiting for diagnosis, information, and admission etc, the hospital would provide greater services to patients.

• Extensibility By keeping the functions modular the system can be extended with new functions as the need arises. This is by design and has been incorporated into the architecture.

• Availability The availability of data can be increased by using this system over the existing paper based system. Data is more readily available to those who need it without having to go through additional administrative staff.

Constraints

• PDA screen size is limited. Because PDAs have a small screen size certain functions are not available to them (such as admitting patients) and a lot of consideration needs to be taken into designing the user interface and forms presented on them.

• PDA graphics – Graphics should be small and simple because the PDAs have a small and low res screen. Graphics (such as graphs) need to be simplified.

• PDA battery The PDAs used here have battery life issues that may not last a full day’s use, depending on usage. This needs to be addressed in the architecture, by using as little network traffic as possible, and being able to maintain state in the event of battery failure.

• PDA input – No keyboard is available so that efficient means to enter data are required. Functions that require a number of data entries are best suited to the PC clients, and the PDAs will mostly be used to make quick entries and to retrieve data.

• Legacy system (paper) The hospital has a large amount of data currently on paper which needs to be added to the system.

• Privacy policies It is very important that privacy policies be addressed by the system. This will be handled by security functions restricting data to staff authorised to access it.

• Training to the staff to use new system Any new system such as this one will require training of staff. The cost and time involved in performing this needs to be taken into account, especially with budgeting and inducting new staff.

• Wireless (limited coverage) While the use of a wireless network provides great mobility within the hospital it has boundaries. By design these boundaries will be at the perimeter of the hospital building.

Enablers

· Wireless – allows mobility

· Software framework (.Net 1.1 and .Net CE)

· User of standards such as IEEE 802.11b

· Development tools - .Net, web services, existing database engine

· TCP/IP

Risks

· Legal liability

· Poor performance

· Potential security issues

· If the system isn’t user friendly or is complicated it can take longer to do things

· Bad Effect of Wifi intervention with medical instruments on patient’s health

· System crash

· PDA crash or malfunction

· PDA stolen

· Server crash

Criticality

- System is highly critical, so that a little failure or break down can cause the human loss.

Time Performance

-The System should be real-time. All authorized users can access the real-time information through either PC clients or PDA clients.

Functional Requirements

Requirements Capture

§ Login – username, password, address & name of client device

§ Authenticate the user.

§ Select a patient – drop down menu

       -	Search by name, ward, or bed number
 

§ View patient information

       -	Admission details

       -	Diagnosis

       -	Observation chart

       -	Fluid balance summary, e.g. blood transfusion

       -	Medication chart – once only – add new, view, update

       -	Medication chart – recurring – add new, view, update

       -	View Medical record

       -	View medical staff associated with patient

§ Get temperature from sensor

§ Record vital statistics

       -	Temperature

       -	Blood pressure

       -	Pulse

       -	Respiration

§ Admission (on PC Client only)

       -	Create new admission record

       -	Record patient’s demographic information

       -	Search if exists in database

       -	Edit admission details

       -	Link medical record to admission record, or create new if necessary

§ Clinical notes & Diagnosis

       -	Add

       -	Edit

       -	View

§ Medication charts

       -	View as table

       -	View as graph

       -	Shows all diagnostics at once

       -	Record value, manually

       -	Update value

§ Recurring Medication

       -	View list of medications

       -	Create new schedule

       -	Edit schedule

       -	Record date/time when given

       -	View history

       -	View all patients using a particular medication

§ Patient Discharge

       -	Fill out discharge form and update in the system (from PC client only)

       -	View list of all discharged patients (first name, last name)

       - 	View details of a discharged patient

§ Staff Information

       -	Return a list of staff (name & phone number)

       -	Sort by department

       -	Sort by type

       -	Create new

       -	Edit

       -	View “admission responsibilities” (patients that are being looked at by staff member)

Use-Cases Diagrams

Use cases describe the functionality of the system from the user’s point of view. The user may be administration staff, doctors or nurses. Each use case is a different way to use the system and the completion of each use case produces a different result. The Figure 1 describes functions related to daily administrative work, while the Figure 2 illustrates functions involved in the medical processes.

1.

Figure 1: Use Case Diagram (a)

2.

Figure 2: Use Case Diagram (b)

Non-Functional requirements

Non-Functional requirements or Quality attributes are not the operational functionality of the system but somehow they improves the real functionality in a way to make them more useful and specify criteria that can be used to judge the operation of a system, rather than specific behaviours.

We have divided these requirements into two types:

Runtime

1. Performance

         o	Response time between PDA and server should be less the 10 seconds

         o 	Response time between PC and server should be less the 5 seconds

         o	Response time between PDA and censor should be less the 5 seconds

2. Usability

         o	System should be highly user friendly like simple to navigate and input data.

         o	User guides and manuals should be provided to help the user for installing and using the system 

effectively.

3. Reliability

         o	Accuracy

              -	As the system is highly critical accuracy is necessity. Interface should be designed in that way that the chances of error while data entry get decreased.

              -	Data from Censor should be very accurate.

              -	level of data integrity should be high enough.

         o	Availability
           
              -        System should be available 7 days and 24 hours.

         o	Safety

              -        Safety measures should be included in the system to protect from the bad Effect of Wifi intervention with medical instruments on patient’s health 

         o	Reliance

              -        System should be reliance in a way that it should keep working when not all but some of resources are available. For example, the hospital has 20 sensors but only 2 even 1 sensor is working at a particular time, while the system should work as normal.      

4. Security

  	       -        Needs authentication (User name and password)
              
              -        Assign necessary privileges to every user depending on the usage. 
              
              -        WAP2 will be used for the protection on wireless communication	

5. Concurrency

              -        Concurrency is very important in the system as if two users trying to updated the same piece of information or one is updating and others are viewing then there is a great need of concurrency at that time. 

Non-Runtime

1. Maintainability

              -        system should have continuous maintenance sessions.

2. Testability

              -        System should be tested on different levels of testing during, before or after implementation and final deployment.

3. Reusability

              -        System should have well design software components for future use and these components should be fully documented as well. 

4. Scalability

              -        System should be highly scalable as the hospital can grow or expand later in future so it should be able to handle the heavy workload.

Conceptual Architecture

Components and their responsibilities

The following Table 1 shows components and their related responsibilities involved in the Smart Hospital System.

Components Responsibilities

PC UI

       ?       Present information to users via PC clients
       ?       Get input data from users via PC clients

PDA UI

       	Present information to users via PDAs
       	Get input data from users via PDAs

Web Services

       ? Network communication
       ? Multi-treads process

Admission/Discharge

       	Admit patients
       	Edit admission details
       	View/search admission information
        	Discharge patients

Diagnosis

       	Conduct diagnosis
       	Edit/view diagnosis
       	Remark diagnosis

Procedures

       	Search procedures
       	View procedures
       	Edit procedures

Staff Directory

       	Add/edit staff details
       	View/search staff information

Sensor

       	Get patients’ body temperatures
       	Send temperatures to PDAs

Database

       	Store all persistent information

Table 1: Components and Responsibilities

Data Model

Figure 3: Data Model

The Figure 3 illustrates the data model for the problem domain to clarify information travelling along connectors and through interfaces, as well as to describe persistent data.

11 classes are involved in this system: Admission details, Medical records, Once chart, Observation chart, only medication chart, Observation chart, Fluid balance summary, Recurring medication from, diagnosis, Discharge, Staff info, Staff responsibility and Medical process. Each of classes has their attributes but only key attributes are shown in this diagram. There are also relationships carrying multiplicity between these classes and components as shown in this diagram.

A Patient may have one and only one Medical Record that is generated when the patient is admitted and is closed when discharged, may have many Admissions that are assigned Medical Record Numbers (MRN) and have one or none Discharge. Under an MRN, a Patient may have many Observation Charts, Once Only Medication Charts, Recurring Medication Charts, Fluid Balance Summary and Diagnosis which are created to keep the relative information. A Staff has one and only one Staff Info identified as StaffID, and may have many Responsibilities. Staff Info and Responsibility will be reflected in Once only medication charts, Recurring medication charts and Diagnosis. Logged in Staffs can browse the Medical Procedures.

Runtime and life cycle Events

Runtime events:

       -  Concurrency
       -  Alive/Ping scheme : There should be a mechanism for every device to ping and to let system know that it is available and working.
       -  Time stamping on transactions
       -  Integrity
       -  Execution flow
       -  Data flow
       -  Disconnection : If some the sensors are not working or disconnected and if at least one sensor is in working condition then the system should work as all are working. So there should not inconvenience.               

Lifecycle Events:

       -   Admitting and demographic information recording
       -   Making File
       -   Making Clinical Notes
       -   Medication Charts and Test Results
       -   Discharge

Behaviour

A range of use case maps are created for events arising from the system usage on the initial conceptual architecture. They illustrate system behaviours from the conceptual architecture view that focuses on domain-level functionalities.

Admission/Discharge

Figure 4 : Admission / Discharge Use Case Maps

As shown in the Figure 4 above, the use case maps carry on the events associating with Admission and Discharge functionalities: Admit Patient, View Admission, Edit Admission, Discharge Patients, View Discharge Info, and Edit Discharge Info, via either PC clients or PDA clients. The path taken by each trace demonstrates the order in which different components participate in the response to each event. Through PC interfaces, users can add (Admit Patient), view and edit admission by querying and updating relative data via Web Services and Admission components. In the same way, PC clients users also can add (Discharge Patient), view and edit discharge information, while users only can view admission and discharge information through PDA clients.

Behaviour steps:

=> Admission: (admit patient, edit admission (can be done from PC only) or view admission) From PC

1. Sending user request form PC.

2. Handling request and network communication and call application process.

3. Calling Function to admit patient, edit admission or view admission and send request to data access layer.

4. Connect to database, Get query from the application, send query to database.

5. Receive Results and send result to Application.

6. Return Functions response.

7. Send response to PC and manage network communication.

8. Display result on PC client’s screen.

9. Sending user request form PC.

Discharge (discharge patient, edit discharge (Can be done by PC only) or view discharge): From PC

10. Handling request and network communication and call application process.

11. Calling Function to discharge patient, edit discharge or view discharge and send request to data access layer.

12. Connect to database, Get query from the application, send query to database.

13. Receive Results and send result to Application.

14. Return Functions response.

15. Send response to PC and manage network communication.

16. Display result on PC client’s screen.

View admission From PDA

17. Sending user request form PDA.

18. Handling request and network communication and call application process.

19. Calling Function to only view admission and send request to data access layer

20. Connect to database, Get query from the application, send query to database.

21. Receive Results and send result to Application.

22. Return Functions response.

23. Send response to PDA and manage network communication.

24. Display result on PDA client’s screen.

View discharge From PDA

25. Sending user request form PDA.

26. Handling request and network communication and call application process.

27. Calling Function to only view discharge and send request to data access layer

28. Connect to database, Get query from the application, send query to database.

29. Receive Results and send result to Application.

30. Return Functions response.

31. Send response to PDA and manage network communication.

32. Display result on PDA client’s screen.

Staff Directory

Figure 5: Staff Use Case Maps

As shown in the Figure 5 above, the use case maps carry on the events associating with staff information: Add / update Staff Info, View Staff Info, View Staff responsibility Info via either PC clients or PDA clients. The path taken by each trace demonstrates the order in which different components participate in the response to each event. Through PC interfaces, users can add (add staff information), view and edit staff information by querying and updating relative data via Web Services and staff directory components while users only can view staff information through PDA clients.

Behaviour steps:

=> Staff: (Add/update (can be done from PC only)) from PC

1. Sending user request form PC.

2. Handling request and network communication and call application process.

3. Calling Function to add/update staff info and send request to data access layer.

4. Connect to database, Get query from the application, send query to database.

5. Receive Results and send result to Application.

6. Return Functions response.

7. Send response to PC and manage network communication.

8. Display result on PC client’s screen.

Staff: view staff info from PC

9. Sending user request form PC.

10. Handling request and network communication and call application process.

11. Calling Function to view staff info and send request to data access layer.

12. Connect to database, Get query from the application, send query to database.

13. Receive Results and send result to Application.

14. Return Functions response.

15. Send response to PC and manage network communication.

16. Display result on PC client’s screen.

Staff Responsibility (View) from PC

17. Sending user request form PC.

18. Handling request and network communication and call application process.

19. Calling Function to view staff responsibility info and send request to data access layer.

20. Connect to database, Get query from the application, send query to database.

21. Receive Results and send result to Application.

22. Return Functions response.

23. Send response to PC and manage network communication.

24. Display result on PC client’s screen.

Staff: view staff info from PDA

25. Sending user request form PDA.

26. Handling request and network communication and call application process.

27. Calling Function to view staff info and send request to data access layer.

28. Connect to database, Get query from the application, send query to database.

29. Receive Results and send result to Application.

30. Return Functions response.

31. Send response to PDA and manage network communication.

32. Display result on PDA client’s screen.

Staff Responsibility (View) from PDA

33. Sending user request form PDA.

34. Handling request and network communication and call application process.

35. Calling Function to view staff responsibility info and send request to data access layer.

36. Connect to database, Get query from the application, send query to database.

37. Receive Results and send result to Application.

38. Return Functions response.

39. Send response to PDA and manage network communication.

40. Display result on PDA client’s screen.

Diagnosis

Figure 6: Diagnosis and clinical notes Use Case Maps

As shown in the Figure 6 above, the use case maps carry on the events associating with Diagnosis and clinical notes: Add / update Diagnosis and clinical notes, View Diagnosis and clinical notes via either PC clients or PDA clients. The path taken by each trace demonstrates the order in which different components participate in the response to each event.

Behaviour steps:

Diagnosis/ Clinical notes: (view) from PC

1. Sending user request form PC.

2. Handling request and network communication and call application process.

3. Calling Function to view diagnosis & clinical notes and send request to data access layer.

4. Connect to database, Get query from the application, send query to database.

5. Receive Results and send result to Application.

6. Return Functions response.

7. Send response to PC and manage network communication.

8. Display result on PC client’s screen.

Diagnosis/ Clinical notes: (Add/update) from PC

9. Sending user request form PC.

10. Handling request and network communication and call application process.

11. Calling Function to Add/update diagnosis & clinical notes and send request to data access layer.

12. Connect to database, Get query from the application, send query to database.

13. Receive Results and send result to Application.

14. Return Functions response.

15. Send response to PC and manage network communication.

16. Display result on PC client’s screen.

Diagnosis/ Clinical notes: (view) from PDA

17. Sending user request form PDA.

18. Handling request and network communication and call application process.

19. Calling Function to view diagnosis & clinical notes and send request to data access layer.

20. Connect to database, Get query from the application, send query to database.

21. Receive Results and send result to Application.

22. Return Functions response.

23. Send response to PDA and manage network communication.

24. Display result on PDA client’s screen.

Diagnosis/ Clinical notes: (Add/update) from PDA

25. Sending user request form PDA.

26. Handling request and network communication and call application process.

27. Calling Function to Add/update diagnosis & clinical notes and send request to data access layer.

28. Connect to database, Get query from the application, send query to database.

29. Receive Results and send result to Application.

30. Return Functions response.

31. Send response to PDA and manage network communication.

32. Display result on PDA client’s screen.

Medication

Figure 7: Medication Use Case Maps

Figure 7 above shows events when viewing and entering medication data. The PC can enter Once Only and Repeating medication schedules, as well as viewing a medication schedule. The schedule shows all medications for a patient (both once only and repeating). The PDA can only view the medication schedule. Observation charts are also visible by accessing the medication component.

Behaviour steps:

(Enter/update/view Observation chart from PC)

1. Sending user request form PC.

2. Handling request and network communication and call application process.

3. Calling Function to view Enter/update/view Observation chart and send request to data access layer.

4. Connect to database, Get query from the application, send query to database.

5. Receive Results and send result to Application.

6. Return Functions response.

7. Send response to PC and manage network communication.

8. Display result on PC client’s screen.

(View Medication chart from PC)

9. Sending user request form PC.

10. Handling request and network communication and call application process.

11. Calling Function to view Medication chart and send request to data access layer.

12. Connect to database, Get query from the application, send query to database.

13. Receive Results and send result to Application.

14. Return Functions response.

15. Send response to PC and manage network communication.

16. Display result on PC client’s screen.

(Enter once only Medication chart from PC)

17. Sending user request form PC.

18. Handling request and network communication and call application process.

19. Calling Function to enter once only Medication chart and send request to data access layer.

20. Connect to database, Get query from the application, send query to database.

21. Receive Results and send result to Application.

22. Return Functions response.

23. Send response to PC and manage network communication.

24. Display result on PC client’s screen.

(Enter/Update Recurring Medication chart from PC)

25. Sending user request form PC.

26. Handling request and network communication and call application process.

27. Calling Function to enter/update Recurring Medication chart and send request to data access layer.

28. Connect to database, Get query from the application, send query to database.

29. Receive Results and send result to Application.

30. Return Functions response.

31. Send response to PC and manage network communication.

32. Display result on PC client’s screen.

(View Medication chart from PDA)

33. Sending user request form PDA.

34. Handling request and network communication and call application process.

35. Calling Function to view Medication chart and send request to data access layer.

36. Connect to database, Get query from the application, send query to database.

37. Receive Results and send result to Application.

38. Return Functions response.

39. Send response to PDA and manage network communication.

40. Display result on PDA client’s screen.

(View Observation chart from PDA)

41. Sending user request form PDA.

42. Handling request and network communication and call application process.

43. Calling Function to view Observation chart and send request to data access layer.

44. Connect to database, Get query from the application, send query to database.

45. Receive Results and send result to Application.

46. Return Functions response.

47. Send response to PDA and manage network communication.

48. Display result on PDA client’s screen.

Conceptual view of Architecture

Figure 8: Initial Conceptual View of Architecture

The figure 8 above illustrates an initial conceptual view of architecture including 9 components with their stereotypes and connectors. Users interact with the system through two kinds of presentations, PC GUI or PDA GUI. The Web Services, which are seen as a middleware, provide business functionalities and information to Admission/Discharge, Diagnosis, Procedures and Staff Directory applications which access the Database. A realtime component, Sensor, communicates with the system and sends patients body temperatures. The connectors in the diagram indicate exchanging information between components. This conceptual architecture also implies a 3-Tier architectural style of this system.

Architecture style

Figure 9: Architecture Style

The style of architecture used in this system, as shown in the Figure 9, is an N-tier model, separating the user interfaces, the application logic, the data access layer and the persistence layer.

The presentation tier consists of rich Windows applications – both a PC version and a separate PDA version running on PocketPC. These communicate with the second tier via a web service, therefore requiring very little work developing a communications protocol and utilising a common protocol which allows for large scalability.

The second tier, the application logic, is run off a web service. This provides a common network protocol (SOAP over HTTP) and allows for scalability features such as web farming, thread pooling and process control, and for a distributed middleware layer. This takes advantage of features in Microsoft’s IIS server. The application logic performs all necessary functions such as controlling security (granting permission to data, user logins, auditing, and all of the data functions shown throughout this architecture.

The third tier, the data access tier, is separated between the application layer and from the persistence layer. It contains implementations of the entity objects along with various supporting objects. These objects contain codes for shipping data to and from the database.

The persistence tier separates data storage from the rest of the system. This allows for scalability and increased performance of the data store, and builds on a strong database server as a foundation.

Execution Architecture

The execution structure of the system is shown below. Concurrency information and a process view is provided, showing details on how this works. A deployment diagram is also provided showing how the system will be deployed in the hospital.

Concurrency Objects

Figure 9: Concurrency Objects

The Figure 9 shows concurrent objects that are useful to abstract component frameworks. As shown in the diagram, four remote objects, PC client1 and 2 as well as PDA client 1 and 2, are accessing services, including View Admission/Discharge, Update Admission/Discharge, View Diagnosis, Update Diagnosis, View Procedures, Update Procedures, View Staff Directory, and Update Staff Directory, implemented using concurrent objects. A realtime object “Sensor” communicates to both PDA and PC clients. All the services are implemented using a middleware framework that provides a thread pool from which threads are dynamically allocated to service requests to these service objects.

Process view

The first diagram below shows the processes required to implement the system.

The following diagram shows how the system can be scaled, e.g. when there are a large number of clients or sensors.

Execution Use Case Maps

To improve the concurrency performance of the system, client applications using the database may require exclusive access to the data, and in order to gain exclusive access they ask for a lock: a client can not update data in the database when another client holds a lock on the particular data. The data will be unlocked after updated or accessed. The following sessions graphically shows execution behaviours of the system when requesting data to or from the PC clients, the PDA clients and the sensors.

PC

The following diagram shows how data flows through the processes when requesting data to or from the PC.

Behaviour steps:

1. Button event triggers and sends user request to Web service.

2. Receives and handles request & network communication and call application process.

3. Calling appropriate Function and send request to data access layer.

4. Connect to database, Get query from the application, send query to database.

5. Receive Results from database and send result to Application.

6. Return Functions response.

7. Send response to PC and manage network communication.

8. Display result on PC client’s screen.

PDA

The next diagram shows how data flows through the processes when requesting data to or from the PDA.

Behaviour steps:

1. Button event triggers and sends user request to Web service.

2. Receives and handles request & network communication and call application process.

3. Calling appropriate Function and send request to data access layer.

4. Connect to database, Get query from the application, send query to database.

5. Receive Results from database and send result to Application.

6. Return Functions response.

7. Send response to PDA and manage network communication.

8. Display result on PDA client’s screen.

Sensor

And finally when request a reading from the sensor the following execution path takes place:

Behaviour steps:

1. Button event triggers from PDA and sends user request to sensor.

2. Get temperature and send back to PDA client.

3. Display temperature on PDA client’s screen.

4. Button event triggers from PC and sends user request to sensor.

5. Get temperature and send back to PC client.

6. Display temperature on PC client’s screen.

Deployment view

Figure 5: Deployment Model

The figure above illustrates the deployment model of the Smart Hospital System, in which software elements are allocated to hardware elements. In this model, the web server and the database server are placed on a single server node that connects to both PC clients and PDA clients with either TCP/IP or wireless protocols. A sensor that measures patient’s body temperature communicates with PC clients and PDA clients as well, via Ethernet and wireless, respectively.

Initial Implementation Architecture

Implementation View

The following diagram shows the initial architecture design showing infrastructure and software components.

Figure 17: Initial Implementation Architecture

Types of technologies to be used

The technologies used in this system are as follows:

- PDA using PocketPC Operating System - Selected because it supports the other required technologies such as .Net and wireless networks.

- .Net CE 1.0 - A framework used to run applications on the PocketPC operating system.

- IEEE 802.11b - A wireless networking protocol, selected because it's supported by the PDAs. This can be upgraded to 802.11g if the need ever arises. All wireless network devices need to support WPA2 for security.

- WPA2 - Used to encrypt wireless network traffic and authenticate wireless devices on the network. It has been selected over WPA because it has additional security features such as less DOS vulnerabilities.

- Windows XP - To be used on client PCs.

- .Net 1.1 Framework - To be used on client PCs to allow the application to run.

- IIS 6.0 - To be used on the server to support web services. This is necessary to support the chosen middleware and serves as an application server.

- Windows Server 2003 - To be used on all servers.

- InterSystems Cache - The database server that will store all data. This has been selected because of its common use in the medical industry.

- CrossBow wireless sensors - These can measure temperature and transmit it wirelessly using a low power system. There's an ethernet bridge available that allows it to connect to the wireless network used by the PDAs.

- Juniper Networks Odyssey Access Client - This provides a WPA2 driver on PocketPC devices. At the moment PocketPC does not have native support for WPA2 so this 3rd party driver provides the security required in the system. If an upgrade to the OS adds this then Juniper's client will no longer be required.

Wireless Sensor Technology

Wireless temperature sensors are used in this system to facilitate taking temperature readings of patients. This reduces the chance of data entry errors and improves the speed at which this work can be performed by nurses.

The technology chosen for this implementation is shown in the diagram below. There are three components, the model numbers are also shown below. This allows the sensor to be accessed from the PDA and allows for a large number of sensors to be used.

To address scalability more gateways can be added throughout the hospital, operating on different frequencies. The sensors themselves form a mesh network allowing them to transmit further distances using as little power as possible. This is an important consideration here. If batteries need to be replaced often then it nulls the convenience obtained from their use.

Figure 18：Wireless Sensors

Factors affecting to the Technologies

'Wireless' – required to allow for mobility, so that the system can be accessed from all areas.

'IEEE 802.11b' – chosen because it is supported by the PDAs to be used.

'.Net 1.1' – allows for faster development than other platforms.

'CE .Net 1.0' – it is well supported by the PDAs being used.

'Web Services' – this middleware was selected because it’s scalable, can be run as a web farm if required, and is well supported by the .Net framework.

'InterSystems Cache database' – provides an object oriented repository making it easier to persist data. It’s commonly used in the medical industry making it easier to support.

'PocketPC' – provides the user a familiar Windows XP style GUI. And it supports .Net.

'Windows XP (on PC client)' – is easy to support, provides users a familiar GUI, supports .Net.

'WPA2 security' – provides a strong wireless security protocol, mainly encrypted data transmission and restriction of wireless clients. This also replaces the need for SSL since it also encrypts network traffic. And since the network is private and physical access can be restricted SSL over the wired network isn’t necessary.

'Serial port' – required by the wireless sensor receiver allowing it to be connected to the system.

'OpenNetCF' – provides a nicer look and feel for the PDA GUI.

'Crossbow sensor: Mica2 MTS300' – can measure temperatures and operate in wireless mode.

Sample Screenshots

The following screen shows how the PC application could look. The menu on the left allows for quick navigation to all of the main functions. Users need to log in and are able to log out to allow for a different user to use the application.

The search panel across the top allows for quick searches of patients by name.

The panel below shows the diagnosis summary. This could be edited if the current user has the necessary permission.

Figure 19: PC UI

The screenshot below shows a sample PDA client. The interface is much simpler, navigation is through a popup menu. This accesses all the major functions of the application. A patient lookup button is provided as this is a common task while moving between patients in the hospital.

The Vitals screen shows the basic readings taken, and allows the user to connect to a wireless sensor (if available) and display its readings.

Figure 20: PDA UI

Justification

An explanation on ideas behind the architecture presented

An analysis of the stake holders and their needs was done at the start and this flowed onto all further analysis. This is necessary so that their needs are met from the very beginning. Changing the architecture after this stage would be most costly and might not fulfil their requirements sufficiently.

Then an analysis of the opportunities that could be gained from the project was performed, together with listing constraints so that they can be addressed.

The system was then broken down into components to allow for a flexible design and to introduce inherent benefits such as modularisation, allowing for concurrency, and robustness by design.

Separate PC and PDA clients are the best choice here because they meet very different needs, both functional needs and non functional (such as mobility). This is seen throughout all of the architecture, with different functions available from either client depending on who will be using each and where they'll be using them from (physical locations). These two applications serve as user interfaces and have no application logic.

The use of a web service solves a lot of the intricate requirements such as handling multiple concurrent connection, networking, and scalability. The alternative would be to develop this framework from scratch but by using an off the shelf middleware development costs can be saved.

The application logic layer is divided into four components. This provides the benefits mentioned above without over complicating the architecture. These processes don't need to send any data to each other and only communicate with the database server and return data to the client.

The sensor could have been connected to a computer (such as the application server) via a USB cable. This would have necessitated a separate application to communicate to the sensors using a polling technique and storing the data on the database. This would use unnecessary wireless traffic to the sensors and use more battery power than available. Instead it was decided to use an ethernet bridge on the wireless receiver (for the sensors) and allow the PDA clients to poll it only when necessary.

Bibliography

Bennett, S., S., McRobb and R., Farmer, (2006). Object-Oriented Systems Analysis and Design Using UML (3rd Edition). Berkshire: McGraw-Hill Education.

Crossbow Technology Inc, (2006). http://www.xbow.com/Products/products.htm. Viewed: September 17, 2006.

Juniper Network, (2006). “Juniper Networks Odyssey Access Client”, Products and Services. http://www.juniper.net/products/aaa/odyssey/oac.html. Viewed: September 19, 2006

Reekie, J. and R., McAdam, (2006). Software Architecture Primer. Sydney, Angophora Press