This essay was produced by one of our professional writers as a learning aid to help you with your studies

Example IT Essay

	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. Patient’s details must exist on database.
Normal Course	DO UNTIL patient details found 1.1 Health Practitioner enters patient’s full name 1.2 System searches Patient Database for patient’s details 1.2.1 IF System finds patient details then patient’s 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 patient’s full name 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 patient’s 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 patient’s 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 Delivery 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)

It’s 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 isn’t 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 packages 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 patient’s full name from CreatePrescription JSP until the patient record is found.

MedicationConfirmer: to process 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.

ADRReportProcessor: 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.

PrescriptionOrderProcessor: 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.