Audio Transcripts Workflow Analysis - Remote Learner · UML, developed a few decades after and...

Audio Transcripts

Workflow Analysis Optional Lectures

Audio

Transcript

WORKFLOW ANALYSIS

Component 10 Fundamentals of Health Workflow Process Analysis & Redesign

Unit 3 Interpreting and Creating Process Diagrams Lecture A Introduction

Slide 1 Welcome to the Fundamentals of Health Workflow Process Analysis and Redesign: Interpreting and Creating Process Diagrams: Introduction. This is Lecture a. The Component Fundamentals of Health Workflow Process Analysis and Redesign, examines different diagramming methods for developing graphical representations of processes in the health care setting. Throughout the last century, different diagrams and notations have arisen. There is considerable overlap between them. Some have fallen by the wayside and others remain in use. Some have become international standards, while others exist in textbooks and articles. In this unit, we present major formalisms for process diagramming in use today and the process aspects that each covers. Unit 3 is composed of several lectures, one for each diagramming method. Lecture a, Interpreting and Creating Process Diagrams: Introduction, provides an introduction to these concepts and reviews information from Unit 2, Lecture b. Based on feedback from practitioners, we recommend using two methods (data flow diagrams in Yourdon notation, and flowcharts). In Lecture a, we review the process aspects that each diagram type covers. In separate presentations, we cover each diagram type. For the two recommended methods, the presentation covers concepts and skills from reading and interpreting the diagrams to actually creating them. For the rest of the diagrams, we cover only background, use, and notation, i.e., the presentation prepares the student to read and interpret the diagram but not to create them. Slide 2 The objectives for this unit, Fundamentals of Health Workflow Process Analysis and Redesign: Interpreting and Creating Process Diagrams: Introduction are to: • Create a process flowchart for a health care system (or system component) using

appropriate ISO 5807 symbols and conventions, • Create context and data flow diagrams for a health care system (or system

component) using appropriate Yourdon symbols and conventions, • Choose the correct scope and detail level for a process flowchart and data flow

diagram, • Read and interpret Gane-Sarson data flow diagram, • Read and interpret an entity relationship diagram in crow’s foot notation, and • Read and interpret UML class, activity, and state diagrams.

Health IT Workforce Curriculum Fundamentals of Health Workflow Process Analysis and Redesign 2 Version 3.0/Spring 2012 Interpreting and Creating Process Diagrams: Introduction Lecture a This material Comp10_Unit3a was developed by Duke University, funded by the Department of Health and Human Services, Office

of the National Coordinator for Health Information Technology under Award Number IU24OC000024.

Slide 3 The topics covered in lecture a of unit 3 include: • Key process aspects that may require analysis and diagraming • Types of process diagrams In lecture a, these topics are combined into a framework that organizes process diagram types according to the process aspects that each type of diagram represents. Thus, lecture a serves as an introduction to the unit 3 material. Slide 4 There are different kinds of process diagrams. They differ in the aspects of processes they represent and in the notations, i.e., symbols and conventions, used for diagramming or mapping processes. The types of diagrams covered in unit 3 include:

• ISO 5807 information processing diagrams, the same symbols used for Flow Charting,

• Yourdon notation for data flow diagrams, • Gane-Sarson notation for data flow diagrams, • Unified Modeling Language (UML) that represents several different aspects of

processes, and • Entity relationship (E-R) diagrams that concentrate solely on information

content. In unit 3, we will review the process aspects that each diagram covers and show an example of each type of diagram. Lecture a of Unit 3 provides a brief introduction and overview to the material in the unit. Here we enumerate the process aspects, e.g., informational versus process steps, etc., that are covered by each diagram type. This brief introduction serves as a framework to help you organize the different diagraming notations according to which process aspects they cover. Later, this framework will serve as a reference when choosing which type of diagram best fits a process analysis & redesign need. Slide 5 The process aspects to be featured will determine the type of diagram to be used, i.e. the diagram that best represents the process aspects that you are interested in. The six important process aspects are: • Context • Process steps • Information flow • Information content • Information transformation • Sequence and other control



• Who or what role performs the step Unfortunately the words used to describe the process aspects have different connotations and even meanings in different disciplines. Briefly, by context, we mean how a system or process interacts with the rest of the world, e.g., a context diagram is used to view the system in the context in which it operates. Context diagrams show main system components and the ways in which the system interacts with things outside of the system, e.g., inputs and outputs. By process steps, we mean the physical and mental tasks or activities that are involved in a process. We separate diagraming these physical and mental steps from data flow. Here Data flow means the path through which data and information travel – data flow is the process from the data’s perspective. Process flow is usually the process from, for example, the patient or provider’s perspective. Information content refers to the pieces of data / information required for process or informational steps or decisions. Data and information transformation refers to manipulations performed on data, e.g., calculating age from a patient's date of birth and today’s date. Step sequence, flow control and state or status all refer to the order in which data or things move through a process, and the logic that controls that flow. And finally, roles refer to who or what performs the process steps. The following table in the next slide indicates which process aspects are covered by the notations/diagramming methods. Note: The health care setting in which you work may have standardized on one particular notation/method for their process representation. Further, health care facilities may have participated in quality improvement or software development efforts, in which case, there may be existing process diagrams that may be of use to you. So, while you may prefer a particular method and can select that method of use in this course, it is important to be aware of the major notations/methodologies, and to understand the basic uses and notation of each. Slide 6 This unit covers five notations that are commonly used to diagram processes: ISO 5807, Yourdon, Gane-Sarson, UML, and E-R diagrams. ISO 5807 can be used to represent process or data flow steps and their sequence and control, as well as information transformation and roles involved in the process. Yourdon data flow diagrams represent context, data flow steps, and information transformation. In Yourdon diagrams, information content is captured through text but not captured in structured form. Gane-Sarson represents the same process aspects as Yourdon with the addition of capturing flow control and state in text. Unified Modeling language, or UML, developed a few decades after and heavily influenced by the earlier methods was designed to represent important aspects of system functionality. The Entity-relationship diagram is designed to represent only information content.



Supplemental material for this unit will cover each of these five methodologies. Slide 7 Not all of the process aspects noted earlier are critical for clinical workflow analysis and process redesign. For our work here, we concentrate on the following: • Yourdon data flow diagrams – for Context diagrams • ISO 5807 Flowcharts - for Process steps, and step sequence and control as well as

roles performing steps Yourdon Context Diagrams and ISO 5807 Flowcharts are covered in this unit in lectures b and c. Detailed instructions are provided on how to create and use these diagrams. Some organizations use these diagrams while others use UML. From the examples received from the Regional Extension Centers and available on the AHRQ and clinical quality improvement websites, it appears that Flowcharts and context diagrams are the most common in health care workflow analysis and process redesign and, thus we concentrate on these diagrams here. Because you may encounter other notations, e.g., Gane-Sarson, UML, and logical data models (E-R diagrams) we provide exposure to those diagrams as well. Your instructor will pick and choose from the available material to best prepare you for local applications. Slide 8 The goal of workflow analysis and process redesign is to represent aspects of the process that help the analyst and health care facility staff identify areas where the process can be improved. The diagrams here meet this need by concentrating on process steps, data flow, roles, and visualizing the whole. There are other process aspects that are not critical to this analysis and thus will not be considered. Other efforts where the methods here have been used to successfully analyze and redesign health care processes include the Public Health Institute’s Business Process Analysis and Redesign program to improve the performance of the U. S. public health system The Public Health institute (PHI, 2006) reference provides great case studies and we recommend it.



Slide 9 Subsequent slide sets on this unit will cover the following top diagramming methods in detail: • Lecture b - ISO 5807 Flow Charting • Lecture c - Yourdon Data Flow Diagrams • Lecture d - Gane-Sarson • Lecture e - E-R diagram • Lecture f - Unified Modeling Language (UML) Slide 10 This concludes Lecture a, Interpreting and Creating Process Diagrams: Introduction. You should be able to: • Understand key process aspects that may need to be diagramed • Suggest a diagram type for a given process aspect to be represented Slide 11 No audio. End.

Audio

Transcript

WORKFLOW ANALYSIS


Unit 3 Interpreting and Creating Process Diagrams Lecture B Process Mapping: ISO 5807

Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: ISO 5807. This is Lecture b. The Component, Fundamentals of Health Workflow Process Analysis and Redesign, examines different diagramming methods for developing graphical representations of processes in health care settings. Throughout the last century, different diagrams and notations have arisen. There is considerable overlap between them. Some have fallen by the wayside and others remain in use. Some have become international standards, while others exist in textbooks and articles. In this unit, we present major formalisms for process diagramming in use today and the process aspects that each covers. Lecture b, Process Mapping: ISO 5807, covers creating flowchart style process diagrams and the associated standard symbols. This is the second of six lectures in the Process Mapping Unit. Slide 2 The objectives for this unit, Process Mapping: ISO 5807 are to: • Create a process flowchart for a health care system (or system component) using



