System For Creating, Controlling And Processing a Medical Prescription - Free Essay Example

Sample details Pages: 6 Words: 1911 Downloads: 7 Date added: 2017/06/26 Category IT Essay Type Essay any type Level High school Did you like this example? Issue Prescription Scenario ID IPv1 Actors Health Practitioner, Prescription Database Triggering event Patient is diagnosed and in need of a prescription Assumptions Prescriptions are only issued through electronic transfer; Scenario is for one prescription Normal Course Health Practitioner starts System System initiates Health Practitioner chooses to create a prescription DO INCLUDES Create Prescription Health Practitioner choose to save the created prescription System stores the prescription in the Prescription Database Health Practitioner chooses to send the prescription DO INCLUDES Send prescription Health Practitioner chooses to exit the System. Create Prescription Scenario ID CPv1 Actors Health Practitioner, Patient Database, ADR Database Triggering event Health Practitioner chooses to create a prescription Assumptions Health Practitioner has a local database for patient details. Patients details must exist on database. Normal Course DO UNTIL patient details found 1.1 Health Practitioner enters patients full name 1.2 System searches Patient Database for patients details 1.2.1 IF System finds patient details then patients Full Name, Address, DOB and other details are automatically entered into a new prescription. END UNTIL 1.2.2 ELSE System prompts Health Practitioner to re-enter patients full name . Don’t waste time! Our writers will create an original "System For Creating, Controlling And Processing a Medical Prescription" essay for you Create order FOR EACH medication to be prescribed 2.1 Health Practitioner enters medication name 2.2 System searches ADR Database for record of medication 2.2.1 IF ADR record is found then System reports ADR contraindications to Health Practitioner 2.3 Health Practitioner confirms medication to be added 2.4 System adds medication to the prescription 2.5 Health Practitioner writes the dosage and/or notes for the medication 2.6 System adds notes to the prescription END FOR Health Practitioner confirms prescription is completed Send Prescription Scenario ID SPv1 Actors Health Practitioner, Associate Pharmacy Database Triggering event Health Practitioner chooses to send a prescription Assumptions There is no pre-determined set of pharmacies to send the prescription to. Normal Course System displays associate pharmacies to chose Health Practitioner chooses pharmacies to send to System includes chosen pharmacies in destinations list Health Practitioner chooses send System sends prescription 5.1 IF successful then System confirms prescription was sent to all pharmacies 5.2 ELSE DO EXTEND Retry Send Retry Send Scenario ID RSv1 Actors Health Practitioner Triggering event System could not send to all pharmacies Assumptions Pharmacy systems are operational Normal Course DO UNTIL Health Practitioner decides otherwise or send is successful 1.1 System reports failure to send to all pharmacies, specifying particular pharmacies that have not been sent to 1.2 System prompts Health Practitioner to chose whether to try to resend now or chose a time duration to retry or not to try again 1.3 IF Health Practitioner chooses to try again now or later then System sends prescription at the chosen time 1.4.1 IF successful then System confirms prescription was sent to all pharmacies 1.4.2 ELSE Retry Send 1.4 ELSE END UNTIL Place Prescription Order Scenario ID PPOv1 Actors Patient, Patient Account Database, Prescription Database, Prescription Order Database, Billing System, Drug Delivery System Triggering event Patient decides to place an order for medication prescribed Assumptions Prescription has already been issued by Health Practitioner; Patient wants one prescription only Normal Course Patient starts System System initiates System requests patients account ID and password Patient enters account details System verifies account details with Patient Account Database Patient requests unordered prescriptions System shows unordered prescriptions Patient selects a prescription to order System sends prescription order to Billing System Patient chooses to set collection/delivery options System communicates with Drug Deliver System System sends Patient a receipt to print System stores new prescription order in the Prescription Order Database. System marks prescription as ordered in the Prescription Database. Process Prescription Order Scenario ID PRPOv1 Actors Pharmacist, Prescription Order Database, Supplies Management System, Prescription Database Triggering event Pharmacist decides to process a prescription order Assumptions Overall system is only accessible by Pharmacist and already verified; Prescription issue already verified when order was placed Normal Course Pharmacist requests new prescription orders System searches Prescription Order Database System shows new prescription orders Pharmacist chooses earliest new prescription order System shows prescription information for chosen order Pharmacist chooses to print prescription items DO INCLUDES Print Prescription Items Pharmacist obtains medication(s) and attaches printed label(s) Pharmacist marks prescription order as processed System sets order as processed in Prescription Order Database System informs Supplies Management System of medications allocated Print Prescription Items Scenario ID PPIv1 Actors Pharmacist, Printer Triggering event Pharmacist chooses to print prescription items Assumptions Printer is available and prepared to print; Printer handles both label and receipt Normal Course Pharmacist confirms print instruction FOR EACH medication 2.1 System sends label to printer END FOR System sends receipt to printer System confirms print instructions sent to printer Process ADR Report Scenario ID PADRRv1 Actors User Triggering event Patient decides to report an adverse reaction to a medication Assumptions Not all patients are able to use the System directly, in which case they report to their Health Practitioner who becomes the User; all network services are operation and other systems are active Normal Course User starts System System initiates User chooses to create an ADR Report DO INCLUDES Create ADR Report DO INCLUDES New ADR Report Alert Create ADR Report Scenario ID CADRRv1 Actors User, ADR Database Triggering event User chooses to create ADR Report Assumptions User creates one ADR Report per medication Normal Course User enters patient details User enters medication name, dosage and other usage information User enters description of adverse reaction(s) User confirms details are completed System sends details to ADR Database System confirms report completed successfully. New ADR Report Alert Scenario ID NADRRAv1 Actors Health Practitioner, Health Authority Triggering event System stores ADR details in ADR Database Assumptions Health Practitioner of patient has the highest priority to receive the ADR Report Normal Course System sends new ADR Report alert to associated Health Practitioner System shows Health Practitioner the report System sends new ADR Report alert to registered Health Authority System shows Health Authority the report Boundaries The system offers several independent user interface classes that need not be loaded from the same host as where their controller is loaded. There are user interface classes to issue, create and send a prescription, retry sending a prescription, place a prescription order online, process a prescription order in the pharmacy, print prescription items and to process and create an ADR report. There is a delivery interface for sending an ADR report alert to the patients Health Practitioner and one for sending to any Health Authority. The system collaborates with a number of distributed and localised databases that are accessible through corresponding interface classes. Distributed databases include the Prescription Database, ADR Database and Prescription Order Database. Localised databases include the Patient Database, Associate Pharmacy Database and Patient Account Database. The system offers communication with external systems for delivering drugs to patients through the Drug D elivery System Interface class, for managing the billing system through the Billing System Interface class and for managing supplies through the Supplies Management System Interface class. Controls The system includes a number of control and transactional classes, that process the external requests and inputs from actors, generate results and entities and makes responses and requests to the external actors. These control classes correspond to the observable flows described originally. Entities The system generates and uses certain of entity classes that correspond to the persistent health care system artefacts. These include Prescription, PrescriptionOrder and ADRReport. The artefacts of label for a medication and receipt for a prescription order do not persist in the system and are not made into entity classes. 3) Its possible to define a standard format for sending human legible data throughout the system for the exchange of Prescriptions and ADR Report Alerts, using XML documents containing attributes and data and are validated using a standard, agreed XML Schema at either end. To exchange system-to-system data, such as to communicate prescription order data to the Billing System, Drug Delivery System and medication allocations to the Supplies Management System, the more succinct and efficient EDI standard can be used, although it isnt very legible. 4) This system can be implemented using J2EE, with its default Web Server, and with JAXP and JAXM APIs used to develop components on an Application Server. MySQL or Orcale RDBMS can be used to manage the databases on a Database Server through JDBC APIs. JSP, Servlets and EJBs should be used to implement the boundaries, controls and entities of the system. The system should be networked with standard TCP/IP and HTTP protocols supported over which XML and EDI can encapsulate communications. 5) The system is designed with a J2EE 3-tier architecture using the Model-View-Controller paradigm. There is a tier of Presentation (View) components which are encapsulated from a layer of Business Logic (controller) components that are decoupled from a Data Access (model) layer. The presentation layer is packaged into J2EE Web Archive files (WAR) of JSP and Servlets for deployment and the Business Logic and Data Access layers are packaged into SessionEJBArchive (JAR) and EntityEJBArchive (JAR) files, respectively. The use of a tiered architecture partitions the system into highly manageable pac kages that can be independently modified without affecting other packages providing that the interface contract is retained. This provides great flexibility to, for example, change or add presentation components without having to interfere with code within the business logic layer. 6 a) The follow JSP pages are part of the web component deployment: IssuePrescription JSP, CreatePrescription JSP, SendPrescription JSP, RetrySend JS, PlacePrescriptionOrder JSP, Print PrescriptionItems JSP, Process ADRReport JSP and Create ADRReport JSP. b) There are a number of lightweight interface coordination processes that certain Session Bean or JSP components would otherwise undertake while interacting with each other, that instead are shifted to Servlets. The following Servlets are deployed within the web component: PatientDetailsFinder: to process the (re) entry of the patients full name from CreatePrescription JSP until the patient record is found. MedicationConfirmer: to pro cess the choice of medication entered to CreatePrescription JSP by searching for an ADR record and get confirmation. PrescriptionFiller: to collect and check patient details and medication details entered to CreatePrescription JSP. DestinationPharmaciesNegotiator: to request and receive the list of pharmacies to send to/from SendPrescription JSP. RetryDecider: to request and find out from RetrySend JSP whether to retry sending the prescription and at what time. NewOrderFinder: to receive the request to obtain unprocessed PrescriptionOrders from ProcessPrescriptionOrder JSP and find out which order to process. ADRReportDetailsCollector: to check all ADR report details are entered to CreateADRReport JSP. c) Stateless Session Beans deployed are as follows: RetryController: to resend prescription if and at the time given by the result forwarded RetryDecider. PrintItemsProcessor: to send print label and print receipt instructions to PrinterInterface. ADRReportPro cessor: handing over to CreateADRReport stateful session bean and send ADRReport to ADRReportAlerter. NewADRReporter: to send ADR report to HealthPractitionerInterface and any Health Authority interface. ADRReportCreator: to create ADR Report from entered details forwarded by ADRReportDetailsCollector. d) Stateful Session Beans across multiple client requests: IssuePrescriptionProcessor: this session bean retains the prescription state until the Health Practitioner requests to save it and send it. PrescriptionCreator: this session bean retains each medication to add to the prescription until the Health Practitioner confirms to add it. PrescriptionSender: this season bean retains the prescription until the Health Practitioner instructs to send it. PrescriptionOrderPlacer: this session bean retains the state of the prescription selected for order until it is marked as processed and retains the prescription order until it is sent to the database. PrescriptionOrder Processor: this session bean retains the prescription order state until it is marked as processed and the prescription until it used to communicate with the SuppliesManagementSystemInterface. e) Entity beans deployed are as follows: Prescription, PrescriptionOrder, ADRReport, Patient, PatientAccount and AssociatePharmacy.