VDML Healthcare Use Case. OMG document number:

Project title: Networked Enterprise transformation and resource management in Future internet enabled Innovation CloudS Acronym: NEFFICS Project No: 258076 THEME: ICT-2009.1.3 Internet of Things and Enterprise Environments VDML Healthcare Use Case (Value Analysis of Remote Monitoring of High Risk Pregnancies ) OMG document number: Based on work from NEFFICS Work Package 2 and 3 Date: 2012.11.10 Version: 0.1 Leading partner: Editor(s): Author(s): Dissemination level: CORDYS Fred Cummins, Henk de Man Fred Cummins, Henk de Man, Arne J. Berre Public Copyright NEFFICS Consortium 2010-2013

Executive Summary This report describes a use case for VDML (Value Delivery Modeling Language) in healthcare. VDML is a modeling language developed in response to an RFP by the Object Management Group, as described in the document: Value Delivery Modeling Language 1.0, OMG document bmi/2012-11- 07. The purpose of this use case is to validate the VDML metamodel and notation, and to provide an example of how an analyst might use VDML to develop a model for evaluation of a proposed business change. This use case is a hypothetical analysis of the values of remote monitoring of high-risk pregnancies, selected as one of many use cases within healthcare studied in the NEFFICS project. The business context for this analysis is based on characteristics of generic healthcare business models and might later be refined further for more specific situations. This use case demonstrates the use of VDML for modeling and analysis of a proposed change to an as-is business system. It also demonstrates how the scope of analysis can be limited to consideration of a specific area of concern. The report begins with a description of the use case, followed by a discussion of an analytical approach using VDML. This includes phases of analysis and various views that support the analysis. The last section highlights insights from this use case regarding the use of VDML. Additional details of the use case are included in Appendices A, B and C. Appendix D provides a glossary of VDML terms. Page 2 / 39 Copyright NEFFICS Consortium 2010-2013

TABLE OF CONTENTS EXECUTIVE SUMMARY... 2 1 2 3 4 INTRODUCTION... 4 CASE DESCRIPTION... 5 ANALYSIS APPROACH... 6 3.1 DEFINE THE BUSINESS CONTEXT... 6 3.2 DEFINE DETAILS OF THE HOSPITAL VALUE PROPOSITION FOR THE PATIENT... 8 3.3 MODEL THE HIGH-LEVEL ACTIVITIES OF THE BUSINESS ENTITIES... 10 3.4 DEFINE SUPPORTING ROLES AND CAPABILITIES... 10 3.5 MODEL THE CAPABILITY METHOD ACTIVITY DIAGRAMS... 12 3.6 IDENTIFY ASSOCIATED RESPONSIBILITIES... 17 3.7 IDENTIFY VALUE CONTRIBUTIONS... 19 3.8 ENTER VALUE MEASUREMENTS... 19 3.9 CREATE RELEVANT SCENARIOS... 20 3.10 HIGHLIGHT KEY CAPABILITIES... 20 3.11 ANALYZE ACTIVITY DEPENDENCIES... 21 INSIGHTS ON VDML MODELING... 23 4.1 AS-IS ANALYSIS... 23 4.2 VALUE STREAM AS SCOPING CONCEPT... 23 4.3 IMPORTANCE OF A TOOL... 23 4.4 IMPORTANCE OF SCENARIOS... 23 4.5 ITERATIVE REFINEMENT OF MODEL AND MEASUREMENTS... 23 4.6 LIMITATION OF SCOPE... 23 4.7 PROFESSION AS CAPABILITY... 24 4.8 PARTICIPATION BY CONTRACTORS... 24 4.9 TYPICAL VALUE COMPUTATIONS... 24 4.10 ACCOUNTING FOR EXCEPTIONS... 24 4.11 CONCURRENT AND REPETITIVE ACTIVITIES... 24 4.12 ACTIVITIES OVER MULTIPLE SHIFTS... 24 APPENDIX A, USE CASE CAPABILITY METHODS... 27 APPENDIX B... 35 APPENDIX C, MATERNITY CARE VALUE NETWORK... 37 APPENDIX D, GLOSSARY... 38 Copyright NEFFICS Consortium 2010-2013 Page 3 / 39

1 Introduction This report describes a use case for VDML (Value Delivery Modeling Language) in healthcare VDML is a modeling language developed in response to an RFP by the Object Management Group, as described in the document: Value Delivery Modeling Language 1.0, OMG document bmi/2012-11-07. The purpose of this use case is to validate the VDML metamodel and notation, and to provide an example of how an analyst might use VDML to develop a model for evaluation of a proposed business change. This use case is a hypothetical analysis of the values of remote monitoring of high-risk pregnancies, selected as one of many use cases within healthcare studied in the NEFFICS project. The business context for this analysis is based on characteristics of generic healthcare business models and might later be refined further for more specific situtations. This use case demonstrates the use of VDML for modeling and analysis of a proposed change to an as-is business system. It also demonstrates how the scope of analysis can be limited to consideration of a specific area of concern. The report begins with a description of the use case, followed by a discussion of an analytical approach using VDML. This includes phases of analysis and various views that support the analysis. The last section highlights insights from this use case regarding the use of VDML. Additional details of the use case are included in Appendices A, B and C. Appendix D provides a glossary of VDML terms. Page 4 / 39 Copyright NEFFICS Consortium 2010-2013

2 Case Description An expectant mother is typically examined by her obstetrician early in her pregnancy and at regular intervals during gestation until time for delivery. For high-risk pregnancies, it may be appropriate for examinations to be more frequent, but, at the same time, patients are advised to minimize their activities, which conflicts with the need for frequent visits to the doctor s office. This modeling effort is to provide the hospital with insight regarding the use of remote monitoring equipment to continuously monitor the condition of the mother and fetus for a high-risk pregnancy, thus reducing the need for repeated examinations. This is expected to both improve outcomes and reduce the cost of maternity healthcare. In order to understand the consequences of monitoring high-risk pregnancies, analysis must consider the effects from the initial examination through hospital discharge following delivery. We have made the following assumptions regarding this course of care: Doctor s businesses are independent business entities, and the doctors have privileges to treat patients in the hospital under contractual arrangements with the hospital. Responsibility for hospital healthcare procedures is associated with a clinical oversight organization unit. A hospital organization unit is responsible for the remote monitoring service. While electronic healthcare records may improve quality of healthcare, the differential effects of monitoring high-risk pregnancies will not be affected by the availability of electronic healthcare records. Co-occurring conditions or complications (that may occur with pregnancies) will require additional treatment regimen, but they need not be modeled in detail if the associated measurements are independent of the use of remote monitoring. More or less frequent occurrence of these conditions can be reflected in the summary value contribution measurements of high-level activities for treatment for those conditions. Monitoring will involve minimal changes to established practices and business relationships, so there will be little change to the treatment of normal pregnancies. The healthcare details of this use case may be somewhat over-simplified, but they, nevertheless, serve to present a diversity of modeling requirements that both illustrate the practical use of VDML and validate its metamodel and notation. Copyright NEFFICS Consortium 2010-2013 Page 5 / 39