diagram, • Read and interpret Gane-Sarson data flow diagram, • Read and interpret an entity relationship diagram in crow’s foot notation, and • Read and interpret UML class, activity, and state diagrams. Slide 3 In Unit 2 we introduced the concept of ISO 5807 flowcharting notation to diagram a process. In lecture b, Process Mapping ISO 5807, we will provide further details about the International Organization for Standardization (ISO) 5807 symbols and conventions. Lecture b also covers reading an ISO 5807 flowchart in terms of the information that could be generated and the workflow steps that are being communicated. And finally, lecture b prepares you to create ISO 5807 flowcharts for a health care system (or system component) using correct symbols and conventions.

Health IT Workforce Curriculum Fundamentals of Health Workflow Process Analysis and Redesign 2 Version 3.0/Spring 2012 Process Mapping: ISO 5807 Lecture b

This material Comp10_Unit3b was developed by Duke University, funded by the Department of Health and Human Services, Office


Importantly, most organizations use flowcharts in information technology and in quality improvement efforts. As a Practice Workflow and Information Management Redesign Specialist, you will see, need to interpret, and need to create flowcharts. Slide 4 Recall that each of the methods for diagramming a process has its own set of capabilities. With ISO 5807 flowcharts a process analyst is able to represent the process or data flow steps, any information transformations that occur or should occur, the order or sequence of the steps involved in the process, and the roles of the persons completing the steps in the process. The flowchart is a useful, and probably the most common tool in mapping the workflow processes in health care. Slide 5 A flowchart is a graphic depiction of the steps or activities that constitute a process. The International Organization for Standardization (ISO) defines flowchart as a “graphical representation of the definition, analysis, or method of a solution of a problem in which symbols are used to represent operations, data, flow, equipment, etc.” (ISO, 1985) The ISO 5807: 1985 standard defines symbols to be used in information processing documentation and gives guidance on conventions for their use in data flowcharts and other diagrams. Many organizations require the documentation of dataflow or process flow. Some organizations require a flowchart to accompany every Standard Operating Procedure (SOP). Organizations also use flowcharts to document and communicate the data flow or process flow for information technology and quality improvement projects. Slide 6 Flowcharts are constructed from standard symbols. It is important that standard symbols be used because flowcharts are used to communicate processes. When people see a specific symbol in a chart, they understand a specific meaning – like a road sign. Thus, to read, use, and create flowcharts, knowing the meaning of the standard symbols is important. The ISO 5807: 1985 specifies the standard flowchart symbols for information processing. Many software applications have flowcharting functionality. Some of these are Microsoft Word, Microsoft PowerPoint, and Visio. The functionality that is important in flowcharting programs includes the availability of standard shapes and “connectors” that latch to the shapes unless you specifically detach them. This allows you to reposition the shapes in the drawing canvas and facilitates editing the flowchart.




Slide 7 Reviewing from unit 2: The terminal symbol is a rounded rectangle which identifies the beginning or end of a process or origin and destination of data. The process symbol is a rectangle which designates an activity. Within the rectangle is a brief description of that activity. The decision symbol is a diamond which designates a decision point from which the process branches into two or more paths. The path taken depends on the answer to the question which appears within the diamond. Each path is labeled to correspond to an answer to the question. The document symbol is a human readable document pertinent to the process. The flow line represents a process path which connects process elements. The arrowhead indicates the direction of the flow. The connector is a circle which is used to indicate a continuation of the flow diagram. Slide 8 The Basic Process symbol “represents any kind of processing function, for example, executing a defined operation or group of operations resulting in a change in value, form or location of information, or in the determination of which one of several flow directions is to be followed.” (ISO, 1985) In this example, the basic process symbol represents the following: • Patient signs-in and checks-in with the front desk, • Receptionist enters the patient into the visit system as present and confirms the

insurance information with the patient • The nurse pulls the chart from the filing stacks and • Escorts the patient to the exam room. Slide 9 The decision, or diamond, symbol “represents a decision or switching type function having a single entry but where there may be a number of alternative exits, one and only one of which may be activated following the evaluation of conditions defined within the symbol. The appropriate results of the evaluation may be written adjacent to the lines representing the paths.” (ISO, 1985)




Decision symbols can show nominal decisions (yes or no), or decisions with multiple possible outcomes. In this example, the patient is given a drug susceptibility test and a decision is made as to the appropriate type of prescription to write based on the test results. Note that the actions are different for the patients who are susceptible and the patients who are not, thus, the decision symbol denotes a point at which, depending on the result of the decision, the process will proceed via different paths. Slide 10 This is an example of the Terminator symbol. The Terminator symbol “represents an exit to, or an entry from, the outside environment, for example, start or end of a program flow, external use and origin or destination of data.” (ISO, 1985) This symbol is described in section 9.4.2 of the ISO 5807 documentation. Here the Terminator symbol is used to represent the entry of the patient into the process (health care workflow setting). Slide 11 Examine the flowchart closely. Take a few minutes and list the symbols that are correctly and incorrectly used according to the flowchart symbols on the previous slide. Correct symbols are used for the decision boxes and the connectors. Incorrect symbol use is a matter of which notation one is following, and how formal or conformant to any one notation one wants to be, i.e., correctness with respect to notation is a relative matter. Comparing the flowchart on this slide to the list of symbols on the previous slides, i.e., according to the ISO 5807 standard, we see that the rounded-corner rectangle used as a terminator should be a different shape, one with parallel lines on the top and bottom and half-circle curvature on the left and right sides. The arrow heads should be shaded or filled in rather than open. Slide 12 The process flow diagrams can become quite complicated. The example in front of you is taken from a hospital setting where there are multiple decisions to be made and multiple actions based on these decisions. This complexity is found in most health care settings.




In this In-patient hospitalization example, we will walk through key decisions and actions as displayed in this slide.

1. A patient is admitted to the hospital and placed in an examination room • The Admission Summary is completed

2. Various observations per the hospital standards are obtained. : • Vital signs and temperature • Continuous 12-lead monitoring • Cardiac enzymes • Distal pulse • Noting of wounds, pain, and/or other symptoms • Presence of a hematoma or clotting time if there is bleeding

3. Medication is administered, and 4. Continuations of the medical assessment which will be determined by preliminary

findings. Examples are: • If there is chest pain, then collect duration of hospital stay related to chest

pain • If the patient displays oozing of hematoma, then evaluate for surgical repair of

puncture site and prepare for the Operation Room • If the patient is improving, then transfer to step-down facility and plan for the

patient to be discharged • If the patient is not improving, then manage medically by continuing various

observations per hospital standards and continuing medical assessments • If the patient has a planned Coronary Artery Bypass Graft (CABG) which is

expected, then prepare for the Operation Room • If the patient has complications from a procedure, either expected or

unexpected in this representation, the staff will prepare for the Operation Room.

5. Finally, a discharge summary will need to be prepared. Slide 13 “This symbol (a rectangle with the bottom long side is curved such that the left side is lower) represents human readable data, the medium being, for example, printed output, an OCR [optical character recognition] or MICR [magnetic ink character recognition] document, microfilm, tally roll, data entry forms.” (ISO, 1985) Here the staff member reviews the patient’s charts and files them. The documents in the patient chart, i.e., the patient chart, is represented by a document symbol.




Slide 14 According to ISO 5807 section 9.1.2.5, the symbol for manual input is a quadrilateral with two parallel sides, two 90 angles, one obtuse angle and one acute angle. “This symbol represents data, the medium being of any type where the information is entered manually at the time of processing, for example, on-line keyboard, switch settings, push buttons, light pen, bar-code wand.” (ISO, 1985) According to ISO 5807 section 9.2.2.2, the symbol for a manual operation is an isosceles trapezoid (a quadrilateral with two parallel sides and the sides that aren't parallel are equal in length and both angles coming from a parallel side are equal). “This symbol represents any process performed by a human being.” (ISO, 1985) Slide 15 In this example, the manual operation of receiving the forms and manual input of keyboard entry of data are represented. The example is as follows: Billing form arrives at the receptionist. Afterward, presumably the receptionist locates the patient in system and performs keyboard entry of the patient form. For this operation, the form for the patient visit appears on the screen. The standard claim form is an input to the process. Slide 16 According to ISO 5807 section 9.1.1.1, the symbol for Data is a parallelogram (opposite sides are parallel and equal in length, and opposite angles are equal). “This symbol represents data, the medium being unspecified” (ISO, 1985). According to ISO 5807 section 9.1.1.2, the symbol for stored data is a four-sided figure with two-parallel sides, one rounded concave end and one rounded convex end. “This symbol represents stored data in a form suitable for processing, the medium being unspecified” (ISO, 1985). Slide 17 Here is a Data Symbol example: The process starts with the logging of a Patient, presumably into a data system. Afterwards, two things occur in parallel: 1) a data record from a referring physician is sent to the database for storage, and 2) data is collected during the Patient visit. After the “during patient visit data collection” which presumably occurs on a paper form – signified by the manual process symbol, a data entry operator locates the Patient record




in the system. After which two things occur, 1) the entry form for Patient visit appears, and 2) keyboard entry of patient form followed by storage of the data in a database.

