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
  1. Health Practitioner starts System
  2. System initiates
  3. Health Practitioner chooses to create a prescription
  4. DO INCLUDES Create Prescription
  5. Health Practitioner choose to save the created prescription
  6. System stores the prescription in the Prescription Database
  7. Health Practitioner chooses to send the prescription
  8. DO INCLUDES Send prescription
  9. 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
  1. 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

  1. 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

  1. 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
  1. System displays associate pharmacies to chose
  2. Health Practitioner chooses pharmacies to send to
  3. System includes chosen pharmacies in destinations list
  4. Health Practitioner chooses send
  5. 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
  1. 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

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
  1. Patient starts System
  2. System initiates
  3. System requests patient’s account ID and password
  4. Patient enters account details
  5. System verifies account details with Patient Account Database
  6. Patient requests unordered prescriptions
  7. System shows unordered prescriptions
  8. Patient selects a prescription to order
  9. System sends prescription order to Billing System
  10. Patient chooses to set collection/delivery options
  11. System communicates with Drug Deliver System
  12. System sends Patient a receipt to print
  13. System stores new prescription order in the Prescription Order Database.
  14. 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
  1. Pharmacist requests new prescription orders
  2. System searches Prescription Order Database
  3. System shows new prescription orders
  4. Pharmacist chooses earliest new prescription order
  5. System shows prescription information for chosen order
  6. Pharmacist chooses to print prescription items
  7. DO INCLUDES Print Prescription Items
  8. Pharmacist obtains medication(s) and attaches printed label(s)
  9. Pharmacist marks prescription order as processed
  10. System sets order as processed in Prescription Order Database
  11. 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
  1. Pharmacist confirms print instruction
  2. FOR EACH medication

2.1 System sends label to printer

  1. System sends receipt to printer
  2. 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
  1. User starts System
  2. System initiates
  3. User chooses to create an ADR Report
  4. DO INCLUDES Create ADR Report
  5. 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
  1. User enters patient details
  2. User enters medication name, dosage and other usage information
  3. User enters description of adverse reaction(s)
  4. User confirms details are completed
  5. System sends details to ADR Database
  6. 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
  1. System sends new ADR Report alert to associated Health Practitioner
  2. System shows Health Practitioner the report
  3. System sends new ADR Report alert to registered Health Authority
  4. System shows Health Authority the report


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.


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.


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.


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.


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.


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.

Leave a Comment