3 Analysis Approach This use case represents an analytical approach of a hospital business analyst using VDML to consider the healthcare effects of remote monitoring of high-risk pregnancies. The approach reflects a scope of analysis of factors that may be affected by the use of remote monitoring. The level of detail in this use case was limited due to the fact that at the time of development of this use case there was no implementation of a VDML tool available to support the effort. Nevertheless, the level of detail is sufficient to meet the objectives of the use case analysis. The following sub-sections will describe the phases of analysis. 3.1 Define the business context Analysis of the effects of remote monitoring requires analysis of the differential effects of monitoring on maternity care. We start by establishing the general business context in which maternity care is delivered. Figure 1, below, depicts the business party roles of a Client (the patient as an economic entity), a Doctor s Office (a business entity that includes one or more doctors, supporting staff and facilities), and a. In the normal course of business, these parties exchange products and services expressed as value propositions related to healthcare. The ovals represent business party roles and the hexagons represent value propositions. The pregnant woman in the Client role takes the role of within the healthcare system as a participant in and as the subject of medical procedures, but note that for other medical conditions, the Client could be a parent and the could be a child. Similarly, the Doctor s Office is an economic entity that may involve multiple doctors (sometimes called a practice ). Within the medical procedures, the doctors have roles based on their specialties (e.g., obstetrician). There is only one hospital involved, that is the hospital considering the impact of the remote monitoring service. Payfor Services Doctor s Office MedicalServices Doctors& s Payfor Services Privileges &Services Figure 1, Value Proposition Exchange Healthcare Services A value proposition will typically identify one or more deliverables and express multiple, associated values of interest to the recipient and their combined effect. A Doctor s Office provides medical services to the Client and the Client pays for the services. The Doctor s Office provides both patients for treatment and doctors to provide collaborative medical care to patients in the. The provides healthcare services for the patient and the Client pays for those services. The Doctor s Office role and the Client role represent individuals from a community of doctor s offices and a community of healthcare recipients, respectively. Each person from the Client community will be treated by one or more doctors from the Doctor s Office community. If there are significant differences among groups of patients, then different patient community segments (equivalent to Page 6 / 39 Copyright NEFFICS Consortium 2010-2013

market segments) could be defined and values could be evaluated based on the differences in service utilization. Similarly, if necessary to the analysis, the doctor community could be classified into medical practices that provide certain specialties (potentially overlapping sub-sets). Particularly for patient community segments, differences between normal and high-risk pregnancy segments will be addressed by defining different scenarios, discussed later. While there is also a community of hospitals, we are only concerned here with one hospital, the hospital considering the remote monitoring of high-risk pregnancies. In this use case, each of the value propositions of Figure 1 are aggregations of the all of the values for all of the services offered by the Doctor s Office and. In this use case, we include only the value measurements and value propositions of maternity care. s Doctor s Office Doctors Client MaternityCare Services MonitoringService Figure 2, Value Proposition Exchange for the Maternity Care Value Stream Figure 2, above, depicts the roles and value propositions of interest to this use case. The management wants to understand the impact of remote monitoring on the value proposition delivered to the patient. To perform this analysis, the analyst must consider the value stream that supports the value proposition to the Client. A value stream consists of the activities, the capabilities, the deliverables and the values that contribute to the value proposition. In other words, a value proposition defines a value stream by virtue of the linkages of the VDML model that identify the activities, capabilities, values and deliverables that contribute to the value proposition. The Maternity Care Services value proposition offered to the Client by the is the focus of this analysis. The value propositions delivered with doctors and patients from the Doctor s Office contribute to values of the hospital care and thus the s value proposition to the Client. The Monitoring Service value proposition contributes values to the Doctor s Office care and thus indirectly to the value propositions of the Doctor s Office and the. Figure 3, below, illustrates the role collaboration view of the maternity care value stream showing the exchange of high-level deliverables between the business entity roles of the business network that are relevant to this use case. Copyright NEFFICS Consortium 2010-2013 Page 7 / 39

OfficeAppointment Doctor s Office Client Monitoring Reports Admission Request Obstetrician Services Initiate Monitoring Emergency Admission Maternity Care Figure 3, Maternity Care Role Collaboration Diagram 3.2 Define details of the hospital value proposition for the patient In this use case, the hospital is concerned about the maternity care value proposition to the maternity care Client. The value proposition must identify the values of interest to the Client, and the VDML model will determine the sources and measurements of those values to assess the level of satisfaction perceived by the Client. In this use case, we will compare alternative value propositions to determine variations in patient satisfaction considering various patient populations and maternity care circumstances. The hospital maternity care value stream is driven by a network of activities and supporting capabilities that contribute value to the end result the value proposition to the Client. In the VDML model, values added to deliverables by each activity are measured as value contributions to be aggregated in the value proposition. These measurements may be specific figures or they may be computed from other value contributions and properties. Efforts to increase some values may have a negative effect on other values. Some of the activity value contribution measurements express the performance of the associated activity such as cost and duration, and other measurements express intrinsic values added to the deliverable by the activity. We will later develop the activity network for this value stream to support specification of the value contributions. The value contribution measurements captured in the VDML model are based on the operation of the activity or characteristics of the deliverable; by themselves, they do not reflect levels of recipient satisfaction. The value proposition model element transforms the value measurements to recipient satisfaction levels, so the value proposition reflects values from the recipient s perspective. For purposes of this analysis, there is no need to define all values of interest to a Client of maternity care services, but rather the analysis will focus on values that will be affected by the use of remote monitoring for high-risk pregnancies. We have identified the following value measurements: Cost of care Duration of hospitalization Risk of death of mother Risk of loss of child A VDML implementation will include a library of units of measure that can be used to express these measurements and determine their use in computations. There may be other values that would be of interest, such as patient comfort or time waiting for service, but the above values are sufficient to illustrate the application of VDML to this use case. Page 8 / 39 Copyright NEFFICS Consortium 2010-2013

The measurements in a VDML model are not data about individual patients, but are statistical figures representing typical maternity patients in this healthcare system. We describe the basis for measurements as the unit of production. The unit of production in this case is the course of treatment of a single pregnancy. Thus the measurements are statistical values on a per-patient basis. These measurements may express statistical variance (e.g., median and standard deviation). The measurements may be estimates developed by the VDML user, they may be empirical measurements collected from actual operation of the business, or they may be measurements developed from a simulation. VDML is designed to provide input to simulation and incorporate the output of simulation, but simulation, per se, is outside the scope of the current version of VDML. Note that the death of a mother or child is, of course, a very negative value. However, we are not evaluating the satisfaction of an individual patient so the level of satisfaction should not be based on a death, per se, but rather on the level of risk expected from care by this healthcare system. A deeper analysis might consider these risks based on different patient market segments other than normal and high-risk pregnancies. These would be considered in different scenarios. Scenarios are discussed later. The industry average for a value measurement may be a reasonable baseline for customer satisfaction. A value proposition computation for the level of satisfaction for a particular value could then be based on the degree of variance from the industry average. The overall level of patient satisfaction expressed by the value proposition is computed from a weighted average of these satisfaction measurements where the weights reflect the relative importance of the values to the recipient. The analyst specifies the computations for aggregation of activity value contributions, the computations for transformation to level of satisfaction, and the weights to be used to compute the overall level of satisfaction. Value weights are subjective as are the computations for level of satisfaction for individual value measurements. The analyst should specify initial satisfaction computations and value weights based on experience or standards, if available. The analyst will likely make adjustments when actual performance data drives the results or business leaders adjust expectations. In the maternity care VDML model, the relevant value measurements (not the satisfaction levels) of the Doctor s Office value propositions must be input to the value stream so they are reflected in the value proposition. Similarly, the value measurements of the value proposition for monitoring by the hospital must be incorporated into the Doctor s Office value stream to be delivered with the patient to the hospital. Thus, in this use case, the four values of interest are affected by hospital services, by doctor services in the community and in the hospital, and by the monitoring services provided by the hospital to the Doctor s Office. Copyright NEFFICS Consortium 2010-2013 Page 9 / 39

Client Obtain Maternity Care Doctor s Office Appointments Visit Doctor s Office Monitoring Reports Monitor Gestation Emergency s Handle Emergency Monitored s Monitor Admission Requests Provide Maternity Care Figure 4, Maternity Care Business Network Activity Diagram 3.3 Model the high-level activities of the business entities We now begin development of the more detailed activity networks for the maternity care value stream. Figure 4, above, shows an activity network view of the maternity care business network. This network depicts the activities of the business network parties that accomplish the associated exchange of deliverables and value propositions. The rows of the activity diagram of Figure 4 represent the roles of the business network. The activities of a role are performed by a participant in that role. The boxes with rounded corners are activities and the inverted pyramids are stores. A store receives and holds business items until they are needed by a subsequent activity. The diamond elements on the activities indicate alternative deliverable outputs, so a patient may either leave a doctor s office visit with a repeat appointment or be admitted to the hospital. The plus-sign icon indicates that the activity delegates to a capability method for the detail of the work to be done. The client performs one activity that either makes a doctor s appointment to enter the healthcare system as a patient in the Doctor s office, or the client enters the system as a hospital emergency patient. The other roles, Doctor s Office and, perform activities that delegate to more detailed capability methods. 3.4 Define supporting roles and capabilities Activities of the Doctor s Office and engage capability methods that define how more specific roles collaborate to do the work. We will focus first on the Doctor s Office Visit method that is engaged by the Visit Doctor s Office activity of Figure 4. Page 10 / 39 Copyright NEFFICS Consortium 2010-2013

Table 1, Role Collaboration Table for the Doctor's Office Deliverable RoleFrom RoleTo Type 1 Appointment Officeadministrator Tangible 2 Officeadministrator Tangible 3 Authorizationrequest Officeadministrator Payer Tangible 4 Authorization Payer Officeadministrator Tangible 5 Officeadministrator Obstetrician Tangible 6 Symptoms Obstetrician Tangible 7 Treatmentoptions Obstetrician Tangible 8 Monitorprovider Tangible 9 Monitorprovider Obstetrician Tangible 10 Treatmentplan Obstetrician Tangible 11 Nextappointment Officeadministrator Tangible Table 1 has been created to capture the roles in the Doctor s Office Visit method. In the real world, the analyst can observe the flow of work as deliverables moving between participants. In this method, the patient has a role, but is also the deliverable in several exchanges as she is received, examined, etc. This does not identify or define all the activities of these roles since it only identifies where deliverables move between roles. Those activities that do not produce deliverables shared with other roles are less obvious. Nevertheless, the table of deliverable flows provides a framework for development of more detailed activities. Figure 5, below, shows a role collaboration diagram corresponding to the deliverable flows of Table 1. The ovals represent roles and the arrows represent the flow of deliverables. This view makes it easier to see the inputs and outputs of each role. The analyst can consider if it is reasonable for additional deliverables to be exchanged or if some of the work calls for additional roles. The analyst may add intangible deliverables to the table and the diagram where needed as a result of this analysis. An intangible deliverable is one that is not formally recognized but is needed for effective operation. Often these are conversations, telephone calls and emails. Monitor provider Office admin Payer 11NextAppointment Obstetrician Client 8 10TreatmentPlan Figure 5, Doctor's Office Role Collaboration Diagram Copyright NEFFICS Consortium 2010-2013 Page 11 / 39