In this example data are represented in two distinct ways. Note that the generic data symbol is used for data from the referring physician. It does not specify medium, such as disc or electronic file transfer, however, because the data go directly to the database, it would be reasonable to infer electronic transfer. Use of the stored data symbol for the office database also signifies data; the symbol specifically indicates stored data. The vertical cylinder could also have been used. In flowchart creation for process analysis, the chart should be specific enough so that the assumptions signified in the example by the word presumably, and the assumption about the medium of data transfer are not required. Such assumptions should trigger the analyst to learn and diagram in more detail. Slide 18 The Display symbol “represents data, the medium being of any type where the information is displayed for human use, for example, video screens, on-line indicators.” (ISO, 1985)

The Display symbol is shaped like the traditional cathode ray tube (CRT) computer monitor viewed from the side. For people who have only used flat screens, the symbol shape is less intuitive. The flowchart example on the slide shows the following: • Patient arrives • Receptionist checks Patient in • Receptionist locates Patient in EHR • Form for Patient visit appears (on computer screen) • Keyboard entry of patient information Slide 19 According to ISO section 9.4.1, the symbol for a Connector is a circle with a number in it. “This symbol represents an exit to, or an entry from, another part of the same flowchart, and is used to break a line, and to continue it elsewhere. The corresponding connector symbols shall contain the same unique identification.” (ISO, 1985)




Example: Page 1 of flowchart: Presumably the patient is escorted to exam room, after which chief complaint & vitals are recorded. Next, the provider is notified that the Patient is ready. After the Notify provider Patient readyprocess box, the connector indicates for the reader to Go to the next page and start at the circle with a 1 in it. Continuing on page 2 of the diagram, the reader would start at the circle with a 2 in it, which directs the reader to the next process step, Examine Patient. This step in the process is followed by a decision, presumably made by the provider about whether or not an order is required. If an order is required, the process continues to the order writing step. Note that the connector with a 1 connects the process across pages one and two. Slide 20 The symbols used to represent a delay in a process are given here. The bullet, although not listed in ISO 5807, is commonly used because in logic diagrams, it represents an and gate. An and gate denotes that two or more things (thing 1-and-thing 2, two inputs) have to happen before proceeding. Two parallel lines are used to denote that things above them must be done before things below them can be done. In the diagram, adapted from the ISO 5807 standard, processes B and C cannot start until process A has been completed. (ISO, 1985) Slide 21 In this section, we will cover non-symbol conventions of flowcharting. These include use of text descriptions, indication of detail level, flow direction, and lines. These conventions are just as important as standard symbols. Not using them leaves the impression that the analyst is not familiar with the standards. Slide 22 It is often important to include text descriptions in a process representation. This is done using annotationsaka call-outs. This keeps the text in the box to a minimum so the chart is more readable. Lengthy text descriptions can be referenced to another page or footnote if necessary. If text descriptions refer to more than one box in a flowchart, a dotted line can be drawn around the steps that the text describes or refers to.




Slide 23 While flowcharts can be used to represent different levels of process detail, items shown on the same diagram should be at the same detail level. The example flowchart at the top shows the main components of the research data collection process at the same detail level; a high-level view of the research data collection process. The bottom diagram is an example of combining items at different detail levels on the same diagram. Note the different level of detail in the bottom flowchart which includes the data processing steps. This would be better in a second flowchart. Combining items at different detail levels can cause confusion. Slide 24 Flowcharts should “read” from top to bottom or right to left. Affirmative responses to yes or no decisions should all be in the same direction. Flow direction for process steps that show re-work (i.e. queries for data discrepancies going back to a data sender) should be opposite of the direction of the progressing process. In the incorrect example on the left of the slide, arrows denoting forward process progress are diagrammed in two different directions. When possible all forward process progress should be in the same direction. The preferred way to diagram this process is shown on the right. Slide 25 Flowcharts should read from top to bottom or left an right. Lines should run up & down or left and right. Do not use diagonal lines. An “incorrect diagram is shown on the left. The preferred way to diagram the process is shown on the right. Note this is left and right; not left to right. Slide 26 There are multiple ways to connect process and data flow. A solid line is used to denote data or process flow. Arrows represent the direction of the flow. A dashed line is used to denote an alternate path. Arrows represent the direction of the flow. A jagged line is used to denote data transfer by a telecommunications link. Arrows represent the direction of the flow. Two parallel lines denote a synchronization between two parallel processes. i.e. that the things above it have to happen and all come to the denoted state before the things below it can occur. There are no arrows on synchronization lines. All lines that represent flow based on decisions should be labeled. Lines should run up & down or left and right. Do not use diagonal lines.




Slide 27 This concludes Lecture b of Process Mapping: ISO 5807. After completing lecture b, you should be able to: • Recognize and use ISO 5807 standard symbols and conventions, • Read and interpret an ISO 5807 flowchart, and • Create ISO 5807 flowcharts for a health care system (or a system component) using

correct symbols and conventions. Slide 28 No audio. Slide 29 No audio. End.

Audio

Transcript

WORKFLOW ANALYSIS


Unit 3 Interpreting and Creating Process Diagrams Lecture C Process Mapping Yourdon Notation for Data Flow

Diagrams Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Yourdon Notation for Data Flow Diagrams. This is Lecture c. The Component, Fundamentals of Health Workflow Process Analysis and Redesign, examines different diagramming methods for developing graphical representations of processes in health care settings. Throughout the last century, different diagrams and notations have arisen. There is considerable overlap between them. Some have fallen by the wayside and others remain in use. Some have become international standards, while others exist in textbooks and articles. In this unit, we present major formalisms for process diagramming in use today and the process aspects that each covers. Lecture c, Process Mapping: Yourdon Notation for Data Flow Diagrams, covers Yourdon notation for data flow diagrams. Slide 2 The objectives for this unit, Process Mapping: Yourdon Notation for Data Flow Diagrams, are to: • Create a process flowchart for a health care system (or system component) using



diagram, • Read and interpret Gane-Sarson data flow diagram, • Read and interpret an entity relationship diagram in crow’s foot notation, and • Read and interpret UML class, activity, and state diagrams. Slide 3 The topics covered in Lecture c are: • Recognize and interpret Yourdon data flow diagram symbols and conventions, and • Create data flow diagrams (DFDs) for health care scenarios. Slide 4

Health IT Workforce Curriculum Fundamentals of Health Workflow Process Analysis and Redesign 2 Version 3.0/Spring 2012 Process Mapping: Yourdon Notation for Data Flow Diagrams Lecture c This material Comp10_Unit3c was developed by Duke University, funded by the Department of Health and Human Services, Office


Data flow diagrams provide a way to document and visualize the movement of data through a process. As such, they document several aspects of processes that analysts and process designers are interested in. There are multiple notations for data flow diagrams, including ISO 5807 flowcharts, Yourdon notation and Gane-Sarson notation. We will only cover Yourdon notation for data flow diagrams in lecture c. Yourdon notation was introduced in Edward Yourdon’s 1989 book Modern Structured Analysis. (Yourdon, 2006). Yourdon notation exists for three types of diagrams 1) data flow diagrams, 2) state transition diagrams, and 3) entity-relationship diagrams. (These are different from the entity-relationship diagrams that are logical relational data models covered in lecture e.) The most commonly used Yourdon diagram in health care is the data flow diagram. Slide 5 Each of the methods for diagramming a process introduced in lecture a covers certain aspects of processes. Recall that Yourdon data flow diagrams, also known as DFDs, can represent the high-level context in which a process operates, i.e., interfaces between a system and the rest of the world. Data Flow Diagrams (DFDs) can also be used to illustrate the details of entities from and to which data are received or sent, process steps, i.e., data or information transformations that occur, and data movement between entities & processes, processes and processes, and processes and data stores. Data flow diagrams do not represent information content, roles, or the logic of flow control (sequence of processes or flow can be indicated as we will see). Here we note data flow diagrams as representing data flow steps and not process steps. This is somewhat artificial; as Yourdon describes in his 2006 revision of Just Enough Structured Analysis, the data flow diagrams can be used to diagram processes. Doing so requires using flows to represent physical things such as materials or supplies and the process symbols represent operations on the materials rather than on data. (Yourdon, 2006) However, we describe DFDs as just representing data flow steps rather than process steps.



