HL7 Summer School. Day 1 Session 4 Capturing clinical requirements: Owen Johnson, Senior Fellow, YCHI, Leeds University

Transcription

1 Yorkshire Centre for Health Informatics HL7 Summer School Day 1 Session 4 Capturing clinical requirements: Owen Johnson, Senior Fellow, YCHI, Leeds University Design Process Delegate Capture clinical requirements

2 Capturing Clinical Requirements A UML Design Process Learning Objectives To introduce a light-weight, agile approach to UML design linking scenarios/ storyboard, semantic modelling, use cases, object oriented analysis, component design and interaction diagrams. To overview the science of requirements representation and how to apply it to healthcare To appreciate the art of requirements capture To review some common tools for working with clinicians. To get some practical experience applying these techniques to a case study. To reflect on the process of requirements capture.

3 The challenge Current Future Source: Business Case for the phased implementation of an e-prescribing solution from University Hospital of South Manchester

4 An agile approach to design Current Future Model the As is process Model the Will be process Process Improvement To what extent are you as a designer looking to improve clinical processes? making current care pathways faster and safer enabling radical improvements in how healthcare is delivered

5 5. Create prototypes of the Future solution, implement and review An agile (and creative) approach to design 1. Analysis Study and understand the current solution to develop a logical solution Current As is Solution Logical Model New Logical Model Candidate Design Solution 1 2. The Creative Step Rethink the model 3. Design Generate candidate design solutions Candidate Design Solution 3 Candidate Design Solution 2 4. Choose Future Will be solution

6 Techniques Storyboard/ User Story/ Scenario After examining Kari Kidd on the GHH Paediatric Ward, Dr Aaron Attend decides to prescribe some topical betamethasone (VTM) 0.1% (strength) for application to a patch of eczema on her wrists (route of administration) twice a day. This order is entered into the order entry system. When visiting the ward to review the prescription the pharmacist, Susan Script, reviews this new prescription and realises it is incomplete, as it is not fully specified. Following hospital policy from the dermatologists, she amends the prescription to include a reference to ointment, so that it now reads betamethasone ointment 0.1% (VMP) topically to wrists (route of administration) bd. The nurse in charge sends this amended prescription to pharmacy for supply, which can be filled as it is fully specified. The Pharmacy Department sends up a 30g tube of betamethasone 0.1% ointment manufactured by Futuna Ltd, (AMPP), fully labelled for Kari Kidd, with the dosage instructions etc. Source: UKCPRS Programme Dictionary of Medicines and Devices Use Cases register. Online at See also Hinchley (2007), pg 21

7 Techniques Semantic Modelling Take a scenario, any scenario, and examine it word by word Verbs = actions/ business processes Nouns (and Noun Phrases)= Entities in the problem domain After examining Kari Kidd on the GHH Paediatric Ward, Dr Aaron Attend decides to prescribe some topical betamethasone Medical Practitioner Examine Patient Patient GHH Paediatric Ward :Ward Betamethasone : Medication Dr Aaron Attend: Medical Practitioner Kari Kidd :Patient? Person

8 Exercise 1 Semantic Modelling from a Storyboard As individuals 1) Work through the e-prescribing storyboard identifying the interesting verbs and noun phrases. As a group 2) Create Sticky Note classes for all the nouns and noun phrases Use Yellow Sticky Notes to represent People or Autonomous Systems Use Green Sticky Notes to represent any other entity Tip 1 the aim is to identify Classes (you can derive/ guess these from instance names, e.g. Kara Kidd is a Patient). Don t worry about instance names just write the name of the class on the Sticky note. Tip 2 if you come across adjectives that relate to a Class it can suggest an Attribute of a Class, if your UML is good enough you can write an appropriate attribute name on the Class Sticky. 3) Arrange the Sticky Notes on a flipchart sheet and, thinking about the likely real world relationships, rearrange the Stickies to create a partial Concept Class diagram for the problem domain. 4) Create Sticky Note Use Cases for each interesting verb Use Pink Sticky Notes to represent the use case Tip 3 Make sure your use case has an active verb and a noun, doing something to something. 5) On a second flipchart sheet, use the Pink Sticky Notes to create a Use Case Diagram if you know how. Identify at least one Actor for each Use Case. Tip 4 To test that your use cases are sound, think about who triggers it and what value it creates for the actor that triggers it.