The deliverables are numbered to correspond to the numbers in the first column of the table. The number sequence provides a convenient basis for discussion of the flows. A VDML tool can generate the numbers based on the table or supporting activity diagrams, if available. Note, that there may be flows that occur independently and thus actually may be in different sequences in different situations, and there will be some flows that occur repeatedly but are only represented by a single row in the table and a single deliverable arrow in the diagram. A role collaboration table and corresponding role collaboration diagram can be created for each method. When modeling an as-is value stream, the business analyst may not consider a role collaboration diagram essential. Instead, an analyst might bypass this and proceed to the next phase to develop the activity networks that include the same information but with more detail. However, use of the role collaboration diagram has several benefits: It helps clarify the scope of analysis by focusing on the exchanges of deliverables necessary to deliver the end product or service. It helps identify the roles that are necessarily involved in each method. It exposes the deliverables exchanged and may help identify intangible deliverables that would be overlooked by focusing immediately on activities. It provides a useful level of abstraction for considering changes to the overall design of the value stream. By abstracting away activity detail, the role collaboration view enables more objective consideration of alternative operating strategies. For example, in a new or existing value stream, new technologies or changes in business requirements may eliminate roles and constraints underlying established operating strategies. The role collaboration diagram brings a focus on the fundamental requirements for exchange of deliverables. These analysis factors may not be immediately obvious, but as the analysis proceeds with more detail, it may be useful to return to the role collaboration diagram to validate and explore the implications of proposed changes to the business system. In a value stream without obvious sub-collaborations, the role collaboration diagram may help identify smaller teams focused on more specific capability methods in order to reduce coordination and communication overhead, improve flexibility and enable sharing of capabilities. A role collaboration table and collaboration diagram could be used to analyze the complete maternity care value stream, defining the more detailed roles and deliverables for all of the activities of the business network. This level of detail is shown in Appendix B and the role collaboration diagram is shown in Appendix C. However, this use case has an inherent structure that helps partition the larger collaboration (discussed below). 3.5 Model the capability method activity diagrams At this stage, we will develop the detail of capability methods engaged by activities of the business activity network (Figure 4). But first, let s examine the concept of a capability method in more detail. A capability method is a collaboration, like the business network, but a capability method defines an activity network template that may be used for delivery of a capability in different contexts it defines a shared service. The same capability method may be engaged by different activities to provide its capability. Each execution of the method may be performed by different participants each time it is used. A capability method collaboration is also different from an organization unit collaboration that represents a specific unit of an organization structure -- a single occurrence, populated by specific people or subordinate organization units. We will look at the associated hospital organization units later. The capability method that is engaged by an activity is selected based on its capability offer to satisfy the capability requirement of the delegating activity. A capability offer is presented by an organization unit that has the resources, facilities, intellectual capital, etc., to deliver the capability. The organization unit will typically use a capability method to apply the capability in a defined way. The capability method may be owned (designed and managed) by the same organization unit, or it may Page 12 / 39 Copyright NEFFICS Consortium 2010-2013

perform a shared capability method that is owned by another organization unit. We will return to the relationship of capability methods to organization units later in this use case. In this use case, the more detailed maternity care activities are quite naturally clustered around treatment settings. It is reasonable to define a capability method for each of these treatment settings. If we did not have these distinct treatment settings or we did not want to make that assumption for definition of capability methods, we might start with a single activity diagram with the 17 roles of Figure 26, in Appendix C, and expand the activities of each role, looking for activity clusters that provide identifiable capabilities to form more distinct capability methods. Finer granularity of capability methods increases the potential for exposure of duplicated capabilities to be considered for consolidation as shared services. Figure 6, Capability methods delegations However, in this use case, treatment settings define natural phases of treatment. Figure 5, above, depicts the delegation paths for the capability methods of this use case. The top-level corresponds to the roles of the maternity care business network of Figure 4. The next level corresponds to the methods engaged by activities of the business network roles. Only one activity is specified for the Client and that activity does not delegate. Each of the activities of the Doctor s Office and delegate to a method that defines the detail of that activity. Two of these (the Doctor s office visit, and the maternity care methods) further delegate to additional methods. The methods identified with an asterisk (*), above, are used as examples in the following discussion. In Appendix A, a capability method activity diagram is presented for each of these methods along with a brief discussion. Figure 16 through Figure 19 and Figure 25 are repeated here, in Figure 5 and Figure 7 through Figure 10 for convenient reference in the following discussion. We will assume that we have role collaboration tables for each of the subordinate capability methods. The role collaboration analysis is useful for identification of roles and relationships in activity diagrams. However, an activity network adds the following: The activities performed by the roles The deliverables that do not cross role boundaries The capabilities required to perform the activities The value contributions of the activities Copyright NEFFICS Consortium 2010-2013 Page 13 / 39

Office Administrator Obstetrician Appointments Examination Provide information Payer info Payment Auth Results Symptoms Authorization Diagnosis Diagnosis Describe Symptoms Treatment Options Options Select Options MonitorRequest Treatment Planning Selections with Monitor Plan Request Admission Accept plan. Schedule Next Appt. Acceptedplan Appointment Request Admission Request Monitor Provider Initiate Monitoring Figure 7, Visit Doctor's Office Capability Method Figure 7, above, illustrates the Doctor s Office visit method. appointments are held in a store pending arrival of the patient at the designated time. At the end of the visit, the patient either makes another appointment (the Appointments store) or the obstetrician makes a hospital admission request (a store for Admission). There are two patterns by which the methods may be integrated: (1) each capability method may be engaged as a service by delegation from an activity of the parent collaboration that passes input deliverables to the method and receives output deliverables from the method, or (2) deliverables may flow directly from one capability method to the next via stores. The first is a service-oriented architecture approach, and the second is a flow-through approach. In the service-oriented approach, the capability methods may be shared by different parent capability methods, and each parent activity determines the flow of deliverables in and out of the methods. Most if not all businesses will have some of each pattern. This use case depicts the maternity care activity network as primarily a flowthrough integration pattern. Regardless of the integration pattern, VDML defines each delegation to a capability method as a different analysis context that may have different sets of measurements for the same method. Analysis contexts will be discussed further later in this report. As a result, activities of the parties in the business network delegate to more detailed capability methods, but inputs and outputs are not controlled by the delegating activity as might be implied by the business network diagram of Figure 4. Instead, the flow of deliverables occurs lower in the network structure where an output deliverable from an activity in one capability method flows to a store that holds it for input to an activity of another capability method. This is illustrated in the Doctor s Office Visit Method. If the patient is determined to have a high-risk pregnancy, the patient has the option of participating in remote monitoring and the Initiate Monitoring activity engages the hospital capability method to initiate monitoring (discussed later). The Payment Authorization activity engages another capability method, but that method is not developed in detail because the value adds of that method are expected to be the same regardless if the pregnancy is normal or high-risk. Page 14 / 39 Copyright NEFFICS Consortium 2010-2013