Slide 6 We will cover two uses of data flow diagrams in this presentation: 1) a high-level version that is called a context diagram, and 2) more detailed versions called data flow diagrams. Both context diagrams and DFDs use the same notation, the only difference is that the context diagram is the 50,000 foot bird’s-eye view rather than the details. At the highest detail level, the context diagram represents an entire system as a single process and highlights the interfaces between the system and the outside world. Thus, context diagrams are helpful to document and share knowledge about what is included in a process (the scope).

Slide 7 A context diagram (shown on the slide) is the highest level (i.e., least detail) DFD. The context diagram depicts the system or process you are modeling as one process, here private practice patient care. Entities that interact with that process are shown, here patients, payers, pharmacies, etc., as are the data stores (the EMR and an ePrescription data store), and the data flow among the entities, processes and data stores. Context diagrams are very helpful in making sure that our analysis is complete and that interactions with external entities are not forgotten. Slide 8 The example data flow diagram on this slide shows the data movement and transformations as a patient goes through the entire visit process. This begins with the reception/intake process where the intake data are entered or written to the administrative database that will be used for billing. After intake, the medical office assistant is given the room assignment. In the examination room the provider assesses the patient, charts clinical data and generates orders for further processes. The orders and clinical data are stored in the EHR. The EHR data are then used in the billing process to generate the claim for financial reimbursement (from the payer). Slide 9 Entities are origins or consumers of data (also called terminators), they are typically individuals, groups of people (for example, another department or division within the organization), external computer systems, and external organizations. Entities are referred to as external entities, because they are outside the process being analyzed, i.e., not changeable. For example in the previous diagram, the patient is not part of the receptionist’s intake process, but the patient’s information is an input to the process. Processes are shown by the circles, or bubbles,in the diagram. They represent the various individual functions or transformations that the system carries out, that is, actions or work performed on data that change them in some way, i.e., take inputs and



creates different outputs (input allergies and drug order and output an allergic alert or drug-drug interaction alert). Flows are shown by curved, directional arrows. They are the connections between the processes (system functions), and they represent the information moving between processes as input and/or the information they generate as output. Yourdon refers to flows as “data in motion”. (Yourdon, 2006) Data stores represent “data at rest”. (Yourdon, 2006) They are shown by two parallel lines with a closed end and opposing open end. This is essentially a rectangle with one of the vertical lines missing. They show collections of data that the system must remember for a period of time. When the systems designers and programmers finish building the system, the stores will typically exist as files or databases. Yourdon published several books and papers with different people. Variations of this notation exist. We chose one here and use it consistently. Slide 10 Entities represent people, organizations, or other things that interact with the system, i.e. entities are outside of the system, they may, of course, be part of a larger workflow process, but they are EXTERNAL to the information system processing the data. Entities send or consume information, and are also called sources or sinks of information. Data flows can come to and from entities ONLY from processes. This is because entities are used to represent sources or consumers of information that are NOT a part of the system being analyzed; if flow between entities, for example, were represented on the diagrams, then that would imply that they were PART of the system being analyzed. As such, data flows to and from entities represent system interfaces (a very important thing to show). Slide 11 A Process should be named or described with a single word, phrase, or simple sentence that describes what the process does. A good name consists of a verb-object phrase such as assessment or assess patient. In some cases, the process will contain the name of a person, group of people, computer, or mechanical device. That is, the process sometimes describes who or what is carrying out the process, rather than describing what the process is.



Slide 12 The process Flow is represented by curved arrows. Arrow heads on the flow indicate the direction of the movement of data, i.e., whether the data are moving into or out of a process or both. The name of the process represents the meaning of the data that moves along the flow. Importantly, the same content may have a different meaning in different parts of the system. For example, the address as given by a patient versus the address that has been matched and validated. Slide 13 The Data Store represents a collection of data at rest. It should be named with a noun or noun phrase, and can be computerized or non-computerized, such as paper charts. Data stores are passive, i.e., processes put data in or read data out of the data store.

• Arrows to data stores mean write, update, or delete data into the data store. • Arrows from data stores mean read, retrieve, or use data from the data store.

Data flows to data stores cannot come from other data stores or from entities. As previously mentioned, a data store resembles a rectangle lacking one of the vertical lines. Slide 14 In Yourdon notation, an event list accompanies a data flow diagram. An event list contains things that stimulate action from the system. For example, for prescribing:

• a patient calls for a re-fill, • a pharmacy calls for a re-fill, or • a patient presents with a problem requiring medication.

Slide 15 Yourdan notation conventions are important. The analyst should choose meaningful names for all processes, flows, stores, and terminators. Also, number the processes by placing a unique number in the circle at the top. You should redraw the DFD as many times as necessary until it is clear and complete and simplify the DFDs as much as possible.



A good DFD fits on one page and is not too crowded. If additional details are needed, processes can be exploded on a new page. Everything on one page should be at the same detail level. Slide 16 Style matters in Yourdon notation and can be used by the analyst to provide additional meaning to DFDs. The size and shape of bubbles are up to the diagram creator and their client. Curved or straight arrows can be used. A diagram looks neater with one or the other but not both in the same process. There is no excuse for hand-drawn diagrams today except during a white-boarding stage. The analyst may choose to name the processes for the role that they perform, as well as use colors to differentiate the types of entities or flows in the diagrams. With all of these style options the DFDs can provide as much or as little detail as is needed to appropriately represent the process for the given audience. Slide 17 Beware of the following potential flaws in your process diagrams: Black holes as Yourdon calls them, are processes that have inputs but no outputs. Miracles are processes that have outputs but no inputs. Mysteries are unlabeled flows and unlabeled processes. Slide 18 We encourage the analyst to represent processes with leveled diagrams where necessary in order to have a diagram that is readily understood and can be provided at the appropriate level of detail for the audience. Start with higher level (context) diagrams to understand the scope and boundaries. These may be used for discussions with leadership in the health care setting. Then decompose the processes to lower levels of detail when needed. Remember the ultimate goal is an optimized clinic process, not a large detailed set of diagrams.



Slide 19 Remember the guidance from Edward Yourdan’s 1989 work, Just Enough Structured Analysis. I quote: “…even if our job were to ‘design the world,’ we would have to recognize that the world is only a part of the solar system, which is part of a small, obscure galaxy, which is (ultimately) part of the universe.” “…the first major model that you must develop as a systems analyst is one that does nothing more than define the interfaces between the system and the rest of the universe, that is, the environment.”

Slide 20 There have been several variations on Yourdon notation. Two of these are: Yourdon-Code and Yourdon-DeMarco. Yourdon concepts and notation have been adapted to suit the needs of individual projects. Yourdon notation for data flow diagrams has been adapted for health care process analysis and redesign by the Public Health Informatics Institute (PHII) in their recent Common Ground Initiative, and by the Agency for Healthcare Research and Quality (AHRQ) funded initiatives (Yourdon, 2006). Yourdon himself makes the point that the actual shape chosen is not important as long as the analyst uses the shape to consistently represent the same meaning. (Yourdon, 2006) Slide 21 This DFD uses one shape and does not distinguish between process, entity and data store. In Yourdon parlance, because it is high-level, it would be called a context diagram – even though it takes a notational liberty in differentiating the types of flows. Importantly, the diagram met the need for software selection and process re-design in many public health departments. The moral is, take what is useful and do not carry extra baggage. Slide 22 Without looking at the next slide, draw a one-page DFD for a prescription refill process at a primary care provider based on the following scenario: Mrs. Jones takes Benecar 20mg QD for blood pressure control. She has taken this medicine for two years with good results. She does not use the auto refill program at her local pharmacy. Today, she called her provider, who does not use e-prescribing, and asked if the prescription could be called in to her pharmacy.



Slide 23 This example prescription refill context diagram shows the process steps and people required to refill a prescription without using a pharmacy auto-refill program or e-Prescribing through the provider. Slide 24 Yourdon notation is a set of symbols and conventions named for the person who developed it, Edward Yourdon. Yourdon notation has not been adopted as a standard. As such, there is no formal maintenance organization. Individuals use and adapt it to suit their needs. For an adaptation to still be a context diagram, it must show entities, processes and interactions. Slide 25 This concludes Lecture c, Process Mapping: Yourdon Notation for Data Flow Diagrams. After completion of this lecture, you should be able to: • Explain two ways process diagrams are used as models, • Distinguish the physical steps from information flow in a health care process

