For the majority of cases “you should use a single technology for all user interface classes in the system” where this does not work then the classes should use the same technology. When the user interface is verified with the user and is also limited then “deployment costs such as distribution, training and support” are reduced.
Boundary classes between an external system and the system (system interface)
In this scenario the system interface classes shows how the chosen system and an external system will communicate with each other.
Control, entity and lifecycle classes
The three different classes can be grouped together in the following ways:
- Control – these objects convert high level messages into many simple ones, which provides a more friendly user interface.
- Entity – these objects hold the persistent business data and rules for the system.
- Lifecycle – these objects create, locate and destroy entity objects.
All of the above objects should use the same technologies or similar ones and are included in the scenario i.e. the Healthcare application. The user interface complexity is the same, even though, for example, the patient user interface class is more restrictive than the pharmacist user interface class. Hence, encapsulating all the user interface classes in one group will make the application much easier.
Describe each group
Once groups of classes have been identified, each group’s technology requirements can also be identified. Using the same descriptive techniques the technology selection will be made easier as it will describe both problems and their potential solutions. The following descriptive areas are looked at:
- User interface complexity
- Deployments constraints for user interfaces
- Number and type of users
- Available bandwidth
- Types of system interfaces
- Performances and scalability
User Interface Complexity
The GUI is the most important factor when selecting the technology for the interfaces classes hence, complexity of the user interfaces needs to be concluded. This is done by looking at each of the user interface class and are grouped together to ensure they satisfy the most complex of interfaces.
The group includes the following analysis classes:
- PatientLoginUI – This allows Patients to enter their username and password as proof that they are authorised to use the system.
- UserLoginUI – This allows GPs and Pharmacists to enter their ID and passwords as proof that they are authorised to use the system.
Deployment Constraints for User Interfaces
Use cases need to be explored to determine deployment constraints, then, a descriptive category needs to be chosen that fits all of the use cases. An example of which includes the ability for doctors to access the system using any NHS computer or even a personal computer via their own ID’s and passwords. The descriptive categories for deployment constraints are:
- hand-held device
- any Web browser on the Internet
- late-model web browser on the Internet
- late-model browser on a network
- specific browser on a network
- dedicated workstations on a network
The doctor must be able to access from any computer in a network or at home, the majority of constraints will be application to the scenario except for the handheld device for which there are no evidence that they are used. Deployment constraints do not determine whether remaining categories 2 and 3 are satisfactory. There’s no specific way of determining which of the constraints should be selected for the technology, however should a survey or questionnaire can be carried then it would make it easier. However, it would seem logical to use number 2 as this can be used over any browser on the internet, no matter how slow the systems are.
Number and Types of Users
There are three actors in the Healthcare application. The actors are the users and include the GP who prescribes the medicine for the Patient. The patient may also order repeat prescriptions on-line and collect them later. Once the Pharmacists has received the prescription an arrangement is made for payment and the medicine is either collected in person or is delivered to the patient. Due to safety it is vital for all three actors to have access to a list of Adverse Drug Reactions on the website.
The descriptive categories that describe users are:
- small number of dedicated users
- general use within an organisation
- large audience with a high interest
- huge audience with a low interest
The Patient(s) agree with option 3, where as the GP and Pharmacist fulfil option 1.
The most suitable for the Healthcare application is option 3, since the most restrictive case must be supported.
Available bandwidth
A key factor in selecting the technology is the bandwidth constraint, the following categories are available:
- Dial-up internet connection – the most common type of connection and also the slowest
- Fast internet connection – fast and efficient enabling most forms of data to be transmitted
- Dedicated network between client and server – allows the client and server to transmit data at the highest of speeds and can even be used from the home
It is difficult to determine which constraint will be used, however category 2 would seem most appropriate at the moment as it is the most common.
Types of system interfaces
These describe the systems interfaces to the system’s functionality, are sometimes used for performance and scalability, which will be looked at in the following section.
Performance and Scalability
Performance and scalability factors are derived from the class and sequence diagrams which describe the features that influence performance and scalability such as data access and update patterns.
The descriptive categories that affect both performance and scalability are:
- read-only
- isolated updates
- concurrent updates
The most appropriate category must be chosen by seeing “how multiple users performing the use cases simultaneously affects each entity object.” Sequence diagrams must therefore be inspected.
For the Login use cases (GP using system, Pharmacist using system, Patient using system), the system locates the user entity object that corresponds to the appropriate actor. Once that object has been located, the password must be checked to see if it is valid. The system must therefore read the password so category 1 is appropriate in this case.
(question 3)
Standardisation of Data Interchange
There have been three types of standardisation which include data types, federation and intelligence, combining to make the task of managing data significantly more complex.
In a number of different application systems, data is distributed over a number of heterogeneous, often autonomous systems, and data exchange among them is difficult. The main problem of process interchange in this problem domain is that of heterogeneous data i.e. different forms of data.
Heterogeneity of data is a common trend, where data is no longer in the form of records in well-defined tables (structured data), but in the form of unstructured content, such as text (in emails, web-pages etc.). It is difficult to integrate structured and unstructured data formats.
On a technical level, varying hardware platforms, operating systems, programming languages and database management systems cause heterogeneity. On a conceptual level, heterogeneity is derived from real world concepts. Autonomy of a source means having differences in representation and access (operating system, database systems) as well as having varying content. This heterogeneity caused by autonomous systems poses problems for system integration since sources are stored and maintained differently.
Although the system will be based on the internet it has been discovered recently that decentralisation in the growth of data has become common, and that even within a specific framework data cannot be freely expressed between the departments or the different hierarchy of employees. The data has to remain static at where it is, and access the data through federation, due to the fact that centralisation of data will not possible.
Another trend is using data for competitive advantage and is associated with data analysis. The data needs to be manipulated, aggregated, transformed, and analysed in increasingly complex ways to produce business intelligence.
An article by Grimson et al. examines the problems of integrating electronic patient records.
To manage their data and processes, hospitals use Enterprise Resource Planning (ERP) systems which attempt to integrate all departments onto a single computer system that can serve all the department’s individual needs. Commonly, the hospital will have more than one ERP system in use for each department at the hospital. This leads to problems in sharing information between care organisations and across systems, causing costs to escalate and efficiency to be reduced.
The information needs of each user may be different, and individuals may only be allowed access to certain information, thus introducing issues concerning data confidentiality. Data continues to be processed manually due to reasons such as under-investment of information technology (IT), and the inept quality where they are available. Some of the reasons determining why such a slow progress is being made includes the complexity of medical data and data entry.
In a strategic sense, a more business process view of health care delivery is needed to increase cost efficiency.
The Electronic Health Care Record (EHCR) stores individual patient records, this system must only available for access by doctors as patient confidentiality is vital. Various integration challenges are apparent when accessing and using the EHCR due to the complexity of medical data, the distributed nature of health care computing, and the different formats of data (structured, unstructured), to mention a few. The requirements of the different user sectors are also so varied.
The most vital problems with information integration to solve are those concerning communication between heterogeneous sources, for example between the patient and the pharmacist.
(question 4)
Technology used for application
CHOSEN TECHNOLOGY - J2EE
Web applications are becoming more and more important. Over the past few years, software development technology has grown and we have been able to build applications that were difficult if not impossible just a short time ago. Building web based applications for large web applications are very complex so it is important to realise that they are not just based upon placing simple web pages placed on a web server but are sophisticated applications that require some sort of software services for the purpose of fulfilling the correct generation of HTML required for the business objective.
The nature of the Healthcare application is based upon a component model. The application will be implemented as software components and in essence be a component model that will specify the interfaces that are provided by components and their interaction between one another. It will also specify their runtime environment that will act just like a container, including the behaviours for these components and their interactions.
HTML Production
HTML (Hypertext Markup Language) is an important part of any web based system. It is the document format language that is used commonly on the World Wide Web. Web browsers read HTML language and display the contents on the page. In a Healthcare system it is essential that the use of HTML is to be very important because the components will essentially have straight link with the interface classes. The HTML production here is important because we have a form of an electronic system that can be used also as part of a website allowing for expansion and also where for example, patients that apply for repeat prescriptions, online, need the presence of HTML production for use in displaying the pages needed while repeat prescriptions are being made. These pages can be viewed using Internet Explorer and many other web browsers such as Mozilla and Netscape. When we talk about expansion here, what we are saying is that when a change is made in one page, the appropriate changes are made in the corresponding pages needed for that particular alteration. So a sense of calling other pages allows expansion of the website.
The Healthcare system will have well-matched technologies that work together forming the main J2EE technology, such as Java Server Pages (JSP), Java Servlets and Enterprise Java Beans. The healthcare system will have its own HTML production class where the class creates the dynamic HTML pages that will be used initially by the Java Servlets. The JSP will allow the rapid development of web-based applications that are platform independent and separates the user interface (UI) from content generation. This allows us to be able to change the overall page layout without changing the underlying dynamic content. It uses XML type tags that encapsulate or hold the code that creates the content for the page. The code or logic for the application is based within the server based resources (example, the ) which the page accesses with the aid of these tags. Hence, the JSP’s will use the HTML production class to generate dynamic web pages that include data entry pages such as forms for repeating prescriptions, questionnaires for NHS healthcare feedback, tables storing Patient details etc where the Servlets import the corresponding Java Beans component that queries in SQL language for example, to store the data that is inputted by the user and retrieve the data that is called by the user.
Important objectives need to be considered before the designing commences, those are:
- To allow the complex logic code to be hidden away from the interface layer of the HTML production. This way easy reusability and efficiency will help the healthcare system designers to create the application quickly.
- Allow the adoption of super and sub class tables. That is where a table may lie within another, yet displaying separate information.
Java Servlets
As mentioned previously, Java Servlets are used in order to provide a component-based, platform-independent method for building web-based applications. They generate dynamic content based upon the user input within the healthcare application. The Servlets enable the creation of web browsers based on the conditions of user input, where the “API is Sun’s flexible and extensible framework for server-side development”. There are several terms used in the servlets that will be familiar to web developers:
- Hyper-Text Transfer Protocol (HTTP)
- HTTP request
- HTTP response
- From data
- Cookie
- HTTP servlet
- Servlet engine
For further details into how these terms function refer to [1].
Java Servlets and Servlets in particular enable developers to retrieve data much more easily by “managing sessions and session data” however the developer is still required to create HTML scripts to compile a browser. Due to the complex nature of formatted HTML scripts they are sent back to the browser which requires the servlets to “obtain a PrintWriter from the HttpServletResponse”. The actual workings of the servlets give the possibility of being associated by the HTTP that specifies the communication protocol between the GP and web server. The same can be said for the pharmacy and the web server. A successful communication between the HTTP requests is sent from the browser to the server that is being used. A connection between the HTTP page opens and closes when a successful task is carried out between two or more machines so considering the healthcare application, our forms, tables, questionnaires etc that are filled in by the user will be sent to the server and fetches information that was entered about the patients, GP, pharmacy or adverse drug reaction etc. It does this by use of one of the following submissions methods that maybe used; GET or POST. These submission methods are specified inside a , using the METHOD attribute. The difference between METHOD="GET" (the default) and METHOD="POST" is primarily defined in terms of form data encoding. However in our Healthcare application we can also use another element ACTION can call the Servlet files to correspond in directing the user to the correct pages. The Servlet that is called imports the use of the correct Java Beans file that will store the information about the patients, GP, adverse drug reaction etc and query’s this information using SQL database to store this information. Another example may be that a GP may want to fetch patient record from the database by feeding it with patient details, such as patient’s surname, first name, ID etc. A response is then sent back from the server to the client i.e. back to GP with patient record.
Some of the advantages of using servlets include: the ease at which they can be learned and other being that they protect the developer from complex HTTP scripts. They are compatible with a variety of technologies such as JavaScript and XML, and are also compatible with server-side technologies. The servlet is provided free when bought with the enterprise Java so it is also cost efficient. Some of the disadvantages include: extensibility and flexibility have to be taken into account, so despite its simplicity the developer is not able create designs freely.
JavaServerPages
JSP’s make heavy use of Java Beans, which are classes that follow a standard pattern of a no-argument constructor (required in JSPs) and public GET and SET methods. They function in the same way as the Java Servlets. In our healthcare application, we deploy this file in the user interface component since it generates dynamic web pages when a task is carried out by the user on the system. For example, the GP submits an adverse drug reaction caused by a specific drug for a particular patient on the system. The doctor can at any time view previous records of ADR on alternative medicines.
Another important issue regarding the use of JSP in our healthcare application is that it keeps as much code as possible out of the JSP and in a bean or other .java class which is then referenced in the page. The code sections of a JSP can quickly become unmanageable and difficult to debug, especially since the compiler is working on the generated ".java" source file and not directly on the JSP. Hence, since this allows for easy and manageable maintenance of the Healthcare application it also enables dynamic page generation that will have a varied layout for every page because of the nature of the business. It is important that for example, the GP will get the same dynamic content within a different layout than that of pharmacy that may be presented in a different layout. This is because we assumed that the GP, patient and pharmacy must log into the system before it can continue with carrying out operations. So the process of logging in will lead the pharmacy into their own appropriate layout or page. The same can be said about the GP or the patient. If it was considered that Healthcare application had set standard layout for every page, the servlets would be more appropriate to deploy.
Enterprise JavaBeans
A Java Bean component may have a visual representation, for example, a user-interface component, or may be non-visual, for example, a database connectivity component.
Java Bean components communicate with each other by sending events. The interface between components is therefore provided by the event model in the Java language. Components have properties which can be set by the programmer to achieve some customisation. Enterprise JavaBeans (EJB) is an extension of the Java Bean model that provides a mechanism for encapsulating a Java Bean component as a CORBA component. Enterprise Java Beans are component architecture for the healthcare distributed system that will be used. The main purpose for the EJB is to provide and support a multi user distributed system. In our healthcare application we have 3 user types: GP, Patient and Pharmacy. They are secure as they allow the developer to define who is allowed to access the system and the boundary is maintained within code, so it is also easier to manage. Enterprise JavaBeans also enables simplified development methods to be used
There are two types of Enterprise Java Beans namely Entity beans and Session Beans.
- Entity Beans – They model the business concepts that can be expressed as nouns. Entity beans often represent "things”, real-world objects like drugs. A bean can even represent a fairly abstract "thing," such as a prescription or adverse drug reaction. Entity beans describe both the state and behaviour of real-world objects and allows us to encapsulate the data and business rules associated with specific concepts. For example, the Patient Bean encapsulates the data and business rules associated with a patient, and so on. This makes it possible for data associated with a concept to be manipulated consistently and safely. Every entity bean has an underlying table within a database where each instance corresponds to a row, that stores information regarding the patient, drug, etc.
- Session Beans – These Beans are used to implement the actual business objects. These objects hold client-specific business logic and the state of these objects reflects the interaction with a particular client. It is not intended for general access, therefore the session beans will execute as a single client. In our Healthcare application, the session bean calls upon a request to change the object in the database. This is done by the calling method on entity beans which then changes its state of persistency. The session beans applied in this application are divided into two different types; Stateless session beans and statefull session beans.
Stateless session beans – These beans have no internal state and no not need to be passivated. They do not remember any set of dialogues held with the client, so each dialogue with a client is started off with a new state. For example in our healthcare application, the repeat prescription forms maybe of a short format that would allow quick user input of the specified fields. When the form is filled in, it must be sent straight away. It does not have the ability to be saved if half of the form was completed. Hence, every time that form is refreshed a new state for that form begins and no input from the previous time it was filled in was remembered.
Statefull session beans – These beans are the opposite of the stateless beans. They have an internal state they need to handle activation and passivation. However, there can be only one Statefull Session Bean for each client. When a patient details form is filled in, it may require to be saved at a particular section of the form. Hence, it remembers its previous state and can be referred to be completed at another point in time.
(question 5)
Discussion on software architecture for the healthcare system and developed component model
Component based model
In this discussion on the healthcare system architecture I will be talking about the presence of a technical architecture chosen referring to the above designed component based model for the healthcare application.
Software architecture for the process of designing the global organization of the healthcare system includes:
- The separation of the software into subsystems
- Decision on how these subsystems will interact
- And determining their interfaces. The architecture that is the core of the design and that will often constrain the overall efficiency, reusability and maintainability of the healthcare system.
UML diagrams can be useful in describing aspects of the architecture model, in that useful package diagrams, subsystem diagrams, component diagrams and deployment diagrams help in suitable system architecture modelling. For the healthcare system we can specify the correct use of user interfaces, JSP’s, servlets, controllers and beans. Using the MVC model as part of the J2EE technology we were able to devise a component based model that explains the architecture of the healthcare system application.
The core user interface components have a direct link to the HTML production components that will display the contents of the dynamic web pages. For the healthcare system we need to display the correct web pages for the correct user. For example, GP must be able to view the corresponding pages it calls to initiate and that it has access to.
Now talking about the architectural view, the healthcare system can be separated in to 3 main layers. The packages have been grouped with sub classes present within them and have divided in terms of user interface, workflow and domain (database). The following is a package diagram that consists of the entity classes for the GP Domain.
As you can see from the above diagram, all the entities involved in describing the GP domain are present. The details about a patient are important so that the GP can refer back to those details and be aware of those patients who are registered with them so that they can be treated. The prescription history is an important aspect for this domain because we can keep a history of all the prescriptions given to a particular patient. When a prescription is used, this information is stored in the entity. The drug entity will work hand in hand with the prescription history entity in that we can derive many symptoms, illnesses and adverse drug reactions of the patient from it. The GP details entity is also by far an important entity that will characterise the domain allowing us to recognise the GP that has logged in to the system.
The below is a package diagram that consists of the entity classes for the Pharmacy Domain. This diagram includes the following entities that make allows achieving the desired business objective for the pharmacy section of the healthcare application to be successful. The pharmacy keeps a record of all the drugs that are prescribed to patients. So records of such drugs are constantly updated within this entity. All the prescriptions that are processed need to be stored so the prescription needs to be present. The signature entity is an important one in that the pharmacist is able to match a particular patient by its signature in order to successfully give the patient the correct drugs. The details about a GP are necessary in that the pharmacy can confirm that a recognised GP has prescribed the prescription. It can also contain a restrictive amount of information about patients like patient address for example, so that the drugs if necessary can be delivered to the patient’s home. Details about the pharmacy such as staff names, opening and closing hours are also included in this domain.
The main reason for keeping these two domains separate from each other is purely because there maybe some details about a patient for example that a pharmacy should not be able to access. The same can be said where some information about a pharmacy such as staff details should not be accessible by the GP. In this distributed environment, it is difficult to fetch personal details from a remote database. What we mean by this is that for example, it may not be appropriate for a GP to access information about a patient from the pharmacy database. It is best that the patient information is extracted from the direct patient database rather than and indirect pharmacy one.
Our next package is the Workflow package that holds the control classes. There are two main workflow packages, one for the GP and one for the pharmacy. Our GP workflow holds
As mentioned previously, the workflow packages hold control classes. For this GP workflow, the control classes involved are the Login Manager that is used to confirm and recognise the GP that is logging into the system. The control class here will do this confirmation by checking that the GP_ID and password entered match GP_ID and password in the GP database. The issue prescription control class will update the GP database with the prescriptions issued to the patients. The class will also be used send the prescription through to the pharmacy domain notifying the pharmacists of the prescription that was issued. Also a control class for Find_PatientID is important in that we can search the database for a specific patient. However the control class here initially opens up a session with the database so that a connection is open and a search for the patient is made. Lastly the ADR_Update control class is present in order for the GP to update any adverse drug reactions that occur to the patients. It does this by executing a control program that will update the ADR repository whenever the update button is pressed.
My next workflow is for the Pharmacy, where a control classes for the Login Manager is needed so that the pharmacy is recognised when entering the system. Without logging in, no processes can be carried out. The Confirm _Signature control class is present so that an initial copy of each patient’s signature can be stored so that a future reference in checking that the correct patient receives the correct drug. The ADR_update control class can simply be placed here because it can be possible that a patient may contact a pharmacy of their adverse drug reaction, and so an update is needed where a control program is executed that will update the ADR repository. Lastly the Find_PrescriptionIssued control class that will be executed in order to search the prescription that has been issued to a patient by their Patient_ID.
My last two packages relate to the user interface. Those two are again for the GP_UI and Pharmacy_UI.
The LoginUI will display the login page to the GP in order to log in. It will prompt the GP to enter the GP_ID and password. Without the log in, the GP may not access and carry out any task with the system. Once they have logged in, the GP is able to view the pages to issue a prescription and to report an ADR. The Extract_Patient_Record will display the specific patient records that are searched for.
The Pharmacy_UI package works in the same way as for the Login process where without logging in, no tasks can be carried out. So it important that a login page is displayed on the pharmacy site, where the pharmacy_ID and password is prompted.
The Retrieve prescription is present so that the pharmacy is displayed with the appropriate page to display the prescriptions that have been sent through by the GP’s for the patients. The Report_ADR will simply display a page where a ADR can be sent through and be centrally stored in its repository.
The Pharmacy_UI will look like the following:
Here it is important to remember that the ADR will have its own central repository where the ADR common in particular drugs are stored.
(question 6)
Reference:
[1] CT Arrington, 2001, Enterprise Java with UML, John Wiley & Sons Inc.