An activity network is not concerned with the flow of control for execution of activities as in a BPMN process model, but rather the flow of deliverables and the statistical value contribution measurements on a per patient basis. A single pregnancy is the unit of production. Activities and flows are evaluated on the basis of the number of occurrences for one pregnancy. So, for example, if a maternity patient visits the doctor s office 10 times during her pregnancy, then for each activity that occurs during each office visit the measurements will reflect ten occurrences. However, the Initiate Monitoring activity should only occur once for each high-risk pregnancy based on the initial patient decision. At the end of this capability method, the patient will either be presented for hospital admission (the Admission Request store) or will obtain another appointment to see the doctor (resulting in performance of another occurrence of this method). The arrows depict the flow of deliverables from or to activities and stores. A store receives and holds multiple business items that are consumed by subsequent activities. Business items are the elements that are used, produced or consumed by activities and flow from or to activities and stores. The name of the business item type is shown on the deliverable flows. In this case, the patient is both a business item that flows between some activities, and a participant in a role that participates in certain activities. In a VDML tool, additional detail about an element, such as an activity, would be viewed by selection of the element in this view. The activities of Figure 7 begin with the patient s appointment the store holds the appointments of many patients. In the Select Options activity, the patient with a high-risk pregnancy decides if she will participate in remote monitoring. The small diamonds on the activity outputs indicate that only some of the outputs flow to each of the two paths they are not necessarily mutually exclusive flows, but in this case they are. The allocation is typically represented as a percentage. Similarly, the Accept Plan activity may result in either a repeat appointment or hospitalization. Each activity requires a performer with a capability to perform that activity. In this use case, the professionals are assumed to have all the capabilities required for the roles they perform. In other business contexts, a performer must have the capabilities required for each of the activities performed by that role. Potential performers may have combinations of more specific capabilities that cannot be simply identified with their profession or job classification, so the capabilities required cannot be simply inferred by the name of a role. VDML provides for the matching of capabilities required by each of the activities of a role to the capabilities of a performer to be assigned to the role. Request Device Accept Device Monitor Provider Request Establish Account. Request Assign Device Monitor Install & Test Provide Instructions Monitoring Devices Monitored s Figure 8, Monitoring Initiation Capability Method Figure 8, above, illustrates the capability method for the Monitoring Initiation method. The bottom-left pyramids indicate where the collaboration activity network is entered and exited by delegation and where delegation of deliverable inputs and outputs occurs. The monitor provider role of this capability method performs several activities with the patient as the input and output business item. This progression of the same business item is common in manufacturing operations where the same business item is enhanced in stages. The result of this capability method is that the patient leaves with a monitoring device installed and tested, with an understanding from instructions and as a patient Copyright NEFFICS Consortium 2010-2013 Page 15 / 39

being monitored. The initiation of monitoring adds to the store of s Monitored. Monitoring is a capability not further elaborated in this use case but is engaged by the Gestation Monitoring capability method, below. A capability method as a service (like Monitoring Initiation) could be used in a different part of the same value stream or a different value stream. For example, suppose monitoring were initiated in the emergency room as well as in the doctor s office. The capability method is the same but the circumstances are different, so value measurements would likely be different. Figure 9, below, depicts the Gestation Monitoring capability method that is a result of the remote monitoring capability. s who are not monitored will just use repeated office visits for evaluation of the status of their pregnancy. s Report Symptoms Office Appointment s Obstetrician Periodic Examination Report Send to Emergehcy Request ization Emergency s Admission Request Ultrasound Technician Ultrasound Report Monitor Provider Monitored s Monitoring Figure 9, Gestation Monitoring Method An activity is shown as engaging the monitoring service of the hospital. The input to the monitoring service is a store of Monitored s. The store is depicted as containing reusable resources since monitoring repeatedly checks the status of each of the patients and only produces an alert deliverable to the obstetrician when the status of the patient or fetus is a concern. The patient may also undergo ultrasound examinations that provide input to the obstetrician. The result of a monitoring alert and examination may be an office appointment, a trip to emergency, admission to the hospital, or no further action. The frequency of occurrence of these alternatives is indicated as properties of the diamond connectors. No-action is implied when the distribution of the expressed alternatives is less than 100%. The Gestation Monitoring method begins when monitoring is initiated and ends when the monitoring device is returned and the patient is removed from the Monitored s store. The activities within the monitoring method may occur multiple times for a patient. The patient may report symptoms multiple times and there may be multiple alerts and examinations by the obstetrician. Page 16 / 39 Copyright NEFFICS Consortium 2010-2013

Admission Requests Mother Recovery Hospi ta Admission PreDelivery Operating Room Child Child Recovery Figure 10, Maternity Care Method Figure 10, above, illustrates the capability method for hospital maternity care. This method is engaged by delegation from the hospital maternity care activity in the business network, but it does not receive its inputs from the delegating activity. Instead, it receives patients for admission in its Admission Requests store. Similarly, the capability methods engaged by these activities receive their inputs into stores, and deliver their outputs to stores (see the capability methods in Appendix A). Generally speaking, these methods will each be performed once for a pregnancy (unit of production). However, some patients may be admitted with false labor, so the first two activities may occur more than once, on average, for one pregnancy. 3.6 Identify associated responsibilities Figure 11, below, depicts an example capability management diagram for some of the capabilities of the high-risk pregnancy use case. It shows the organization units and the community responsible for providing certain specialist physician capability offers, using capability methods and managing capability methods and resources. Operating Room Beds Facilities Management. Operating Room Beds Admissoins Nurse ER Nurse Nursing Nurses Obstetrics Nurse Clinical Oversight Pediatric Nurse Emergency Admissions Maternity Ward Operating Room Emergency Admissions Maternity Ward Operating Room Obstetrician Pediatrician Anesthesiologist Affiliated Doctors Pediatricians ER Physicians Obstetricians Anesthesiologists Recovery Recovery ER Physician Figure 11, Clinical Capability Management Diagram In Figure 11, a large box represents an organization unit or community named in the small box at the top of the larger box. An organization unit is a collaboration with a fork icon (suggesting organization structure), and a community is designated with three small circles (suggesting loosely associated members). The stretched hexagons on the left side of a organization unit or community collaboration box represent capability offers of the associated collabortion. The square boxes connected to the capability offers with bold, dashed lines are the capability methods (designated by the linked-boxes icon) used to provide the capability. A capability method may be shown in a different organization unit indicating that it is performed by one unit and specified by a different unit (not shown in Figure 11). Copyright NEFFICS Consortium 2010-2013 Page 17 / 39

The fine, dotted lines connected to the capability methods identify capabilities or resources used by the capability method. A resource store is depicted by a bottom-up pyramid. The circular arrow inside a store triangle indicates that the store is a pool of reusable resources. A capability like Monitoring could be offered as a service by one or more organization units that own resources (people, equipment, materials, etc.) to deliver the capability. The organization unit will use a capability method to define how the resources are applied to provide the capability. In addition, the provider of a capability may delegate to capability methods provided by other organization units to do some of the work to deliver its capability. The capability method specification may be owned by the same organization unit that provides the capability, or it may be owned by another organization unit that is responsible for defining and maintaining the method specification. This allows different organization units (for example in different countries) to provide the same capability with the same capability method but different resources. When analyzing value delivery and considering improvements, it is important to understand the organizations responsible for the capabilities. Administration Clinical Services Support Services Medical Services Scheduling Nursing Maintenance X-Ray Procedures Case Management Housekeeping Ultrasound Billing Emergency Information Services Laboratory Contracts Clinical Oversight Facilities Management Medical Equipment Remote Monitoring Figure 12, An Organization Structure in a Collaboration Structure Diagram The analyst can navigate from the capability management diagram (Figure 11) to an organization structure diagram like that in Figure 12, to locate the organization units and their management chains. Figure 12 uses a collaboration structure diagram to represent an organization structure. In an organization structure, organization unit collaborations are assigned to position roles in other organization unit collaborations thus representing the organization hierarchy. An oval represents a role in the parent collaboration. A small oval at the connection to a collaboration indicates that it fills a role. A large oval with a participant name (not shown) indicates an actor directly assigned to the role. Similar diagrams can represent the assignment of other types of collaborations to roles. Page 18 / 39 Copyright NEFFICS Consortium 2010-2013

3.7 Identify value contributions The activity network defines a structure for identification of sources of value contributions. Each activity should be considered as a potential source of one or more value contributions and tagged as such. This is not shown in the activity diagrams, but would be supported as properties to be added or viewed in a name-value-list display for a selected activity. DeathinER Deathingestation Deathinchildbirth Predeliveryduration Deliveryduration Recoverydurattion Durationofhospitalization Deathinrecovery Riskofdeathofmother Value care Obstetrician Anesthesiologist Costofcare Riskofdeathofchild ERphysician Pediatrician Labtests Imaging Miscarriageduringgestation Miscarriageinemergency Stillborninpredelivery Monitoring StillborninOR Figure 13, Measurement Dependency Graph In the process of evaluating activities, the analyst may recognize the need for additional value types that are relevant and add their effects to the value proposition. A measurement dependency graph like that in Figure 13 can be generated from the activity network and activity value contributions. The plus (+) and minus (-) signs on the arcs indicate if the source measurement increases or decreases the target measurement. The graph depicts the aggregations of value contribution measurements that determine satisfaction levels and the overall patient satisfaction of the value proposition. A particular value measurement may be affected by multiple activities. Each of the relevant activities has an associated value contribution for that measurement. The computation for aggregation of these values depends upon the nature of the measurement. For example, durations and costs may be added (assuming the durations are sequential), while risks must be aggregated as probabilities. Costs may be adjusted for flow percentages or for activities performed multiple times. 3.8 Enter value measurements The value stream activity diagrams and value contributions include operational data to be entered in support of the analysis. The data should be captured at the granularity of performance for individual patients so that value measurements can be correlated with different groupings of pregnancies. In addition, criteria for classification of medical conditions will be needed for development of different scenarios, discussed below. Overall, it will be important to analyze the relationship between high-risk pregnancies and the effects on specific value measurements and the resulting hospital-to-patient value proposition. Copyright NEFFICS Consortium 2010-2013 Page 19 / 39