involving an EHR, and • Choose an appropriate process diagram to model given aspects of a process. Slide 26 No audio. End.

Audio

Transcript

WORKFLOW ANALYSIS


Unit 3 Interpreting and Creating Process Diagrams Lecture D Process Mapping Gane-Sarson Notation

Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Gane-Sarson Notation. This is Lecture d. The Component Fundamentals of Health Workflow Process Analysis and Redesign, examines different diagramming methods for developing graphical representations of processes in health care settings. Throughout the last century, different diagrams and notations have arisen. There is considerable overlap between them. Some have fallen by the wayside and others remain in use. Some have become international standards, while others exist in textbooks and articles. In this unit, we present major formalisms for process diagramming in use today and the process aspects that each covers. Lecture d, Process Mapping: Gane-Sarson Notation, covers Gane-Sarson notation for data flow diagrams. Slide 2 The objectives for this unit, Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Gane-Sarson Notation are to: • Create a process flowchart for a health care system (or system component) using



diagram, • Read and interpret Gane-Sarson data flow diagrams, • Read and interpret an entity relationship diagram in crow’s foot notation, and • Read and interpret UML class, activity, and state diagrams. Slide 3 Lecture d provides details about Gane-Sarson notation for data flow diagrams. We describe the Gane-Sarson symbols and conventions for process mapping. Lecture d does not cover other parts of Gane-Sarson notation, and is not meant to teach you how to draw the diagrams, only to understand and interpret them in case you encounter them in practice. Slide 4

Health IT Workforce Curriculum Fundamentals of Health Workflow Process Analysis and Redesign 2 Version 3.0/Spring 2012 Process Mapping: Gane-Sarson Notation Lecture d This material Comp10_Unit3d was developed by Duke University, funded by the Department of Health and Human Services, Office


Each of the methods for diagramming a process has its own set of capabilities. Gane-Sarson represents the process context (that is, the process or system boundaries, interactions with the outside world, and the major functions). It also represents information content, the order or sequence of the data flow steps involved in the process, the transformations that occur or should occur, and the roles that perform the processes. While Gane and Sarson recognized the importance of representing information content and flow control, they did so through text data dictionaries (lists of the data elements) and structured if-then type statements. Since these are not graphic representations, we will not cover them here. Gane and Sarson represented context, data flow and data transformation through one diagram type, the Data Flow Diagram (DFD). Their approach used a high-level DFD to show context, and a more detailed (or series of more detailed) diagrams to show data flow steps. Data transformation is represented on the DFD by a process symbol that indicates that data transformation occurs. Then the actual transformation is specified using text. Slide 5 Gane-Sarson notation was introduced in Chris Gane and Trish Sarson’s 1977 book, Structured Systems Analysis: Tools and Techniques. The book was later published in 1979 by Prentice-Hall. (Gane and Sarson, 1979) Gane-Sarson notation is used for data flow diagrams. Although we have not seen Gane-Sarson notation used in health care, process analysts might encounter Gane-Sarson style diagrams, thus, we provide introductory-level information to the notation. Slide 6 Gane-Sarson notation is specific to data flow diagrams which show the movement, transformation and storage of data. Slide 7 This is an example of a simplified on-line appointment scheduling Gane-Sarson diagram. The diagram describes a data flow where a patient enters a web inquiry which generates two checks against different databases. After which, the information including an option to accept or decline the appointment is returned to the patient for acceptance. Slide 8 Gane-Sarson data flow diagram notation uses these four symbols:



Entities show the people, roles, organizations or other things with which the system communicates, i.e., sources or consumers of data. Processes are shown by square rectangles with rounded corners. They represent data processes, i.e., the various individual functions that the system carries out to transform data inputs into outputs. Process boxes can be numbered to show the sequence in which they are carried out. Flows are shown by straight arrows. They are the connections between the entities, processes, and data stores. They represent the information that the processes require as input and the information they generate as output. Data stores are shown by an open-ended long rectangle. They represent collections of data that the system must access (read from or write to) or remember for some period of time. Data stores typically exist as files or databases. Slide 9 Entities represent people, organizations, or other things that interact with the system, i.e. entities are outside of the system, that is they are part of a process, but external to the information system. Entities send or consume information, and in Gane-Sarson notation are also called sources or sinks of information. If the same entity is shown more than once in a diagram, a diagonal line is added to the lower right-hand corner to visually distinguish it. For example, if the nurse entity was drawn twice, to keep from having a lot of criss-crossing lines on the diagram, a single diagonal line would be added to the lower right-hand corner. Further, if a medical assistant entity was similarly drawn twice on the same diagram, two diagonal lines would be added to visually distinguish it from the nurse and patient entities. Slide 10 Processes transform data. The process should be named or described by a single word (a verb), phrase, or simple sentence that describes what the process does. Similar to other notations, a good name will generally consist of a verb-object phrase such as check availability.



In some cases, the processes are named for a role, an organization, or a machine that performs the process. Processes are given a number in the upper right-hand corner; this is an identifier and does not imply sequence. Optionally, processes can also have a lower section, similar in appearance to the process identifier part at the top, in which the role or machine that accomplishes the process, or the physical location of the process is undertaken. Slide 11 Similar to ISO 5807, Gane-Sarson notation uses straight arrows. Arrows should be named to indicate the meaning of the data that moves along the flow that is, a noun. Data flows with a verb name are incorrect; they signify a process that has been omitted. Data flow in and out of a process must be altered in some way, i.e., not labeled the same thing. A flow can:

Represent only one type of data, e.g., request or reply, or Consolidate several elementary dataflows into one flow, e.g., request and reply. This is dependent on the intended detail-level of the diagram.

The same content may have a different meaning in different parts of the system, for example, address (as input by the receptionist) versus address after validation with the directory. Arrows indicate direction of the data flow, for example, from the practice EMR to the pharmacy. Slide 12 The data store is used to model a collection of data at rest. Data stores can be in computerized or non-computerized form, such as paper charts, microfiche, index cards, etc. Stores are passive; processes put data in or read data. Like processes, data stores can be given an identifying number, e.g., D1, D2, etc., where D denotes a data store and the number serves as a unique identifier. Like entities, data stores can be drawn more than once on a diagram to avoid crisscrossed lines; in this case, a vertical line is added to the closed end of the data store shape.



Slide 13 Unlike Yourdon notation, Gane-Sarson does not use an event list to indicate things that stimulate action from the system. Things that stimulate action from a system are indicated by entities. Slide 14 Gane-Sarson, like Yourdon notation, uses leveled diagrams, that is, a roll-up and drill-down approach where increasing levels of detail are shown on successive diagrams. A process called functional decomposition is used to represent each process in more detailed steps / processes. Each process in a DFD can be exploded, i.e., redrawn to show increasing levels of detail. When this is done, decimal numbers can be used to identify the lower detail level process, while maintaining the links to the parent or higher level process on the parent diagram. Context diagram is the highest level. There are as many lower-levels as needed. Slide 15 Gane-Sarson Conventions include:

• Choosing meaningful names for processes, flows, stores, and terminators, • Numbering the processes and data stores, • Making sure the DFD is internally consistent and consistent with any

associated DFDs, and • Exceptions and error handling are shown on lower-level diagrams.

Slide 16 The size of the shapes should be consistent throughout the diagram. Keeping the size of the boxes consistent means that a short enough process name needs to be found so that it fits in the box, or that the name may be abbreviated. We found no guidance on the use of color shading for shapes or arrows, and expect that since the notation was developed in the 1970’s, that color was not commonly used on the diagrams. However, today, color may be used to visually show different types of entities, processes, data stores or flows. Arrows in Gane-Sarson are straight, and horizontal or vertical i.e., no diagonal or curved arrow lines. Double headed arrows can be used instead of two separate arrows in opposite directions, such as to represent request and reply.



