Issuing Prescription - Assignment Example

1. Use case Issuing Prescription This use case helps the GP to prepare the prescription for any patient after his diagnosis. Actors: GP. Preconditions: The actor should have logged into the system and should have made his diagnosis out of it. The actor should have his opinion on the patient ready. Flow of Events: 1. A screen comprising of the details to be collected are shown to the actor. The details would include the patient identification, the patient ailment note, the date and time of diagnosis, the medicines that have to be issued to the patient, duration of the treatment and the when to consume these medicines are all collected in the form. 2. After filling the form the GP would click the save button to save the details for the use of the pharmacist. 3. The patient identification is cross checked with the database and the existence of the patient is verified with the patient database. 4. All the medicines prescribed and their existences are verified in the medicine database. 5. After confirming the existence of all the medicines and the patient, the information is stored in the prescription database. Exceptions: 1. If the patient identification is not present in the patient database, then an exception would occur displaying an error screen to the GP, indicating that the patient identity entered is incorrect or that the patient is not covered under the NHS. GP is asked to re-enter the patient identity or cancel the entry. 2. If the medicine does not exist in the medicine database, then an error screen is displayed indicating that the medicine entered does not exist and the relevant information is to be entered again. 2. Use case name: Managing Drug Dispensation System Description: The Pharmacist sees the prescription for any patient and issues relevant drugs to the right patient. Actors: Pharmacist Preconditions: The GP should have created the prescription and the patient should inform the pharmacist his reference. Flow of Events: 1. The actor is shown a form that collects the patient identification and reference number for the electronic prescription. 2. The system displays the prescription made by the GP for this purpose. It also shows whether the prescription has been supplied already or if partly supplied, the quantities supplied are indicated. 3. From the information shown, the actor picks up the relevant drugs for the satisfaction of the patient. He completes the form by entering the supply effected against the prescription and also takes an electronic signature from the patient as proof supply. 4. The actor saves the information in the relevant database by clicking the save button. 5. The information is saved after checking that the quantities do not exceed the prescribed quantities and the medicines are the same as the ones prescribed. 6. The opening form for collecting the next patient identification is displayed again. Exceptions: 1. The prescription reference number or the patient identity given might not be right and an error could occur. An error screen has to be displayed indicating the error and the actor is asked to rectify it. 2. An exception occurs when the quantities supplied exceeds the prescribed quantity. An error screen is shown and the pharmacist is asked to rectify the error. 3. Use case name: Reporting ADR Description: An adverse reaction of the medicine can be registered using this screen by any of the actors. Actors: GP, Pharmacist and Patient Preconditions: The prescription of the GP for the patient should have been drawn and the medicines should have been issued. Flow of Events: 1. A form is thrown open to the actor. This would contain the patient identity and the prescription reference. 2. Based on the information entered, a new screen is displayed indicating the prescription details already supplied and the consumption pattern suggested and any doctor notes, if present. 3. Further information on the adverse reaction is also collected in the screen. After which the finish button is pressed. 4. Saves the complaint for retrieval and review. 5. Sends a message to the relevant authority to look into the matter. Exceptions: 1. An exception occurs if the patient identity or the prescription reference is not present. An error screen is displayed and the actor is requested to correct the same. 1.c) Interaction Diagrams Issuing Prescription Managing Drug Dispensation Reporting ADR 1.d) Class diagrams Issuing Prescription Managing Drug Prescription Reporting ADR The class diagram shows the functions that are contained in the class and the attributes that are present in every one of the classes that is planned. In the attributes, PrescriptionId and the PatientId are the keys to the databases and the attributes of various classes. The verify is the patient id verification in the database if the patient id exists or not. 2. The technology adopted for the development of the system should be easy and user friendly for operation. The system needs to be spread over the internet and operated across multiple locations by a large number of users simultaneously. Therefore, the technology adopted should be web driven and the database should be capable of storing large volumes of data and retrieving them with little or no observable delay in operation. Technology adopted should ensure that all these are made possible. The users should be given on common web server which will answer all the queries related to the distribution of medicines. The server should be failsafe with appropriate backup processes in case of failure. The technology should ideally support a hot standby for the entire system enabling it in case of failures. The major categories for consideration will be user friendliness, the data storage and retrieval system or the database, the web process and the support that it can provide and finally, the hot standby and backup processes. All these categories need to be taken care of. 3. The information flow between the GP and the pharmacist contribute to a major data interchange standardisation. In addition to this, there should also be appropriate data interchange designed for communication with other module of the system that is designed. Data interchange is expected to include data translation and transaction management solutions. The standardisation needs to be done on both the counts. However on one end, common server based software would ensure that the data exchange between the GP and the pharmacist will be seamlessly integrated. However, a similar structure needs to be adopted for the flow between other modules namely sourcing and drug delivery. 4. The web based architecture which will ensure a common server that would host the database and the software together. This would be built over a component based architecture that would optimise the development effort by providing the basic components for the system development. Most of the component based systems come with a Rapid Development Environment ensuring quick and swift development of the software. Hot standby technology could be adopted from any one of the vendors who specialise in standby solutions like Veritas or such other products to provide for a hot swappable standby enabling the entire service to work without any break. For effective data interchange, XML data files can be created and transferred from one module to the other. 5. The complete system design will comprise of the following major components which can be broken down further into individual components that might be standardised for the purpose. The component diagram is shown below: There are three actors in the model; the patient, the GP and the pharmacist. All the actions of the system are executed at the web server. This would support three tables in the database; one, pertaining to the patient and the patient details, two for the prescription and finally the third is on the ADR. There are methods that would update the patient record, verify the patient identity number when entered on the screen. In case of the prescription, collection of the prescription details is done when the GP enters the values. Save and show prescriptions are provided for saving the details and showing it to the pharmacist. After the issue, the prescription is again updated along with the patient update. The ADR is created in case there is an adverse reaction noticed by any of the actors. 6. Diagram indicating the Enterprise Beans, the Session beans, the servelets and the Jsp files. a) Three JSPs are included as in the diagram shown above primarily to create the user interface required. b) Servelets should be handling the saving and searching the relevant information from the database. However, they will make use of the relevant beans for the operation. Two servelets have been planned for this project. c) Session beans are used for prescription information and for medicine lists. This will help in creating / choosing the medicines from the database and form a 'cart' before saving them on to the disk. The same is done when medicine is dispensed to the patients. Two session beans have been created. d) No Stateful session beans is planned because every time a patient is taken up, he is new and there need not be information pertaining to the earlier case carried forward. e) Entity beans for interacting with the database are created. There are four entity beans marked with eb in the figure above. Every one of them helps in either saving the data or in searching for the relevant data. Read More