When collecting (or estimating) the value contributions data, it is important to remember that the measurements of an activity may reflect multiple occurrences of that activity for a single unit of production (i.e., a single patient). The duration of the activity may be short, but the cumulative time over many occurrences may represent considerable cost. In addition, particularly in healthcare, an activity may be performed by different people over multiple shifts. For this VDML model, the number of different people assigned is not of concern; rather the measurements should reflect the overall impact of the multiple occurrences for a single pregnancy. 3.9 Create relevant scenarios VDML provides the ability to capture sets of measurements that represent different circumstances. A set of measurements for elements of a VDML model for a certain circumstance is called a scenario. The same model may be used to represent different scenarios. So a scenario for the course of care for a typical pregnancy could be represented by one scenario with associated measurements, and a scenario for the course of care for high-risk pregnancies could be represented by a different scenario. This allows the analyst to compare the satisfaction levels achieved for each of the scenarios, and then examine the sources of differences between the scenarios by tracing back to the value contributions of activities. The following are different scenarios that could be of interest for assessing and understanding the implications of remote monitoring of high-risk pregnancies. All maternity patients Normal risk patients High-risk patients without monitoring High-risk, monitored patients High-risk monitoring opt-out patients Alternative high-risk selection criteria scenarios (i.e., what is high-risk?) Alternative high-risk alert scenarios (i.e., when does monitoring result in action?) Normal risk ER admissions High-risk ER admissions Comparison of the value propositions of scenarios will provide an overall perspective on the difference between the scenarios. However, this is not the whole story. Using the measurement dependencies, the analyst can identify the activities that have a significant impact on overall satisfaction. Critical activities depend upon capabilities that may help or hurt the specific value measurements. This will highlight capabilities that can be improved in order to have a positive impact on the value proposition. A scenario also supports different measurements for the same capability method engaged in different contexts. The different contexts are represented by different delegation contexts element. The delegation context also allows a business item (such as a patient) to be passed to a capability method where it is assigned to a role (e.g., the role that performs activities such as selecting treatment options). It should be noted that in some cases, changes to a capability may improve one value measurement and have an adverse effect on another value measurement. For example, in our use case, more frequent examinations may provide more timely intervention on problems but will increase costs. In a broader-scope model involving shared capabilities, a change to a capability may improve one value stream and degrade another. The VDML model will help the analyst identify and quantify these interactions. A VDML tool implementation may provide tabular displays or reports to show the contributions of activities to particular value measurements and how they compare across multiple scenarios. 3.10 Highlight key capabilities Capability definitions will be captured in a VDML capability definition library for the enterprise (potentially an industry library may be available in the future as a starting point). The library defines a capability taxonomy so that more general capabilities can be defined as including more specific capabilities. An organization may be identified as having a general capability and then provide more specific capabilities with distinct capability methods. Page 20 / 39 Copyright NEFFICS Consortium 2010-2013

The consistent definition of capability semantics and terminology will help specify the capabilities that are needed by activities, it will help identify the capabilities that are available and the organizations that offer them, and it will help identify capabilities offered by multiple different organizations that might be considered for consolidation. Support for recognition of duplicated capabilities and analysis of potential consolidations is a primary objective of VDML. Figure 14 below, illustrates a capability map display that can be generated from a capability library. The analyst can highlight certain capabilities in the capability map (boxes shown with double borders) that should be targeted for improvement to provide a capability heat map for management presentations. The analyst can then navigate from the capabilities of the heat map to the capability management diagrams (e.g., Figure 11) and associated organization units. Admissions Nurse Laboratory Imaging Monitor Obstetrician Obstetrics Nurse MedicalSvcs. ReportStatus ERPhysician Pediatric Nurse ERNurse Nursing ER Administrator Admissions Administrator Administration Install Devices Maintain Devices Medical Monitoring Pediatrician Anesthesi ologist Physicians Services Healthcare Figure 14, Capability Map 3.11 Analyze activity dependencies This final analysis phase is not necessary for this use case, but it is included to illustrate potential support for additional analysis of a value stream. The tabular display is not required by the current VDML specification but can be provided by an implementer of the specification. We have described three complementary and partially overlapping views of the high-risk pregnancy value stream: the value proposition exchange, the role collaboration network and the capability method activity networks. The value proposition exchange provides a high-level, business entity abstraction as a context for the more detailed views. The role collaboration diagram shows the dependencies associated with deliverables exchanged between roles for the value stream of interest. The activity network diagrams depict the dependencies between activities including dependencies between activities of the same role along with capabilities, value contributions and stores. Business analysts may tend to focus on the deliverables that have a direct impact on when a subsequent activity is enabled. There may be other activities, performed later, that are also dependent on some of the same deliverables but these may be overlooked because the deliverable does not appear to constrain the start of the later activity. Table 2, Activity Dependency Table (a non-normative Copyright NEFFICS Consortium 2010-2013 Page 21 / 39

VDML view) makes dependencies easier to identify and analyze, and it supports further business design analysis. It shows activity dependencies for the Doctor s Office Visit capability method and the Initiate Monitoring capability method that it engages. Activities and stores, as nodes in the network, are listed in the center column. The columns to the left of the activities indicate the role associated with each activity. The columns on the right of the activities indicate the input and output deliverables. If the deliverables are in an appropriate sequence, the inputs to each activity will be to the left of the outputs, and for each deliverable the deliverable as output will be in the same column and above the deliverable as input (outputs before inputs). The table includes the detail of delegation to the Initiate Monitoring capability method (between the bold borders); the activities are indented. This illustrates how the table could be used to refine a flat description of activities (without sub-collaborations), to carve out or redefine sharable capabilities like the Initiate Monitoring capability method. Table 2, Activity Dependency Table Roles Activities Deliverables Obstetrician OfficeAdministrator MonitorProvider information PaymentAuthorization Appointments(store) O X Provideinformation I O X Paymentauthorizationrequest I O X Describesymptoms I O X Examination I I O X Diagnosis I I O X Treatmentoptions I I I O X Selectionoptions I O X initiatemonitoring I O X Requestdevice IO O X Establishaccount I Monitoringdevices(store) O X Assigndevice IO I O X Installandtest IO IO sbeingmonitored(store) I X Provideinstructions IO IO X Treatmentplanning I I I O X Acceptplan I O X Schedulenextappointment I I O X Requesthospitaladmission I O NextAppointment(store) I adminssion(store) I Symptomsreported examinationresults Diagnosis TreatmentOptions Selectedoptions Monitoringrequest Monitoringdevice withmonitor TreatmentPlan PlanAccepted AdmissionRequest Doctor'sAppointment This tabular view helps the analyst evaluate dependencies of activities and grouping into subcollaborations. For example, the table indicates that Treatment planning could be performed before Initiate Monitoring. The tabular view also can be useful for recognition of dependencies in an as-is business system analysis where flows in the real world are less visible because information deliverables are posted to a shared file or database rather than physically travelling from one participant (role) to another. Page 22 / 39 Copyright NEFFICS Consortium 2010-2013

4 Insights on VDML Modeling This use case provides some useful insights on modeling with VDML. These are summarized in the following paragraphs 4.1 As-is analysis VDML has the flexibility to model a variety of business architectures. Most of the VDML model for this use case is a representation of an as-is business design. In this use case considering the full value stream in the Appendix A most of the methods are linked by flow-through of deliverables through stores. In a to-be business model there might be more use of delegation to shared capabilities. One capability method (Initiate Monitoring) was represented as a sharable service, and other sharable capabilities were implied by activities with capability methods that were not modeled. A capability method can be configured to be a sharable service and at the same time receive input(s) or send output(s) directly from/to other methods. 4.2 Value stream as scoping concept The concept of a value stream is important for defining the scope of an analysis as well as the scope of a value proposition. The value stream is essentially the elements linked directly or indirectly to the value proposition through value contributions and deliverable flows, including activity delegations to participating capability methods. Thus the linked value contributions, deliverable flows, activities and capability methods are in scope including values in value propositions of suppliers. These linkages may branch into multiple tributary methods and subordinate value streams to account for the sources of values expressed in the value proposition. 4.3 Importance of a tool Development and evolution of a VDML model is very difficult without an automated tool. In this use case, the multiple views provide useful insights and help the analyst clarify and complete the underlying model, but developing and maintaining consistent views is very tedious when there is not a shared, computer-based model to ensure consistency. As different views are considered, new information or discrepancies will be entered that must then be propagated to all affected views. 4.4 Importance of scenarios The ability to capture measurements that reflect different circumstances (scenarios) is essential for evaluation of alternative plans or solutions. VDML supports computation of resulting value proposition satisfaction levels, and the ability to trace back through the model to identify key sources of performance measurements, along with the ability to compare these measurements for different scenarios. In this use case, different scenarios support the capture and computation of value measurements for a variety of circumstances to be considered for evaluation of the impact of high-risk pregnancy monitoring. All of these can be created and analyzed using the same VDML value stream model but with different measurements for different scenarios. 4.5 Iterative refinement of model and measurements Support for iterative refinement of the model and associated measurements is essential because the analyst will gain understanding and the model will raise new questions as it is developed. For as-is models, the analyst will incrementally learn and capture the details and variations of current business operations. This was evident as this use case was developed and the need for additional roles, activities, deliverables and capabilities became apparent. For to-be models, the analyst will need to explore, evolve and evaluate alternative future configurations. 4.6 Limitation of scope A VDML model can include extensive detail about the design of a business. A complete VDML model of a business could take years to develop. Although such a model would continue to evolve and provide support for business analysis and design, most businesses will not make an initial commitment Copyright NEFFICS Consortium 2010-2013 Page 23 / 39