Slide 17 Hopkins enumerated Rules for Correctness for these diagrams (Hopkins, 2006). These rules can be used to assess the logical consistency of the diagrams and include: • Entities may not send data directly to other entities, • Entities may not send data directly to data stores (data must be processed in some

way first), and • Entities may not get data directly from data stores (data must be processed in some

way first). Information is neither created nor destroyed; it must come from and go to somewhere. Information comes from and goes to entities and data stores via processes. Watch for spontaneous data creation and black holes. Note: in-only data stores may be ok, as when being read by another system. Also out-only data stores may be ok, as when getting data from another system. Data flows with a verb name signify a process that has been omitted. Slide 18 Like Yourdon notation, Gane-Sarson is a set of symbols and conventions named for the people who developed it. Gane-Sarson notation has not been adopted as a standard. As such, there is no formal maintenance organization. Individuals use and adapt it to suit their needs. Slide 19 This concludes Lecture d, Process Mapping: Gane-Sarson Notation. After completing Lecture d you should be able to: • Understand Gane-Sarson symbols and conventions for data flow diagrams, and • Be able to read and interpret data flow diagrams that use Gane-Sarson notation. Slide 20 No audio. End.

Audio

Transcript

WORKFLOW ANALYSIS


Unit 3 Interpreting and Creating Process Diagrams Lecture E Process Mapping UML notation for Data Flow and Related

Diagrams Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Entity-Relationship Diagrams. This is Lecture e. The Component Fundamentals of Health Workflow Process Analysis and Redesign examines different diagramming methods for developing graphical representations of processes in the health care settings. Throughout the last century, different diagrams and notations have arisen. There is considerable overlap between them. Some have fallen by the wayside and others remain in use. Some have become international standards, while others exist in textbooks and articles. In this unit, we present major formalisms for process diagramming in use today and the process aspects that each covers. Lecture e, Process Mapping: Entity-Relationship Diagrams, includes the background and development of entity-relationship diagrams (ERDs), the process aspects that are covered by ERDs, how ERDs are used, the symbol set, and notation conventions. This lecture also covers how to read an ERD (rather than how to create one). Slide 2 The objectives for this unit, Process Mapping: Entity-Relationship Diagrams are to: • Create a process flowchart for a health care system (or system component) using



diagram, • Read and interpret Gane-Sarson data flow diagrams, • Read and interpret an entity relationship diagram in crow’s foot notation, and • Read and interpret UML class, activity, and state diagrams.

Health IT Workforce Curriculum Fundamentals of Health Workflow Process Analysis and Redesign 2 Version 3.0/Spring 2012 Entity-Relationship Diagrams Lecture e This material Comp10_Unit3e was developed by Duke University, funded by the Department of Health and Human Services, Office


Slide 3 After lecture e, you should be able to: • Understand the background of how Entity-Relationship Diagrams (ERDs) are used

and maintained, the symbol set used in producing ERDs, and process aspects covered by them,

• Understand the notation conventions and be able to read (not create) a simple ERD. Slide 4 Entity-relationship diagrams are also called E-R diagrams and ERDs. The concept for ERDs was introduced in the 1976 paper by Peter Chen (Chen, 1976) just seven years after E.F. Codd (Codd, 1969) published his seminal work defining the relational model of data. Chen’s notation provided a way to graphically show relationships between data values, thus, it is best described as a data model. More specifically a logical data model because it describes how the data are related, not the physical locations of the data values within computer memory or how they are stored in a database. Logical data models (referred to as just data models for the rest of the presentation) are used to represent or document the data that are needed, collected, stored or otherwise used for some business need or needs. A data model is a description of the data rather than how the data are used or how the data move through a system. Thus, such descriptions are called “static” models, or models of information content. Descriptions of how data moves through a system would be called “dynamic” or “behavioral” data models. ERDs and, for that matter, static data models in general were not designed to, and in fact cannot model process steps, step sequence, or flow control. Static data models convey “just the data.” ERDs are used in projects where the data content for a system needs to be documented. Slide 5 As a workflow analyst, you will most likely not be creating ERDs. However, you may run into them as either documentation provided by a prospective vendor that documents the data that their system stores, or documentation that a health care facility has for an existing system. ERDs are based on the relational data model (Codd, 1969). Briefly, the relational data model describes fundamental ways in which data values may be related to each other, and as such, guides the design of a relational database in such a way as to keep those relationships intact. Full appreciation of the information conveyed on an ERD requires knowledge of the relational data model. IMPORTANTLY: this course does not require knowledge of the relational data model or of databases built based on the relational model. Most



community colleges and universities have courses on relational databases and relational database management that cover the relational data model in depth. Lecture e covers reading and interpreting ERDs, not how to create them. Slide 6 ERDs are similar to Unified Modeling Language (UML) class diagrams; they are both static data models. ERDs pre-date the development of the UML standard by over a decade, and the influence of ERD notation and methodology on UML class diagrams is quite visible. Although class diagrams represent additional relationships that ERDs do not, they both can represent multiple levels of abstraction, and the incorporation of hierarchy where the lower level classes “inherit” attributes from higher level classes. This is referred to as inheritance. Class diagrams can be used to show individual pieces of data and their attributes and relationships. If just this data content is needed, ERDs are equivalent to UML class diagrams. Class diagrams are covered in a separate lecture. Slide 7 To summarize the important points so far, ERDs are used to specify or document static content, i.e., data that are, or are to be stored in a data system. As such, ERDs are often used as the starting point in the design of relational databases. ERDs are included in this unit because data and information are used, collected and stored in many work processes, especially those in information intensive settings such as health care. Data are a part of health care workflow and need to be considered and understood along with the workflow steps. Thus, the workflow analysis and process redesign specialist may encounter ERDs. Further, the workflow analysis and process redesign specialist will need to know when data are important to a clinical workflow and when to take these data into account as part of process redesign. Slide 8 Several notations exist for drawing ERDs; the most common is Barker or “crow’s foot” notation. “Crow’s foot” notation is favored over the original Chen style of ERD modeling because of its readability and more efficient use of drawing space. Data model diagrams provided by software vendors often use crow’s foot notation. We will cover only crow’s foot notation in this lecture.



Slide 9 We collect and store data about things in the real world. When these data values have meaning, i.e., definition, context such as what the value is about, when it was collected, etc., we call the data information. Often the meaning is assumed and the word data is used interchangeably with the word information. Nonetheless, data models including ERDs represent three things 1) entities or things about which we collect data, e.g., cars, people, organizations, 2) relationships between the data values, for example, a person can have no cars, one car, or many cars, and 3) attributes, or the data that we collect about the entities. For example, we may be interested in the make and model of a car, or the name and address about a person. Make, model, name and address are considered attributes of the entities cars and people. Slide 10 An ERD looks like this. There is only one type of E-R diagram, a data model. The ERD in the example describes the data that might be used to manage courses and student registration. A data system for managing student course registration would need data about courses, instructors, course sections, course seats, and students; these are entities. The course registration management process might require course name, number, and credit hours; these are attributes. The course registration management process might also require instructor name, number, and department; these are also attributes. In ERD notation, the entity name appears in the top of the box. The attributes are listed in the box below the name. The lines connecting the boxes convey information about the relationships between the data. These relationships may be a model of reality, or may document constraints or business rules required by a process or data system. The statement “every student must have a student ID” is one such constraint that may or may not reflect reality. Slide 11 In ERD crow’s foot notation, an entity is represented by a two-part box, i.e., the top section that holds the entity name AND the bottom section where the attributes are listed. An entity has a name, attributes, and an identifier that uniquely identifies instances of the entity. Unique identifiers are similar to social security numbers; each number is distinct and is assigned to one and only one person. Thus if we had a list of 12 social security numbers, we could be assured that the list represented 12 different people. An attribute that acts as the unique identifier is added to the entity or selected from the attributes that meet the all important criteria of being capable of serving as a unique identifier. Sometimes on an ERD you may see boxes that have an entity name but no attributes. This is done on draft diagrams as a place holder to show that information about the entity is needed but has not yet been specified. For the Course entity shown on the slide, a database would store the course name, number and credit hours. IMPORTANTLY: the Course entity box signifies that the



database holds data values about courses. Each ACTUAL course for which data exist is called an instance of the course entity. If there were a person entity, you and I would be considered instances because we are real and exist. The generic entity, person, or course on the slide, are called universals because they represent the existence of instances. Slide 12 Relationships between instances of two entities are represented by a line. Relationships have a name which is a verb. ERDs only show a few types of relationships (UML class diagrams are capable of representing additional types of relationships). The types of relationships represented are 1) the existence of a relationship, denoted by the presence of a line between two entities, and 2) the maximum and minimum number of times an instance (actual occurrence) in one entity can be associated with instances in an entity with which it has a relationship. These maximum and minimum numbers are called cardinality and modality respectively. These are the ONLY types of relationships represented in data models. Slide 13 Cardinality and Modality work together to define the relationship. Cardinality indicates the maximum number of times an instance in one entity can be associated with instances in the related entity. Modality indicates the minimum number of times an instance in one entity can be associated with an instance in the related entity. Thus, Modality is also called participation because it denotes whether or not an instance of an entity MUST participate in the relationship. Cardinality and Modality are both shown on the relationship line by symbols. We will go over each of the symbols and how to interpret them. Slide 14 Cardinality indicates the maximum number of times an instance of one entity can be associated with instances in the related entity. Cardinality can have the values of one or many, no more detail than that. It is either one or more than one. On the relationship line, the cardinality is the closest to the entity box. The cardinality symbol in the diagram on the slide is in the red circle. Cardinality is indicated on BOTH ends of the relationship line, so there is a left to right cardinality and a right to left cardinality.