9 Exercise Debrief Reflect on How hard is this technique When might this technique be appropriate Who generates the scenarios When would you stop How much technical UML knowledge to you need How does this fit with HL7 models

10 HL7 R-MIM Source: Hinchley (2007), page 42. Reproduced without the permission of the author.

11 Partial solution Medical Practitioner <<Actor>> Examine Patient Prescribe Medication Patient <<Actor>> Person Medical Practitioner Patient Ward Use Case Diagram prescribed Prescription Class Diagram Prescription Item Medication

12 HL7 MIM Model OO Design methods are similar but different to HL7... Source: Hinchley (2007), page 43. Reproduced without the permission of the author.

13 A UML-based approach 4) Make component and deployment choices 8) Design responsibilities for software components Use Case Deployment Component Activity 1) Model Business Processes with Use Cases Class 5) Model System requirements with Use Cases Object Collaboration 2) Create Concept-level Class Diagrams 6) Create Design-level Class Diagrams 3) Model Business Processes with Activity Diagrams State Sequence 7) Model use case realisations with Interaction Diagrams

14 Use Case Modelling A Use Case diagram is a simple model of either a business process or a system requirement. GP Surgery Patient Make an Appointment The principles behind use cases are based on systems theory, any software component, system, business unit or organisation can be seen as a system which interacts with people or other systems outside its boundary. Use Case modelling is based on carefully understanding systems theory.

15 Use Cases as transactions of value to an actor PERSON Withdraw Cash BANK Use Case Transactions At the end of a (successful) use case the actor should have received something of value to them. PERSON CASH BANK Transaction A series of actions and interactions which result in an exchange of items of value, such as information, goods, services and money.

16 Use Cases a Class of transactions between actor and system Use Cases are technically a class of transaction between actor and system. They represent the set of all possible scenarios. The Use Case Diagram is therefore a type of (concept level) class diagram, it shows actor classes, use case classes and the relationships between them. Patient Make an Appointment The set of scenarios for the above use case might include: Owen:Patient rings reception for an appointment at 3.30 on Tuesday 7 th December Carol:Patient pops in to make an appointment any time today Simon:Patient agrees with his GP to see her appointment same time next week Sue:Patient makes appointments at 2.15 on 8 th December; 9 th January and 4 th March Beryl makes an appointment for her mum Gladys:Patient at 4pm on 9 th December Owen:Patient rings to cancel appointment for Tuesday 7 th December as he realises he s running a course that day, he makes an appointment for 3.40pm on Tuesday 14 th instead. Samantha:Patient uses the Internet to book an appointment online for Monday 13 th December. Colin:Patient s the surgery for an appointment any time Wednesday and they him back a time of 4.20 which he confirms is fine. Each scenario is an instance of the use case performed by an instance of an actor. There are an infinite number of possible scenarios for a use case but they are all essentially following a similar pattern.

17 Use Case Description As text Basic Flow is the main flow described in the Use Case Description. Patient Make an Appointment This use case begins when Patient decides they want to see a Doctor. They contact the Reception staff and ask for details of when their preferred Doctor is free. They may discuss a number of appointment slots that are free before they decide on one that is most convenient for them. They choose an appointment slot and the Reception staff record the patient s name on the appointment record and confirm the details back to the Patient. At the end, the actor is Happy - they get measurable value (Reward > Effort). Alternate Flows are other variations (alternatives) that still lead to a successful completion of the use case. The actor is still happy - they still gets measurable value (Reward > Effort). Exception Flows are variations that lead to an unsuccessful use case - the user fails to complete the use case transaction. The actor is NOT Happy - they get no measurable value and have wasted their time (Effort > Reward).