to such an undertaking. In order to realize benefits with reasonable investment, the scope of each undertaking must be well-defined as was done in this use case. These limited scope models can be integrated and built-upon to develop a more comprehensive model over time. This use case provides an example of limited scope by avoiding detailed models for methods that are not affected by the initiative, and by focusing only on relevant measurements to support comparison of value propositions. 4.7 Profession as capability This use case illustrates how each profession can be treated as a capability to fill roles in multiple activities that call for that professional capability. That simplifies this model. In most cases, a participant can have multiple capabilities and a role may perform multiple activities that require different capabilities. A role assignment must ensure that the participant has all the capabilities required by the role. VDML supports representation of those requirements. Dynamic assignment of participants to roles requires a simulation capability that is beyond the scope of this version of VDML. 4.8 Participation by contractors In this use case, doctors are members of independent business entities but perform activities within the hospital. In a VDML model, services that are outsourced may be treated fundamentally the same as internal services through delegation from an internal activity. However, the use of contractor personnel cannot be addressed in the same manner since these individuals will be assigned to internal roles to perform activities. Thus the contractor business relationship may be established and maintained as an exchange between business entities, and the personnel and outsourced capabilities will be provided as capability offers to be assigned to roles. As a consequence, the contracting entity functions much like an internal organization unit that is responsible for management of capability offers and pools of available personnel. This use case illustrates those relationships. 4.9 Typical value computations While we do not include the value computations in this use case, it is fairly evident that specification of some computations, such as risks, could require some special skills. Business analysts may be inhibited by the need to come up with these value computations. VDML tool vendors should provide typical computations as part of their deployment package to give analysts useful initial computations. The analyst can refine these as s/he gains a better understanding of the business situation and the VDML model. 4.10 Accounting for exceptions This use case does not draw attention to various exceptions that can occur during the treatment of a medical condition. That is a result of the assumption that treatment of the condition of interest will be fundamentally the same independent of the exceptions, and the effects of exceptions can be incorporated in the statistical measurements of values. Where there are statistical variances as a result of exceptions, these can be reflected in the value measurements of different scenarios. 4.11 Concurrent and repetitive activities In some cases, a value stream may include an activity that is repeated numerous times for a unit of production, either autonomously or within the context of a repeated method. The VDML model should not represent individual occurrences, but rather should capture the statistical measurements appropriate to the net effect of the multiple occurrences on the activity element. This was characteristic of both the Doctor s Office method and the Gestation method. The goal is to develop statistical measurements, not to depict the specific occurrence of activities in the course of treatment of a particular patient. 4.12 Activities over multiple shifts This is similar to the above observation regarding repetitive activities. For example, in this use case, nursing care occurs 24-hours a day, seven days a week. The activity is performed by different people on different shifts. For this analysis it is only necessary to represent the net measurements of the Page 24 / 39 Copyright NEFFICS Consortium 2010-2013

contributions of all the performers of the activity over the time period in which nursing care was provided for the patients within the scenario. In a more detailed model, if personnel resource requirements are a concern and if different skills can be required for different patient services, then this activity might be replaced with multiple activities or delegation to a capability method that details out the more specific activities and required capabilities. Copyright NEFFICS Consortium 2010-2013 Page 25 / 39

Page 26 / 39 Copyright NEFFICS Consortium 2010-2013

Appendix A, Use Case Capability Methods This Appendix presents the set of activity diagrams for this use case, beginning with the Maternity Care Business Network activity diagram. The scope of analysis of these activity networks is appropriate for analysis of the impact of monitoring high-risk pregnancies. A fully developed VDML model for this value stream would capture the value measurements associated with these activities, provide the computations for patient satisfaction for the values and for the weighted overall level of satisfaction and include the details of additional capability methods that are referenced in activity delegations. The measurements were not developed for this use case due to a lack of access to empirical data and the complexity of developing that level of detail without a VDML tool. The following methods are discussed in the paragraphs that follow: Figure 15, Maternity Care Business Network Activity Diagram Figure 16, Visit to the Doctor's Office Capability Method Figure 16, Visit to the Doctor's Office Capability Method Figure 17, Gestation Capability Method Figure 18, Emergency Room Care Figure 19, Maternity Care Method Figure 20, Admissions Capability Method Figure 21, Maternity Ward Care Figure 22, Operating Room Capability Method Figure 23, Mother Recovery Care Figure 24, Child Recovery Care Figure 25, Initiation of Monitoring Capability Method Figure 15 defines the business context with the activities performed by the business entities: the Client (the economic role of the patient), the Doctor s Office (the economic entity of a doctor or group of doctors in the community) and the. Except for the Client activity, the other activities delegate to collaboration methods defined in the following paragraphs. Client Obtain Maternity Care Doctor s Office Appointments Visit Doctor s Office Monitoring Reports Monitor Gestation Emergency s Handle Emergency Monitored s Monitor Admission Requests Provide Maternity Care Figure 15, Maternity Care Business Network Activity Diagram Copyright NEFFICS Consortium 2010-2013 Page 27 / 39

In this use case, a pregnant woman may first be seen by an Obstetrician for treatment related to her pregnancy (Figure 16), or she may arrive at a hospital emergency room due to problems with her pregnancy or other health concerns (Figure 18). In either case, she may subsequently go either into the hospital or schedule a later appointment with her obstetrician. While the patient is with the obstetrician (Figure 16), she will be examined, and, if she is deemed to be at high risk, the doctor my recommend remote monitoring of her pregnancy. Monitoring will provide for timely detection of significant changes in her condition or the condition of the fetus and avoid repeated trips to the doctor s office for follow-up examinations. In this case, the patient will acquire a monitoring device through delegation to the capability method of Figure 25. Note that office visits and other activities during gestation may occur multiple times for the pregnancy of one patient, so each measurement may reflect multiple occurrences for that patient. In other words, the unit of production is patient care for one pregnancy, so the measurements reflect averages over multiple patient pregnancies. Office Administrator Obstetrician Appointments Examination Provide information Payer info Payment Auth Results Symptoms Authorization Diagnosis Diagnosis Describe Symptoms Treatment Options Options Select Options MonitorRequest Treatment Planning Selections with Monitor Plan Request Admission Accept plan. Schedule Next Appt. Acceptedplan Appointment Request Admission Request Monitor Provider Initiate Monitoring Figure 16, Visit to the Doctor's Office Capability Method Page 28 / 39 Copyright NEFFICS Consortium 2010-2013

s Report Symptoms Office Appointment s Obstetrician Periodic Examination Report Send to Emergehcy Request ization Emergency s Admission Request Ultrasound Technician Ultrasound Report Monitor Provider Monitored s Monitoring Figure 17, Gestation Capability Method During gestation, the Gestation capability method of Figure 17, above, responds to changes in the condition of the patient or fetus. The patient is on her own and may obtain ultrasound tests for evaluation by the doctor. The doctor will receive monitoring reports and alerts. Examinations by the doctor, either routine or in response to a monitoring concern, may result in the patient going to a hospital emergency room or to the hospital for admission. The Monitoring activity is on-going for the duration from installation of the monitor until hospital admission. In some cases a pregnant patient may come to the hospital emergency service as an initial contact (before an office visit) or during the course of her pregnancy if she experiences problems. Emergency room activities are depicted in Figure 18. Triage will determine how quickly the problem is addressed. The ER physician will determine a treatment plan, provide emergency treatment, and the patient will either be admitted to the hospital or be scheduled for an office visit. Copyright NEFFICS Consortium 2010-2013 Page 29 / 39