Slide 15 Modality indicates the minimum number of times an instance in one entity can be associated with an instance in the related entity. Modality can have the values of zero or one; two or three are not allowed. The modality symbol is located next to the cardinality symbol, on the inside of, i.e., NOT next to the entity box. A modality of one is denoted by a straight vertical line and a modality of zero is denoted by a circle. Like cardinality, modality is indicated at both ends of the relationship. Slide 16 Once you have the three symbols (zero-circle, one-vertical line, and many-crow’s foot) committed to memory, reading them is easy. Let’s go over them starting from the top of the slide. Modality zero and cardinality of many means that instances of the entity on the left of the relation can have or be associated with from zero to many instances of the entity on the right. Modality one and cardinality many similarly means that instances of the entity on the left of the relation can have or be associated with from one to many instances of the entity on the right. Modality one and cardinality one means that instances of the entity on the left of the relation can have or be associated with one and only one instance of the entity on the right. Modality of zero and cardinality of one means that instances of the entity on the left of the relation can have or be associated with from zero to one instances of the entity on the right. Remember, cardinality and modality specify a range. Slide 17 On an ERD, modality and cardinality look like the examples in the slide. Remember that these are shown on both sides of a relationship, thus, there is a left-to-right AND a right-to-left reading direction! Pause the slides and read through each of the examples. The “Seat fills Student” example shows:

Left to right: a seat is filled by exactly one student; Right to left: a student fills exactly one seat.

The “Student has Transcript” example shows:

Left to right: a student has one or more transcripts; Right to left: a transcript has one student.

The “Student Registers for Course” example shows:

Left to right: a student registers for one or more courses; Right to left: a course is registered by one or more students.



The “Instructor teaches Course” example shows: Left to right: an instructor teaches zero to many courses; Right to left: a course is taught by exactly one instructor.

Slide 18 When people talk about relationships between entities, they use phrases like one-to-one, many-to-one, or many-to-many. When people refer to the relationships in this way, they are calling out the cardinality (maximum number allowed) only, i.e., not mentioning modality (the minimum). Pause the slide and read through the relationships for each example. Note that cardinality is used in both directions. In these examples the digit ‘1’ denotes ‘One’; the letter ‘M’ denotes “’Many’. The “Seat fills Student” example shows:

Left to right: one to one, 1:1; Right to left: one to one, 1:1.

The “Student has Transcript” example shows:

Left to right: one to many, 1:M; Right to left: many to one, M:1.

The “Student Registers for Course” example shows:

Left to right: many to many, M:M; Right to left: many to many, M:M.

The “Instructor teaches Course” example shows:

Left to right: one to many, 1:M; Right to left: many to one, M:1.



Slide 19 Because the x-to-x way of referring to relationships does not account for the modality, there are four different ways that a Many-to-One relationship can occur based on different combinations of modality. The four varieties of a Many-to-One relationship are shown on the slide. • one through many notation on one side of a relationship and a one and only one, • zero through many notation on one side of a relationship and a one and only one, • one through many notation on one side of a relationship and a zero or one notation

on the other, and • zero through many notation on one side of a relationship and a zero or one notation

on the other. Slide 20 Similarly, because the x-to-x way of referring to relationships does not account for the modality, there are three different ways that Many-to-Many relationships can occur based on different combinations of modality. The three varieties of Many-to-Many relationships are shown on the slide.

• a zero through many on both sides of a relationship, • a one through many on both sides of a relationship, and • a zero through many on one side and a one through many on the other.

Slide 21 And finally, because the x-to-x way of referring to relationships does not account for the modality, there are two different ways that a One-to-One relationship can occur based on different combinations of modality. The two varieties of a One-to-One relationship are shown on the slide.

• A one and only one notation on one side of a relationship and a zero or one on the other, and

• A one and only one notation on both sides. Slide 22 We will use this ERD example in the following slides. A doctor can be scheduled for many appointments, but may not have any scheduled at all. Each appointment is scheduled with exactly 1 doctor. A patient can schedule 1 or more appointments. One appointment is scheduled with exactly 1 patient. An appointment must generate exactly 1 bill, a bill is generated by only 1 appointment. One payment is applied to exactly 1 bill, and 1 bill can be paid off over time by several



payments. A bill can be outstanding, having nothing yet paid on it at all. One patient can make many payments, but a single payment is made by only 1 patient. Some patients are insured by an insurance company. If they are insured, they can only carry insurance with one company. An insurance company can have many patients carry their policies. For patients that carry insurance, the insurance company will make payments. Each single payment is made by exactly 1 insurance company. We will go through sentence by sentence on the next several slides and trace through the associated ERD. A data analyst will meet with clients (who are subject matter experts) and work with them to elicit the information needed to model their data needs. This paragraph is a very simplified example because each data need is clear and completely stated. Thus it does not represent the information that an analyst encounters in a real-world setting. Slide 23 In the pink box on the slide, you see that a doctor can be scheduled for many appointments, or may not have any scheduled at all (i.e., a doctor can have zero to many appointments scheduled). Each appointment is scheduled with exactly 1 doctor. (i.e., an appointment can have only one doctor associated with it). Slide 24 In the blue box on the slide, you see that a patient can schedule 1 or more appointments. One appointment is scheduled with exactly 1 patient. Slide 25 In the orange box on the slide, you see that an appointment must generate exactly 1 bill and a bill is generated by only 1 appointment. In the yellow box on the slide, you see that one payment is applied to exactly 1 bill, and 1 bill can be paid off over time by several payments. A bill can be outstanding and have nothing yet paid on it at all. Slide 26 In the green box, one patient can make many payments, but a single payment is made by only 1 patient. In the purple box, some patients are insured by an insurance company. If they are insured, they can carry insurance with only one company. An insurance company can have many patients carry their policies.



In the yellow box, for patients that carry insurance, the insurance company will make payments, each single payment is made by exactly 1 insurance company. Slide 27 Crow’s foot notation is one of several ways to represent static data content. Because of widespread use, it has become a de facto standard. Importantly, the notation encompasses key information about static content that is needed to specify a database. Most likely for this reason, the concepts represented in this notation have been carried forward and built upon in UML class diagrams. Slide 28 This concludes Lecture e, Process Mapping; Entity-Relationship Diagrams. As a workflow process analyst and redesign specialist, you may encounter ERDs and need to get information from them about data that are used or generated in a process. Thus, being able to recognize an ERD and read pertinent information from one is important. In summary, we covered the background of ERDs and process aspects covered by them (i.e., static content). We introduced the symbols and notation used in ERDs and worked through several examples reading a simple ERD. You should now be able to recognize an ERD and be able to read and interpret the diagram. For more exposure to ERDs and the relational data model, we suggest a course in relational databases. Slide 29 No audio. Slide 30 No audio.

Audio

Transcript

WORKFLOW ANALYSIS


Unit 3 Interpreting and Creating Process Diagrams Lecture F Process Mapping Entity Relationship Diagrams

Slide 1 Welcome to Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping: Unified Modeling Language (UML). This is Lecture f. The Component Fundamentals of Health Workflow Process Analysis and Redesign, examines different diagramming methods for developing graphical representations of processes in health care settings. Throughout the last century, different diagrams and notations have arisen. There is considerable overlap between them. Some have fallen by the wayside and others remain in use. Some have become international standards, while others exist in textbooks and articles. In this unit, we present major formalisms for process diagramming in use today and the process aspects that each covers. This is the sixth and final lecture of the Process Mapping Unit of component 10, Fundamentals of Health Workflow Process Analysis and Redesign. Lecture f covers the Unified Modeling Language (UML). Slide 2 The objectives for this unit, Interpreting and Creating Process Diagrams: Introduction, are to: • Create a process flowchart for a health care system (or system component) using



diagram, • Read and interpret Gane-Sarson data flow diagrams, • Read and interpret an entity relationship diagram in crow’s foot notation, and • Read and interpret UML class, activity, and state diagrams. Slide 3 Upon the completion of Lecture f, you should be able to: • Understand the purpose, symbols and conventions for UML Class, Activity and State

