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
END FOR

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

  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
END FOR

  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

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.