Emergency s Report Symptoms Schedule Doctor Appointment Doctor s Appointment ER Nurse record Triage Provide Emergency Treatment. ER Physician Authorizationrequest Examination Diagnosis Plan Treatment. plan ER Administator Payment Auth Admission. Admission Request Figure 18, Emergency Room Care Capability Method s with high-risk pregnancies may be more likely to use emergency services. On the other hand, the use of remote monitoring may reduce the use of emergency services, including false alarms, below that for normal pregnancies. Scenarios should reflect the differences in utilization of emergency services. Admission Requests Mother Recovery Hospi ta Admission PreDelivery Operating Room Child Child Recovery Figure 19, Maternity Care Method The method of Figure 19 defines the high-level activities of maternity care in the hospital. It is engaged by delegation from the Provide Maternity Care activity of the business network (Figure 15). These activities, in turn delegate to the methods in the following paragraphs. When the patient arrives at the hospital, she must go through an admission process. Figure 20, includes authorization for payment, a physical examination and assignment to a maternity ward bed. Page 30 / 39 Copyright NEFFICS Consortium 2010-2013

Admission Requests Travel to Monitor Provider Return Monitor Monitor Monitoring Devices Admissions Admin Capture Information Payment Auth. Assign Bed Transport Waiting forbed Admissions Nurse Physical Exam Figure 20, Admissions Capability Method If she is a monitored high-risk pregnancy patient, the monitoring device is returned. The details of this are not expanded here since they should always be the same if a monitor is used and should have zero effect if a monitor is not used. The Return Monitor delegating activity can capture the measurements associated with the delegated capability method. Obstetrics Nurse Obstetrician swaiting ForaBed Admit patient to ward Identify cooccuring conditions Referral Examine Birth Status Scheduled Nursing Care Schedule Operating Rm Waitingfor Operating Room Consulting Physician Specialistsin cooccurring conditions Physician Consultation. Instructions Figure 21, Maternity Ward Care Capability Method On the maternity ward, Figure 21, consultation will be arranged for any co-occurring conditions, and the status of the birth process will be monitored. These activities may occur multiple times before the patient is ready for delivery (the operating room), so the measurements should reflect the statistical number of occurrences for a typical patient. Nursing care may be considered an on-going activity for the period in which the patient is on the maternity ward. Consultation is not modeled in detail, but if there are relevant differences in the measurements for different pregnancies, then these differences should be captured in the measurements on the Consultation activity for associated scenarios. Figure 22, Operating Room Capability Method, depicts activities in the operating room. The obstetrician will be supported by nurses and an anesthesiologist. If the obstetrician determines that a Copyright NEFFICS Consortium 2010-2013 Page 31 / 39

Cesarean birth is necessary, then a surgeon is engaged. Following the birth, the mother and child are moved to respective recovery care facilities. The frequency of occurrences of Normal and Cesarean births may depend upon the use of remote monitoring. For example, the obstetrician may determine that the risk of waiting for a natural childbirth is mitigated if the patient is being continuously monitored. Obstetrics Nurse Obstetrician Anesthesiologist Pediatrician Waitingfor Operating Room Examination Address Special Needs Delivery mode decision Administer Anesthetic Decision Natural Birth. Child /Mother Child Record Birth Record Mother Care Child Care Child Mother Recovery Child Recovery Surgeon Cesarean Section Figure 22, Operating Room Capability Method During recovery of the mother, Figure 23, Mother Recovery Care Capability Method, below, the mother may hold and possibly nurse the child. The mother receives nursing care and her condition is monitored. The duration of recovery and thus the number of occurrences of other activities will vary. Nursing care will be continuous during the recovery period. The details of nursing care need not be modeled unless there are services that would be unique or more intense based on the use or non-use of remote monitoring. Different scenarios may associate different measurements with the Scheduled Nursing activity if they are related to the use or non-use of remote monitoring. Page 32 / 39 Copyright NEFFICS Consortium 2010-2013

Obstetrics Nurse Mother Recovery Newborns Child Hold/Nurse Child Scheduled Nursing. Check Vital Signs Report Report Report Symptoms Report Recovery Time Discharge Home Obstetrician Recovery Status Exam Figure 23, Mother Recovery Care Capability Method During recovery of the child, Figure 24, Child Recovery Care Capability Method, the child will receive nursing care and monitoring as well, but the child will also undergo tests and treatment for special conditions and possible preventive treatment. Home Pediatrician Pediatric Nurse Newborns Child Child Scheduled Nursing. Laboratory Tests. Check Vital Signs Child Report Preventive Treatment. Recovery Time Report Report Child Child Recovery Status Exam Report Take Child Home Child Prepare for discharge Report Discharge Report Child Figure 24, Child Recovery Care Capability Method Both the patient (mother) and child are discharged to go home, but not necessarily at the same time. The Initiate Monitoring capability method (Figure 25) is the only detailed capability method in this use case that is engaged by delegation. The bottom-left pyramids represent entry and return from delegation in the parent Initiate Monitoring activity of the Doctor s Office collaboration or possibly other delegating activities. These activities reflect costs and other measurements associated with the initiation of monitoring. Copyright NEFFICS Consortium 2010-2013 Page 33 / 39

Request Device Accept Device Monitor Provider Request Establish Account. Request Assign Device Monitor Install & Test Provide Instructions Monitoring Devices Monitored s Figure 25, Initiation of Monitoring Capability Method Page 34 / 39 Copyright NEFFICS Consortium 2010-2013

Appendix B Table 3, Role Collaboration Table for Maternity Care This table depicts the flow of deliverables between roles for this use case. The rows correspond to the arcs of the role collaboration diagram of Figure 26 on page 37. Tangible deliverables are those that are formally recognized, and intangible deliverables are those that are ad hoc and are not identified in operating procedures. The sequence is not strict, but deliverables should not precede deliverables that they depend upon. Deliverable RoleFrom RoleTo Type 1 Appointment Officeadministrator Tangible 2 Officeadministrator Tangible 3 Officeadministrator Obstetrician Tangible 4 Authorizationrequest Officeadministrator Payer Tangible 5 Authorization Payer Officeadministrator Tangible 6 Symptoms Obstetrician Tangible 7 Treatmentoptions Obstetrician Tangible 8 Monitorprovider Tangible 9 Monitorprovider Obstetrician Tangible 10 Treatmentplan Obstetrician Tangible 11 Nextappointment Officeadministrator Tangible 12 admissionrequest Obstetrician Tangible 13 admissionrequest Obstetrician Admissionsadministrator Tangible 14 Reportsymptoms ERNurse Tangible 15 ERNurse ERadministrator Tangible 16 ERadministrator ERphysician Tangible 17 PaymentAuthRequest ERadministrator Payer Tangible 18 Authorization Payer ERadministrator Tangible 19 Symptoms ERNurse Tangible 20 ERNurse ERphysician Tangible 21 Symptoms ERPhysician Tangible 22 Treatmentplan ERphysician ERNurse Tangible 23 Doctor'sappointment ERnurse Tangible 24 admissionrequest ERnurse Admissionsadministrator Tangible 25 Emergencytreatment ERnurse Tangible 26 Doctor'sappointment Officeadministrator Tangible 27 Reportsymptoms Obstetrician Tangible 28 Requestultrasound Ultrasoundtechnician Tangible 29 Ultrasoundresults Ultrasoundtechnician Obstetrician Tangible 30 Monitoringresults Monitorprovider Obstetrician Tangible 31 Requestization Obstetrician Admissionsadministrator Tangible 32 Sendtoemergency Obstetrician ERAdministrator Tangible 33 Admissionsadministrator Tangible 34 Monitoringdevice Monitorprovider Tangible 35 Admissionsadministrator Admissionsnurse Tangible 36 Examinationresults Admissionsnurse Admissionsadministrator Tangible 37 Admissionsadministrator Obstetricsnurse Tangible Copyright NEFFICS Consortium 2010-2013 Page 35 / 39

38 Obstetricsnurse Obstetrician Tangible 39 records Obstetrician Consultingphysician Tangible 40 Cooccurring treatment Consultingphysician Obstetrician Tangible plan 41 condition Obstetricsnurse Obstetrician Tangible 42 Obstetrician Obstetricsnurse Tangible 43 Obstetrician Anesthesiologist Tangible 44 (anesthetized) Anesthesiologist Obstetrician Tangible 45 Obstetrician Surgeon Tangible 46 Child Surgeon Pediatrician Tangible 47 Birthrecord Obstetrician Pediatrician Tangible 48 (mother) Obstetrician Obstetricsnurse Tangible 49 Obstetricsnurse (mother) Tangible 50 Vitalsigns Obstetricsnurse Obstetrician Tangible 51 Dischargereport Obstetrician Obstetricsnurse Tangible 52 (child) Pediatrician Pediatricnurse Tangible 53 (child) Pediatricnurse Pediatrician Tangible 54 Recoverystatus Pediatricnurse Pediatrician Tangible 55 Dischargereport Pediatrician PediatricNurse Tangible 56 (child) Pediatricnurse (mother) Tangible 80 Symptoms Monitorprovider ERPhysician Intangible 81 Symptoms ERAdministrator ERNurse Intangible 82 Anomalies Monitorprovider Intangible 83 Requestassistance Pediatrician Obstetricsnurse Intangible 84 Assistance Obstetricsnurse Pediatrician Intangible 85 Requestassistance Surgeon Obstetricsnurse Intangible 86 Assistance Obstetricsnurse Surgeon Intangible 87 Symptoms Admissionsnurse Obstetricsnurse Intangible Page 36 / 39 Copyright NEFFICS Consortium 2010-2013