18 Use Case As a Template Use Case Name: Primary Actor: (Actor that initiates Use Case) Other Actors: Value Proposal to Actor(s) (the goal of the Use Case from the Actor s perspective) Basic Course of Events: (The Normal Flow) This use case begins when Value Proposal You can use this UCDForm template for use case descriptions Source: YCHI5030M, Process Modelling Benefits and Change Alternative Paths: (Other paths through the use case which result in a successful outcome typically variations to the basic course of events, determined by the actor and their needs). Exception Paths: (Other paths through the use case which result in an unsuccessful outcome typically when something goes wrong) Assumptions: Pre-conditions: Post-conditions: Related Business Rules: Basic Flow Alternative Paths Exception Paths Related Non-Functional requirements Usability, Performance, Security: (Any non-functional requirements that are specific to this Use Case rather than the system as a whole) Project: Author : Date:

19 Use Case Description as Activity Diagram Prescribe Medication Medical Practitioner <<Actor>> Order Entry System <<Actor>> Pharmacy System <<Actor>> Medical Practitioner Decide to Prescribe Enter Medication Order Validate Order Review Order [Y] [N] Revise? [N] Confirm? [Y] Cancel Order Confirm Order Send Order to Pharmacy Receive Order from Ward Fail Complete

20 Making Implementation Choices What systems will be used? Where will they be located? How will they be connected? What responsibilities should each system have? How will the systems work together to help realise the use cases? EHR Server 1 Server 2 Order Entry HL7 Pharmacy

21 Implementation Example Order Entry System <<Actor>> Pharmacy System <<Actor>> Source: PharmacyExport Module. A brief demonstration of a Pharmacy Export module for OpenMRS. this Module integrates OpenMRS and the idart Pharmacy System.

22 Use Case Description as Sequence Diagram Medical Practitioner <<Actor>> Order Entry System <<Actor>> Pharmacy System <<Actor>> Pharmacist <<Actor>> Enter Medication Order Prescribe Medication Confirm Order Send Order Medical Practitioner Review Order Review Order Pharmacist Revise Order Send Alert Revise Order Revise Order

23 Options for Integration A) Different systems in different organisations HL7 B) Different systems from different vendors on different servers HL7 (or something lighter) EHR Server 1 Server 2 Order Entry HL7 Pharmacy

24 Options for Integration C) Different systems from same vendor Shared database EHR Server 1 Server 2 Order Entry HL7 Pharmacy

25 Options for Integration C) Different modules from same vendor on same server Enterprise database EHR Order Entry Pharmacy Server 1 Interface Engine D) BUT No organisation is an island. HL7 Rest of Healthcare ecosystem

26 A UML-based approach 4) Make component and deployment choices 8) Design responsibilities for software components Use Case Deployment Component Activity 1) Model Business Processes with Use Cases Class 5) Model System requirements with Use Cases Object Collaboration 2) Create Concept-level Class Diagrams 6) Create Design-level Class Diagrams 3) Model Business Processes with Activity Diagrams State Sequence 7) Model use case realisations with Interaction Diagrams

27 The Agile Manifesto Source:

28 Capturing Clinical Requirements A UML Design Process Learning Objectives To introduce a light-weight, agile approach to UML design linking scenarios/ storyboard, semantic modelling, use cases, object oriented analysis, component design and interaction diagrams. To overview the science of requirements representation and how to apply it to healthcare To appreciate the art of requirements capture To review some common tools for working with clinicians. To get some practical experience applying these techniques to a case study. To reflect on the process of requirements capture.

29 Yorkshire Centre for Health Informatics Leeds Institute of Health Sciences Faculty of Medicine and Health Charles Thackrah Building 101 Clarendon Road Leeds, United Kingdom LS2 9LJ Tel. +44 (0)