This essay was produced by one of our professional writers as a learning aid to help you with your studies
Example IT Essay
|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|
|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.|
1.1 Health Practitioner enters patient’s full name
2.1 Health Practitioner enters medication name
|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.|
5.1 IF successful then System confirms prescription was sent to all pharmacies
|Triggering event||System could not send to all pharmacies|
|Assumptions||Pharmacy systems are operational|
1.1 System reports failure to send to all pharmacies, specifying particular pharmacies that have not been sent to
Place Prescription Order
|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|
Process Prescription Order
|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|
Print Prescription Items
|Triggering event||Pharmacist chooses to print prescription items|
|Assumptions||Printer is available and prepared to print; Printer handles both label and receipt|
2.1 System sends label to printer
Process ADR Report
|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|
Create ADR Report
|Actors||User, ADR Database|
|Triggering event||User chooses to create ADR Report|
|Assumptions||User creates one ADR Report per medication|
New ADR Report Alert
|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|
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.
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.