Software Architecture Document For e-Arogya
Content
1.Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. Architectural Representation
3. Architectural Goals and Constraints
4. Use-Case View
4.1 Actors
4.2 Use-Case Realizations
4.2.1 System Administration
4.2.2 Patient Registration and Electronic Health records (EHR)
4.2.3 Investigations and results
4.2.4 Supply Chain Management
4.2.5 Support Service management
4.2.6 Death Certification
5. Logical View
5.1 Overview
5.2 Architecturally Significant Design Packages
5.2.1 Electronic Health Records
5.2.2 Pharmacy
5.2.3 Labs
5.2.4 Support Services
5.2.5 Death Certificate
5.2.6 User Privileges
5.2.7 System Logger
6. Process View
6.1 Patient Registration and Electronic Health records (EHR)
6.2 Investigations and results
6.3 Supply Chain Management
6.4 Support Service management
6.5 Death Certification
7. Deployment View
8. Implementation View
8.1 Overview
8.2 Layers
8.2.1 Presentation Layer
8.2.2 Service Layer
8.2.3 Database Layer
9. Size and Performance
10. Quality
List of Figures
Figure 1: 4+1 model
Figure 2: System Administration use-case
Figure 3: Patient Registration and Electronic Health records (EHR) use-case
Figure 4: Investigations and results use-case
Figure 5: Supply Chain Management use-case
Figure 6: Support Service management use-case
Figure 7: Death Certification use-case
Figure 8: Logical view
Figure 9: Electronic Health records logical view
Figure 10: Pharmacy logical view
Figure 11: Labs logical view
Figure 12: Support services logical view
Figure 13: Death certificate logical view
Figure 14: User privilege view
Figure 15: System logger view
Figure 16: Patient Registration and Electronic Health records (EHR) process view
Figure 17: Investigation results process view
Figure 18: Supply chain management process view
Figure 19: Support service management process view
Figure 20: Death certification process view
Figure 21: Deployment view
Figure 22: Implementation view
1. Introduction
1.1 Purpose
e-Arogya is the software solution proposed to make the functions of the Emergency Treatment Unit (ETU) of the Colombo South Teaching Hospital (CSTH) more efficient. After introducing the system, the ETU will be able to provide a fast, efficient, quality service to the patients. Then this system will be expanded to be used in other departments at CSTH and finally other hospitals in Sri Lanka as a ‘ripple effect’.
This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.
1.2 Scope
The scope of this
1.2 Scope
The scope of this software architecture and design document is to depict the architecture of the ‘e-Arogya’, e-Heath Solution for the ETU of the Colombo South Teaching Hospital. This document describes the architectural model used to design the system architecture, different views of the system architecture according to the model as well as architectural goals and constraints. sfsdfsdf
1.3 Definitions, Acronyms, and Abbreviations
· ETU - Emergency Treatment Unit
· CSTH - Colombo South Teaching Hospital
· SOA - Service Oriented Architecture
· ESB - Enterprise Service Bus
· SCM – Supply Chain Management
· SSM – Support Service Management
· HER – Electronic Health Records
1.4 References
· Web Services Architecture, W3C Working group note 11 February 2004, http://www.w3.org/TR/ws-arch/
· System Requirement Specification of e-Arogya
· Business Process Re-Engineering for the ETU at the CSTH by Dr.M.N.Karunathilaka
1.5 Overview
The rest of this document discusses the 4+1 view model of the system ‘e-Arogya’. The 5 views discussed in this model are the Logical View, Process View, Deployment View, Physical View and the Use Case View. In this document each of these views are clearly discussed and represented graphically. Also each of these views is targeted for different users and they are clearly stated in the document.
2. Architectural Representation
This document follows the “4+1” view model. Each of the views in this document is described below.
1. Logical View – This view provides the functionality the system provides to the end users. This is represented using block and line diagrams. This view is mainly targeted for the end users.
2. Physical View/ Deployment View – This view provides the topology software components on the physical layer and the communication between these layers. This view is represented using UML deployment diagram and is targeted for the system engineers.
3. Process View – This view describes the dynamic aspect of the system. This discusses about the processes and how they communicate with each other. This view is represented using UML including the activity diagram and is mainly targeted for the Integrator.
4. UML.
5. Use Case/ scenario View – This view contains how the key uses cases affect the architecture of the software. This view is represented using UML diagrams.
The above views are designed and clearly indicated in the rest of the document. Each view is explained using a diagram.
Figure 1: 4+1 model
3. Architectural Goals and Constraints
e-Argoya is a system that stores sensitive data of patients. Therefore it should contain very high security on the data stored. Therefore the database that is used to store the data is encapsulated by an interface that will control the access to the database. Also the users of the system are divided in to user class. Any user in the system should belong to a group. These groups have clearly defined privileges so that the users can only add, modify and view data that have allowed by the system.
The entire patients expect privacy about their medical data. Therefore medical data can only be viewed by the user groups that have the required privileges.
This system should be developed with the minimum amount of cost and in a time limit. Therefore as a solution to overcome these two contains we use an open source heath system that supports as many functionalities that are required in the system. The major constraint that affects the architecture of the system is that it should adhere to the architecture of the open source system that will be used. After researching for a suitable system we decided to use OpenMRS as the base open source system. Therefore the architecture of e-Arogya adheres to the architecture of OpenMRS.
e-Arogya system is developed in the purpose of providing an efficient health care services for Sri Lankans at public hospitals. Apart from that since this is used at emergency patients’ admissions and treatments also this system should be able to handle the incoming requests in a very efficient manner and the users should be able to perform the functions within a shorter time period than they are handled manually.
One of the major requirements of e-Arogya is that is should be able to expanded as a ripple effect to the other departments of the hospital and then to the other hospitals. Therefore this concept should be supported by the architecture.
4. Use-Case View
This view represents how the users of the ‘e Arogya’ system interacts with the system and what are the functions each user can perform. These use-cases are described under few sections so that it is easy to understand.
4.1 Actors
The following is the list of known actors that will interact with the deployed system.
· Director
· Deputy Director
· Deputy Director IT
· Deputy Director Administration
· Deputy Director Supply
· Deputy Director Laboratory
· Deputy Director Support Service
· Specialist
· Doctor
· Nurse
· MRO
· Admission counter officer
· Admitting officer
· Coroner
· Head of Hospital Police Post
· JMO
· Clerk
· Overseer
· Store Manager
· Store Keeper
· Pharmacist
· Pathologist
· Microbiologist
· Hematologist
· MLT
· In charge of Ambulance
· In charge of Cleaning
· In charge of Meals
· System Developer
4.2 Use-Case Realizations
The architecture of the system is designed under 6 main sections. In order to have a clear picture of the system, the use cases belonging to each section are grouped together.
4.2.1 System Administration
Figure 2: System Administration use-case
4.2.2 Patient Registration and Electronic Health records (EHR)
Figure 3: Patient Registration and Electronic Health records (EHR) use-case
4.2.3 Investigations and results
Figure 4: Investigations and results use-case
4.2.4 Supply Chain Management
Figure 5: Supply Chain Management use-case
4.2.5 Support Service management
Figure 6: Support Service management use-case
4.2.6 Death Certification
Figure 7: Death Certification use-case
5. Logical View
This section describes the architecturally significant parts of the design model, such as its decomposition into subsystems and packages.
5.1 Overview
e-Arogya is designed using three layers. The middle layer, called the service layer contains the business logic of the system. The business logic is implemented using web services and a ESB.
According to the W3C Working group note 11 February 2004 of Web services architecture a web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine processable format (especially WSDL). Other systems interact with the web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP, with an XML serialization in conjunction with other web related standards.
Each web service contains a interface and a service implementation. This service implementation can be considered as a package in the logical view. There are 7 major services and they are EHR, Pharmacy, Lab, Support Services, Death Certificate, User Privileges and System logger. The packages for these web services are name after the name of the web service.
Figure 8: Logical view
5.2 Architecturally Significant Design Packages
Details of the 7 packages and their sub packages are described below.
5.2.1 Electronic Health Records
This package implements the EHR (Electronics Health Records) function of the system. EHR service provides much functionality. They are Medical records handling, patient details handling and patient transfers. Each of these functionalities can be considered as a sub package. The diagram below shows the packages and the sub packages structure. The use cases are organized in each of the sub packages.
Figure 9: Electronic Health records logical view
5.2.2 Pharmacy
This package implements the functions of the pharmacy. In the pharmacy non clinical items and non-clinical items are stored and released for the use of patient in the ETU after a request. Following diagram shows the structure of the sub packages.
Figure 10: Pharmacy logical view
5.2.3 Labs
This package implements the functions of the lab. The lab performs different kinds of investigations on patients. Following diagram displays the package structure.
Figure 11: Labs logical view
5.2.4 Support Services
This package implements the functions of the support services. Support services at the ETU are Meal, Laundry and Cleaning. Each of these support services are implemented within a sub package. Following diagram displays the package structure.
Figure 12: Support services logical view
5.2.5 Death Certificate
This package implements the process that should be followed when a death occurred to the point where the body is released. The following diagram displays the package structure.
Figure 13: Death certificate logical view
5.2.6 User Privileges
This package implements the functions related to user privilege management of the system. Following diagram displays the structure of the sub packages.
Figure 14: User privilege Logical view
5.2.7 System Logger
The system has a logger that records all the activities in the database for future reference. This is useful to find bugs that come up in the system as well as if an attack happens to the system, to find how and when and who did the attack.
Figure 15: System logger Logical view
6. Process View
This section describes the main processes of the ‘e-Arogya’ system.
6.1 Patient Registration and Electronic Health records (EHR)
Figure 16: Patient Registration and Electronic Health records (EHR) process view
6.2 Investigations and results
Figure 17: Investigation results process view
6.3 Supply Chain Management
Figure 18: Supply chain management process view
6.4 Support Service management
Figure 19: Support service management process view
6.5 Death Certification
Figure 20: Death certification process view
7. Deployment View
In this architectural view, the likely physical network and hardware configurations on which the e-Arogya system will be deployed will be presented. Figure below depicts the deployment model.
Figure 21: Deployment view
In this system server, PC’s and the database server are located in a Local Area network. The existing fiber optics network of Colombo South Teaching Hospital can be used for this.
When this system is deployed for ETU it requires PC’s to access the system. These PC’s doesn’t require very high performance to run this system. There is a separate database server in this system because when it is expanded as a ripple effect for other departments of the hospital and for the other hospitals in Sri Lanka it becomes a large system and requires a separate server for data storage.
For ‘e-Arogya’ system there is a requirement of an SMS gateway for sending alerts for various purposes. To achieve this server is connected to an SMS gateway through the Internet.
8. Implementation View
This section describes the overall structure of the implementation model, the decomposition of the software into layers and subsystems in the implementation model, and any architecturally significant components.
8.1 Overview
e-Arogya system architecture is basically divided into three layers. They are presentation layer, service layer and the database layer. These three layers and how they interact with each other are shown in the figure below.
Figure 22: Implementation view
8.2 Layers
In this section the three layers are described in detail.
The presentation layer is the topmost layer that interacts with the user. This layer will present the information to the user and get information from the user. This layer interacts with the middle layer that is the service layer through an interface. This layer allows separating the UI from the business logic and databases. By introducing this layer the system becomes loosely coupled and provides room to expand it in the future.
8.2.2 Service Layer
Service Layer is the middle layer. This layer contains all the business logic of the system. This layer has two types of sub systems, the ESB (Enterprise Service Bus) and the web services. The ESB communicates with the other two layer layers as well as the web services within this layer. The web services do not directly communicate with each other. This uses the ESB too.
8.2.3 Database Layer
The database layer is the bottom layer. This layer communicates with the ESB at the service layer through an interface. By separating the data from the business logic and the presentation we expect to achieve much security. Since the data is only access by the ESB and that is through an interface, a user will not be able to access unauthorized data.
9. Size and Performance
The architecture of the system should be designed in such as way that is should be able to expanded in to other departments in the Colombo South Teaching hospital and other hospitals with no or minimum amount of modifications to the architecture.
The maximum delay on providing a service to the user should be 1s. Within this time the request has to be processed and the response should be displayed to the user.
10. Quality
Since the product suppose to be used in the government sector the quality of the product is very important. Currently the product developed only for the ETU of the CSTH. But it is expected to be extended therefore that it could be used to manage entire government hospital system of Sri Lanka. Therefore it is very important that the code is not too complex and it is easy to read and understand by another developer.
The users of the product have very limited knowledge in computers. Therefore the user interfaces have to be very simple and it should have to be multi language. We expect to give facilities such as demos and user guides to the users there for they can get familiar with the system.
The system should be able to run from the moment it has been deployed in the working environment without any crashes.
The system should be independent from the underlying system. Therefore the system should be able to run on any platform without doing major changes. By using a language like Java or PHP we can achieve that requirement.
Data security is also very important factor. By proper user authenticating and giving minimum privileges to the users we can achieve data security. We also have to take security measures to prevent unauthorized access to the data through the network.
No comments:
Post a Comment