machine diagrams and, • Read and interpret the UML diagrams

Health IT Workforce Curriculum Fundamentals of Health Workflow Process Analysis and Redesign 2 Version 3.0/Spring 2012 Unified Modeling Language (UML) Lecture f This material Comp10_Unit3f was developed by Duke University, funded by the Department of Health and Human Services, Office


There are entire certifications in UML and Object Oriented Design. It would be impossible to cover the entirety of UML in this lecture. Similarly, it would be impossible to impart skills to create UML diagram sets. We use this lecture to introduce three UML diagrams most relevant to workflow analysis and process re-design, and refer the interested student to the publically available reading and training on UML and object oriented design. Slide 4 Each of the methods for diagramming a process covers different process aspects. Unified modeling language (UML) has diagrams to represent each of the process aspects that we are interested in for process analysis and re-design. These include use case diagrams that represent the context in which the system operates, process and data flow steps, information content, any information transformations that occur or should occur, the order or sequence of the steps involved in the process (including flow control and state), and the roles of the persons completing the steps in the process. There are 13 different types of UML diagrams. W we will cover three of them here. Slide 5 Unified Modeling Language is a standard developed and maintained by the Object Management Group (OMG). The first UML standard, UML1 was released in 1997. (Watson, 2010)

The Object Management Group states that the rationale behind the creation of the UML standard was that, “visual software modeling was plagued by the incompatibility of different notations created by different modeling gurus. The absence of a standardized notation deterred potential users, and as an inevitable result the modeling tools market was tiny and fragmented.” (Watson, 2010) UML is for software design and development, not workflow or process representation. However, software development necessitates process and workflow analysis and representation, thus, because they represent the same information, UML diagrams are sometimes used on workflow analysis and process redesign. Further, UML adapts and incorporates notations that existed in the early 1990’s, for example, ISO 5807 Flowcharts, Yourdon, Gane-Sarson, and entity-relationship diagrams. Slide 6 UML notation was developed to support visual modeling in the development of software, and later, to support using the models to automate software development.



UML provides different diagram types that represent aspects of computer software and system context, e.g., functionality, data content, and data movement, not physical process steps. Many IT professionals are trained in UML, thus workflow analysts may encounter UML diagrams in practice. We present in this module how to read UML diagrams rather than detailed training on how to create UML models. Slide 7 The thirteen UML diagrams fall into three categories. • Structure Diagrams, of which there are six types, represent static aspects of system

structure. One structure diagram, the UML Class Diagram, is covered here • Behavior Diagrams, of which there are three types, represent dynamic aspects of

systems. Of these, two diagrams, the UML Activity Diagram and the UML State Machine Diagram are covered here.

• Interaction Diagrams, of which there are four types, represent detailed behavior. Interaction diagrams are not covered here.

Slide 8 A class diagram is a model of the information stored in a system and in many ways, is analogous to the E-R diagram covered in lecture e. Slide 9 A class diagram shows static information content, for example, data that are collected or used in patient care. Data collected and used in the diagnosis of tuberculosis are shown on the diagram in the slide. Class diagrams show the data in boxes and the relationships between the data, called associations. Like entity-relationship diagrams, class diagrams also show the minimum and maximum times an instance of one class can be related to an instance of another class, called cardinality and modality of the relationships. Slide 10 A class, shown by a box, represents the information collected, generated by or used in a process. An association, shown by a line, represents relationships between the information. Where an entity-relationship diagram shows only the number of times data can be related, class diagrams employ more types of relationships, including aggregation, composition and inheritance that are designated by different arrow heads. Navigability, i.e. direction of the relationship, is shown by an arrow head.



Cardinality and modality of the association are shown by numbers on the lines. Slide 11 It is easier to see these in this larger view of the class diagram shown than of the one shown on slide 9. In UML, the associations use different types of arrows. The black filled diamond signifies composition, for example, a package of skin tag removal supplies is composed of a set of tweezers, a pair of scissors, and some gauze. In this case, the black diamond would be “on” or attached to the “skin tag removal supplies” box. An open diamond (not shown on the slide) signifies aggregation. In aggregation, the aggregate class (the box to which the open or white diamond is touching) is in some ways the “whole”, with the class on the other end of the association being some “part” of that whole. The open triangle arrows signify inheritance. Inheritance means that one box, also called a class in UML, receives its properties from another. For example, boxes for “patient” and “pediatric patient” may have an inheritance association because all of the information that applies to a patient would also apply to a pediatric patient. In this case, the open arrow would be attached to the patient class. A dependency, not shown on the diagram, signifies a relationship that is less direct or not directly dependent. Dependencies are shown with dotted lines. Slide 12 Similar to a flowchart, an activity diagram shows movement of either tasks and steps or movement of information. In UML parlance, this is called the dynamic aspect of a process, or simply “behavior”, as opposed to class diagrams that show the “static” aspects. Although activity diagrams have a significant number of features in common with flowcharts, the symbol set is smaller. Activity diagrams focus on the movement rather than using symbols to differentiate types of data, or types of task steps, etc. Slide 13 An activity, shown by a long rectangle with rounded corners is a task that is performed either by a person or a computer system. Motion and direction, shown by lines with arrow heads, indicate the flow of the process or information. Branch points in a process, shown by either a diamond or a heavy horizontal line, indicate when more than one option or path exists by which the process can proceed or



the information can flow. The start and stop of a process or information flow are shown by circles. Slide 14 In this simplified activity diagram example, the process starts when a patient calls to schedule an office visit. The receptionist answers and attempts to schedule the appointment. If a mutually-convenient time is found, the appointment is scheduled, if not, the process ends. When the scheduled date arrives, the patient attends the visit (or not). The process is complete when the office visit is over. Slide 15 A state machine diagram, also called state diagram, shows the different states, also called “statuses”, allowed as something moves through a process, for example, as information is processed by a system. For example, a prescription may have any of the following statuses:

• Requested by patient, • Authorized by provider, • Sent to pharmacy, • Filled, or • Not filled.

These would be examples of states or statuses that an ePrescription may have. In real life applications, something like a prescription or other order may have 10, 20 or more states. Slide 16 State diagram symbols are simply rectangles and lines and arrows that denote transition. Slide 17 This simplified state diagram example corresponds to the previous activity diagram example. The process starts when a patient calls to schedule an office visit. The receptionist answers and attempts to schedule the appointment. While trying to find a mutually convenient time, candidate time slots are marked as tentative. When a time slot that will work for both the patient and the practice is found, the appointment is scheduled. That state remains until the appointment has arrived (the patient has arrived). At the end of the time slot, visits that have not been arrived are marked as missed. If the time slot has been marked as arrived, it is given a status of complete when the claim form is entered, i.e., when the patient is leaving.



Importantly, the diagram shows valid transitions, for example, according to the diagram example, a scheduled slot can go to states of arrived or missed, but a scheduled time slot cannot go directly to a status of complete. Slide 18 UML is an international standard and is maintained by the OMG. The standard is freely available from the OMG web site. Slide 19 In Lecture f, we provided a brief overview of Unified Modeling Language (UML) class, activity and state machine diagrams. We covered the purpose, symbols and salient conventions for each of the diagrams. This is the final lecture of six in the Fundamentals of Health Workflow Process Analysis and Redesign: Process Mapping unit. At this point, you should be able to: • Understand the purpose, symbols and conventions for UML Class, Activity and State

machine diagrams and, • Read and interpret the UML diagrams Slide 20 This concludes Fundamentals of Health Workflow Process Analysis and Redesign. In unit 3, we covered five diagramming methods. Based on feedback from practitioners, we recommend using two methods (data flow diagrams in Yourdon notation, and flowcharts). For these two recommended methods, we covered concepts and skills from reading and interpreting the diagrams to actually creating them. For the remaining three diagrams, we covered only background, use, and notation, i.e., the presentation prepares the student to read and interpret the diagram but not to create them. At this point, you should be able to: • Create a process flowchart for a health care system (or system component) using

appropriate ISO 5807 symbols and conventions. • Create context and data flow diagrams for a health care system (or system

component) using appropriate Yourdon symbols and conventions • Choose the correct scope and detail level for a process flowchart and data flow

diagram • Read and interpret Gane-Sarson data flow diagrams • Read and interpret an entity relationship diagram in crow’s foot notation • Read and interpret UML class, activity, and state diagrams.



Slide 21 No audio. End.

Audio Transcripts Workflow Analysis - Remote Learner · UML, developed a few decades after and...

Documents

Transcript of Audio Transcripts Workflow Analysis - Remote Learner · UML, developed a few decades after and...