Appendix C, Maternity Care Value Network The diagram, below depicts the exchanges between deliverables for all roles in the maternity care value stream. This diagram is complex, but provides insights into the links between the roles and may reveal deliverables that are either intangible or would improve the overall collaboration. By removing the organizational boundaries, the analyst can consider changes that might require reorganization. 4 Monitor provider 80 9 30 5 Office admin 3 82 28 Ultrasound technician 29 43 Anesthesi ologist 17 Payer 23 25 ERnurse 81 22 21 8 23 34 14 19 1 2 26 11 6 12 27 10 42 7 Obstetrician 47 85 44 45 46 Surgeon 86 18 24 15 ER administrator 20 32 16 33 ER Physician 21 31 13 Admissions admin 49 36 41 38 50 51 48 Obstetrics nurse 37 35 87 Admissions nurse 84 40 83 39 Consulting physician Pediatrician 52 54 55 53 56 Pediatric nurse Figure 26, Maternity Care Network Copyright NEFFICS Consortium 2010-2013 Page 37 / 39

Appendix D, Glossary Activity. Work contributed to a collaboration by a participant in a role of the collaboration. A role may contribute to multiple activities in the same collaboration (source: VDML; example of use of term outside VDML: Osterwalder(2004)). Actor. An individual (indivisible) participant, which might be human (a person) or non human (e.g. a software agent or machine) (source: VDML; example of use of term outside VDML: Gordijn and Akkermans (2003)). Analysis Context. An analysis context defines a set of measurements associated with a particular use of a collaboration or a store used as a decoupling point between collaborations. When an activity delegates to a collaboration, an analysis context defines the delegations of activity inputs and/or outputs to/from collaboration inputs and/or outputs, and may define assignments of roles within the collaboration (source: VDML). Business Item. A business item is anything that can be acquired or created, that conveys information, obligation or other forms of value and that can be conveyed from a provider to a recipient. For example, it includes parts, products, units of fluids, orders, emails, notices, contracts, currency, assignments, devices, property and other resources (source: VDML). Business Model. A business model describes the rationale of how an organization creates, delivers, and captures value (source: Osterwalder and Pigneur (2010)). Business Network. A collaboration between independent business (or economic) entities, potentially companies, agencies, individuals or anonymous members of communities of independent business entities, participating in an economic exchange (source: VDML; example of use of term outside VDML: Vervest et al. (2009)). Capability. Ability to perform a particular kind of work and deliver desired value (source: VDML; examples of use of term outside VDML: Osterwalder(2004),SoaML (2012), ITIL (2011)). Capability Method. A reusable template for a collaboration configured for participants to perform activities to deliver a capability and to contribute value (source: VDML). Channel. Mechanism to execute a deliverable flow, such as e-mail, face-to-face conversation, SOAP, REST, physical transportation, postal service, telephone, fax, FTP, etc. Characteristic. Distinguishing feature or quality that can be qualified or quantified by applying a measure (source: popularized version of definition in SMM (2012)). Collaboration. Collection of participants joined together for a shared purpose or interest(source: VDML; examples of use of term outside VDML: SoaML (2012), BPMN (2011)). Community. A loose collaboration of participants with similar characteristics or interests (source: VDML; examples of use of term outside VDML: WeillandVitale(2001)). Delegation Context. A specialized Analysis Context, set by an activity and in which the activity delegates its work to a collaboration. A delegation context also defines the delegations of activity inputs and/or outputs to/from collaboration inputs and/or outputs, and may define assignments of roles within the collaboration (source: VDML). Deliverable. Product or service produced by an activity or delivered from a store that can be conveyed to another activity or store (source: VDML; example of use of term outside VDML: Allee (2008), ITIL (2011)). Deliverable Flow. The transfer of a deliverable from a provider (or producer) to a recipient (or consumer) (source: VDML). Intangible. Deliverable that represents something that is unpaid or non-contractual that makes things work smoothly or efficiently (as opposed to Tangible) (source: VDML; example of use of term outside VDML: Allee (2008)). Measure. A method that is applied to characterize an attribute of something by assigning a comparable quantification or qualification (source: popularized version of definition in SMM (2012)). Measurement. The result of applying a measure (source: popularized version of definition in SMM (2012)). Organization. An administrative or functional structure normally interpreted as a network of Organization Units at a higher level in an organizational hierarchy (source: VDML; ; example of use of term outside VDML: ITIL (2011)). Organization Unit (or: Org Unit). An administrative or functional organizational collaboration, with responsibility for defined resources, including a collaboration that occurs in the typical organization hierarchy, such as business units and departments (and also the company itself), as well as less formal organizational collaboration such as a committee, project, or task force (source: VDML; Page 38 / 39 Copyright NEFFICS Consortium 2010-2013

example of use of term outside VDML: Zachman framework, as introduced by Zachman (1987), and Sowa and Zachman (1992), though a formal definition of the term seems to be omitted). Participant. Anyone or anything that can fill a role in a collaboration. Participants can be actors (human or automatons) or collaborations or roles of actors or collaborations (source: VDML; example of use of term outside VDML: Allee (2008)). Pool. A store that contains re-usable resource, i.e. resource that is returned to the pool after having been used, so that it is again available for use (source: VDML; example of use of term outside VDML: PMBOK (2000)). Practice. Proven way to handle specific types of work and that have been successfully used by multiple organizations (source: VDML; examples of use of term outside VDML: BPMM (2008), ITIL (2011)). Process. A sequence or flow of Activities in an organization with the objective of carrying out work ( source: BPMN (2011)). Resource. Anything that is used or consumed in the production of a deliverable (source: VDML; example of use of term outside VDML: Hruby et al. (2006)). Role. An expected behavior pattern or capability profile associated with participation in a collaboration role participants working together with a common interest or purpose (source: VDML; example of use of term outside VDML: Allee (2008)). Scenario. A scenario defines a consistent business use case and set of measurements of a VDML model by specifying a, possibly recursive, analysis context for elements in scope of that use case. The nesting of contexts allows a collaboration to be used as a sub-collaboration by more than one activity, each of which sets its particular context and measurements (source: VDML). Service. A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description (source: SOA-RM (2006)). Store. Represents a container of resource. The resource that is received or provided is identified by a business item (source: VDML; common concept in data flow diagrams (DFD), also known as Gane- Sarson diagrams, as proposed and applied by Gane and Sarson (1979); common construct in simulation systems, such as GoldSim, as explained in GoldSim (2010, 1) and GoldSim (2010, 2); data store in BPMN (2011) is a similar construct, though with a more narrow meaning). Tangible. Deliverable that represents something that is contracted, mandated or expected by the recipient and which may generate revenue (as opposed to Intangible) (source: VDML; example of use of term outside VDML: Allee (2008)). Unit of production. The volume of work including the number of occurrences for any activity or deliverables that results in one unit of output for a collaboration. So if the end product is an automobile, then a unit of production will require 4 tires. If a patient, on average, requires ten blood draws during a course of treatment, then the unit of production is ten blood draws. Value. A measurable benefit of interest to a recipient in association with a business item (source: VDML; example of uses of term outside VDML: Brodie and Gilb (2010), Gilb (2007), Gilb and Gilb (2011)). Value Chain. Set of activities that an organization carries out to create value for its customers (source: Porter (1985)). Value Delivery Model. Model that supports business analysis and design based on evaluation of performance and stakeholder satisfaction achieved through the activities and interactions of people and organizations using business capabilities to apply resources and deliver stakeholder values (source: VDML). Value Network. Any set of roles and interactions in which participants engage in both tangible and intangible exchanges to achieve economic or social good (source: Allee (2008) ). Or: Any web of relationships that generates both tangible and intangible value through complex dynamic exchanges between two or more individuals, groups or organizations (source: Allee (2003)). Value Proposition. Expression of the values offered to a recipient evaluated in terms of the recipient s level of satisfaction (source: VDML; examples of use of term outside VDML: Ballantyneetal.(2008), Osterwalder (2004),Johnson et al. (2010)). Value Stream. End-to-end collection of activities that create a result for a customer, who may be the ultimate customer or an internal end user of the value stream (source: Whittle and Myrick (2005)). A network of activities that includes resources, value contributions and capabilities to determine a value proposition for a customer who may be the ultimate customer or an internal end user of the result (source:vdml). Copyright NEFFICS Consortium 2010-2013 Page 39 / 39