1 2 These are the abbreviations we are going to use in this presentation, we call the system we are going to implement

as PRMS which stands for Patient Record Man agement System. 3 we will discuss the following topics today. 4 PRMS is an electronic patient record system, this is being implemented for the Texas Scottish Rite Hospital For Children. 5 Basics about what is an use case. Its a bussiness process, we depict use cases at 3 levels Abstract-as verb noun phrases. High level- giving the scope. Expand ed - Showing the interaction between the user and the system. 6 This is the tabulated procedure for deriving an use case, Basically it should answer the following questions It should be a business process, should start and end with an actor and finally accomplish a task. 7 We will discuss the use cases according to the priority of in the wish list. R3.1: This is the use case for recording test request for a patient In the Abstract use case Actor is the user which can be a doctor, nurse etc and the action done is recording the test. In the high level use case, the use case begins with the user entering t he test request information to the PRMS systems and the use case ends when the u ser sees the confirmation from PRMS that the record is added successfully. 8 In the expanded use case, here we have tabulated the step wise intercation bet ween the user and the system in achieving the use case task, 0 Initial state is the system displays gui for the user. 1 the user selects the approtiate action button that he wants to perform for t his use case i.e 'Record Test Request'. 2 the system takes the user to the another gui where he can enter the details, (0??? its not begining with the actor???). 3 in the next step user enters the the details and selects "Record" button to indicate that he is done with recording 4 The system displays the confirmation message to the user that record is adde d/saved. 5 The last step is when the user saves the confirmation message. This is the e nd of the use case. 9 R3.2 : This is the use case for user to record the actual test results. Abstract: Actor is the user, Verb is recording the test result High level: use case starts when users enters the test result and ends when t he user sees the appropriate confirmation 10 Expanded: 0 system displays GUI 1 User selects "record test result" button, 2 System takes him to "Test Result GUI" 3 User enters the details and clicks "Record" button 4 System gives the confirmation message 5 user sees the confirmation message. 11 R3.3: This use case is for Recording the patient consultation details

Abstract: Actor is User, verb is recording the consultation details High level: use case begin with user entering the consultation details and en ds with user seeing the confirmation message. 12 Expanded: main steps are user selecting "Record Consultation" button System displaying "Record Consultation" GUI User entering the information And the confirmation message. 13 UML Diagram: This is the UML diagram with all the previous use cases, drawn u sing the use case factory tool, recording the test request, recorsing the actual result, and recording the consultation 14 R4.1: This use case is for tracking the file checkout, Abstract: Actor is the user, Verb is recording the file checkout details, Highlevel: begins with user entering the file details like why it is being t aken, whn it will be returned. And ends with user seeing the confirmation. 15 Expanded use case: main steps here are User selects "Record file Checkout" button GUI is displayed User enters the info system updates it s database User sees the confirmation from the system. 16 R4.2: This use case is for recording the file checkin Abstract: Actor User, Verb is recording the file checkin Highlevel: Starts with user entering the file checkin information and ends wh en user sees the confirmation 17 Expanded: Main steps "Record file check-in" in the GUI User entering the info in the respective GUI System updating the checkin in to the database 18 R4.3 : This is for knowing the file locating Abstract: Actor is user, Verb is Tracking the file Highlevel: Starts with user entering the file details and ends with user ge tting the file location details 19 Expanded use case: Main steps: "File track" in the GUI User gives the file details to be tracked SYstem displays the file location 20 R4 UML diagram for file checking in , ckeout and tracking 21 R5 : This is the use case for recording the phone call details to/from patien t Abstract: Actor is user, Verb is to document High level: begins with user entering the phone call details ends with a con firmation 22 Expanded: Main steps:

User selects "Phone call record" button Gui is displayed User enters the info and a confirmation is given 23 R5 UML 24 R1: Use case for creating new patient record Abstract: Actor: user verb is to create Highlevel: Begins with user entering new patient record info and end with con firmation for successfull entry 25 R2: Use case for searching and retrieving patient records Abstract use case: Highlevel: This begins with user entering one or more patient identifiers like patient id, DOB etc and ends when user sees the search result 26 R1 to R5 UML 27 R6: This is use case for Pending task Notifications Abstract: High level: 28 R7.1 Use case for remote login to PRMS Abstract: Highlevel: 29 R7.2 Use case for user authorized functionality access Abstract: Highlevel: 30 R7.3 Use case for user logout Abstract: Highlevel: 31 R8 Use case generating the report Abstract: Highlevel: 32 R9 Use cae for attaching notes: Abstract: Highlevel: 33 R10 use case for accessing information from EDM Abstract: Highlevel: d 34 R6-R10 UML 35 Use case tracibility matrix with the requirements marked along the use cases they are covered in. 36 UC feedback ???? 37 References: left TSRHC slides Demo which req???