The business model that was developed for EAB Healthcare raised considerable concern with the development team. All of the various flows that were captured showing how the facility's external interfaces interacted with the facility's people and systems caused the specter of scope creep to haunt them. Fortunately, as mentioned earlier, through the close cooperation with the business people, the desire is to focus only on the parts of the business that use the clinical records. From the vision statement of the project, one of the major goals is to improve staff efficiency by reducing the volumes of paperwork that must be handled. The intent is to make EAB Healthcare a more efficient business.
Therefore, with this guidance in hand, the team begins to limit the scope of the effort. There is no need to model all the activities of the business actors when they are not interacting with the system. The business modeling also showed many reports are created as a result of numerous processes. However, these records are not handled with high frequency by many people and thus can be deferred to a later delivery. With these insights the development team now concentrates on keeping the scope of the project focused on the medical records that are constantly used, every day, by most of the staff. This focus motivated the developers to name the new system 揙MaR?for the Online Medical Records system.
This drives the team to conclude that the Accounts Receivable and Respond to Inquiry business use cases should be deferred to a later delivery. This allows the development effort to focus on the business use cases with higher value: Comply with Regulations, Manage Clinical Records, and Provide Clinical Care (Table 4-2).
Unfortunately for the members of the development team, they do not have the advantage of having textual specifications for the system they are to build. They are working in an industry (elder care) that does not traditionally embrace such discipline and typically does not have the budget to develop such specifications. So OMaR's requirements will be elicited using a use case approach. The resulting requirements will take the form of use cases, use case models, and whatever supplemental documents the team can obtain.
Beginning with the Comply with Regulations business use case, the team starts the transition to the system use case model. Looking at the business use case model Provide Resident Care (see Figure 3-6), you can see the three business actors Data Broker, Government Agency, and Corporate Auditor interact with the Comply with Regulations use case and must be brought into the system use case model. However, the Government Agency and Corporate Auditor were generalized as an Investigator business actor (see Figure 3-20). So initially, the Investigator and the Data Broker will be included in the system use case model.
In the original activity diagrams for Comply with Regulations two business actors are cited: the Medical Records Manager and the Government Agency. In dealing with compliance, most of the interaction with the Government Agency really falls to the Nurses and the Administrator of the facility. Therefore, these two business workers will appear in the system use case model instead of the more generic Facility Staff. Also, since the Government Agency is only one type of Investigator, the more general Investigator actor will be used here (see Figure 4-1a and 4-1b).
The only function of the Medical Records Manager in this scenario is to provide access to the records. This is where the development team begins the process of automating the functions of the Medical Records Manager. Thus, the Medical Records Manager will not move into the system use case model, but the activity performed, providing access to the clinical records, will appear as a new use case, Access Clinical Records. Further examination of the activity diagrams for this business use case shows many other activities, but they are operational activities that the external actors perform manually (for example, Interview Staff, Inspect Facility). Therefore, no other activity will be brought over to the system use case diagram. This leads to the simple use case diagram shown in Figure 4-2.
Turning to the business object model for Comply with Regulations (Figure 4-3) we see many different entities here. Before just bringing them into the system use case model, let's remember the focus of this development梞edical records that are constantly used, every day, by most of the staff. Examining the various sequence diagrams for this model (see Appendix A, Figure A-17 through A-24), the team concludes that the sequences for Review Compliance, Accreditation, and Investigate Concerns mostly fall into three categories: operational activities, completely external activities, and activities that do not require any significant Clinical Records support (many of the report entities are not part of the Clinical Records). Therefore, these will be scoped out to a future delivery (Table 4-3).
Why look at the sequence diagrams for this scope and prioritization exercise? The activities depicted in these sequences are eventually going to find their way into one or more system use cases (possibly as main flows, alternate flows, error conditions, and so on), as discussed previously. Rather than wait for all the use cases to be fully defined and elaborated, we can do an early assessment. Thus, we avoid doing all that work to define things we are not going to develop.
This leaves the three sequences to Establish, Maintain, and Transmit the Minimum Data Sets (MDSs). These fit the criteria for the current focus of the project very well since the MDSs are the centerpiece documents around which compliance revolves. Examining these sequences leads us to bring these key activities, performed by the business workers, into the system use case diagrams as new use cases: Establish MDS, Maintain MDS, and Transmit MDS (Figure 4-4).
Now the team continues along the same line with the other business use cases: Manage Clinical Records and Provide Clinical Care. Manage Clinical Records is absolutely central to the functioning of the system. Therefore, all the aspects of this business use case will be included in the current delivery. This business use case primarily defines the functions the Medical Records Manager performs. The other actors involved merely provide or receive information. Since the Medical Records Manager's functions are targets for automation, many of these functions become 搑eassigned?to new use cases, new actors, and the Medical Records Manager. Simple ones such as the transfer of records manifest in the system use case model as Access Clinical Records and Update Clinical Records use cases. More complex functions, such as the management of the closure and destruction of records, according to the business rules specified, become Manage Records, Close Clinical Records, and Destroy Clinical Records use cases. The development team also has created some use cases that were overlooked in the business modeling but became apparent during requirements definition (Create Clinical Records, Unarchive Clinical Records, and Verify Security Permission). The resulting system use case model is shown in Figure 4-5.
|Investigate Concerns||Medium||Second||Mostly external/minimal support needed|
|Review Compliance||Low||Second||Minimal support needed|
The database designer should take note of the significant business rules that are expressed in the sequence diagrams that have to do with MDS processing:
These are critical aspects of a key part of the Clinical Records that require special attention due to the volume and frequency of access such business rules imply. This allows you to start planning performance considerations into your system early.
Also, the 搘innowing out?process that the team is going through to prioritize and control the scope of the project allows you to focus on the critical business entities (for example, MDS, Clinical Records) and establish a solid core database. These are the use cases that must be paid great attention. You can leave the less critical data (for example, Case Mix Index Report) for subsequent deliveries.
A new actor (Clinical Records User) was added to represent all the various users of the Clinical Records. A more interesting actor (Time) was added to de pict the passage of time, which is critical to some of the functions performed (for example, Manage Records).
The team notes an interesting outcome of this analysis. The Manage Clinical Records use case (Figure 4-5) can also fulfill the needs expressed in the Respond to Inquiry business use case (Figure 3-10). The only part of Respond to Inquiry that needs system support is the access to the Clinical Records. (The role played by the Facility Staff will be fully automated in the new system.) As can be seen in Figure 4-5, access is provided via the Clinical Records User actor. We merely have to add the Inquirer to the Clinical Records User hierarchy. (This change also simplifies the Provide Clinical Care use case diagram, in which the Clinical Records User can now replace numerous actors.) Therefore, Respond to Inquiry is subsumed by Manage Clinical Records and does not need to be developed separately.
When the team applies the new focus on the Provide Clinical Care business use case, most of it survives. This business use case already centers on some of the most critical business entities梩he Care Plan and Treatment (Table 4-4).
When the team brings model elements from the business use case models and business object models into the system use case model, eliminating the elements that are not part of the Clinical Records or are external to EAB (deferring these to subsequent deliveries), the results are shown in Figure 4-6.
|Establish Care Plan||High||First||Critical|
|Update Care Plan||High||First||Critical|
|Provide Services||Low||Third||Mostly external|
Consider what has been accomplished during the business modeling and requirements definitions phases to this point. The team has defined various actors. Most of these actors represent the roles people perform. The specification of roles is important for the database designer when security is considered. While this is usually a consideration during physical database design, since we are using the UML, these roles (and the entities they access) are defined much earlier in the life cycle.
In fact, once the team develops the business and system use case models, what have really been defined are the various 搖ser views?Also, since these business model elements migrate into the system use case model, what is actually happening is the integration of all the user views into one common conceptual view. This integrated view is an extremely valuable result of the development process, especially when these models are developed in conjunction with the application developers. This not only provides the database designer an excellent foundation upon which to develop a quality database but it also gives everyone on the team a shared understanding. This common understanding between application and database developers usually never materializes during more traditional development processes.
Proceeding in this fashion (that is, merging the business models into the system models) using the UML also gives the database designer a relatively straightforward way to proceed in these early phases and yields valuable results. Typical guidance given for gathering the user's requirements often is very simplistic梩alk to the users or watch what the users do on the job or send out questionnaires and job surveys and so on. Then what? Often the designer is left to just shuffle all this raw information together in some form. Using the UML as has been done here gives you a simple, standard way to proceed and represent this important information.
This is a surprisingly simple use case diagram. This is because actors that are higher up in the actor hierarchy represent many of the actors (for example, External Care Provider, Internal Care Provider) and most of the activities (use cases) performed by the actors are simply accessing and updating the records. The actual medical treatments are operational activities that make up much of what these actors do. However, it is only the results of the operational activities that are captured by OMaR.
You may note in Figure 4-6 that one of the use cases is annotated ?from Included Use Cases).?This merely indicates that we have put some use cases into their own package (Included Use Cases) because they are included in many different use case diagrams.
Each of the system use cases must be elaborated in further detail. This can be done with a relatively simple use case template (Figure 4-7).
There are many different variations on this type of template. Tailor it to your own needs, but don't make it so formal as to make it cumbersome to use. Most of the fields in the sample use case template are self-explanatory. Keep the use case purpose brief梩hree to five sentences. Preconditions are conditions that must be true for the use case to execute. Postconditions are important conditions that are true after the use case basic flow is executed. The basic flow elaborates the steps followed in a successful execution of the use case. These steps can also indicate where 揺xtended?or 搃ncluded?use cases are executed. The alternate flows elaborate alternate paths that are followed when the triggering condition is true. These alternate flows augment the basic flow. For example, when the triggering condition occurs, the basic flow of the use case changes from steps A, B, C, and so on to steps A, B, B1, B2, B3, B4, C, and so on. An example can be seen in Figure 4-8.
Each system use case should have its own use case description. But as we've warned before, beware of analysis paralysis梩he condition where you attempt to analyze every possible part and variant of the system and thus never complete the analysis and move forward in the project. There are probably a nearly infinite number of conditions that could trigger an alternate flow. So how many do you examine? We can confidently give the definitive answer梚t depends. It depends on many factors, such as the criticality of the use case, the level of domain knowledge of the development staff, and whether the software run attended or unattended, local or remote. Is it a real-time system with failure conditions that are catastrophic or trivial? You could go on for days defining every alternate path for every minute error condition, but that is not the intent.
For candidate conditions that could trigger alternate paths, some items to consider include
Interfaces.? What if an interface to/from another part of the system does not provide what is needed for this use case?
Time.? What if things happen sooner or later than expected?
Hardware.? What if a key component fails? What if its backup fails?
Critical processing.? What if the security capabilities fail?
Availability.? What if data, hardware, or some other critical item is not available to the use case?
Does this mean you should have alternate paths for each of these? No. If they are important to your system, add them. Leave the trivial error processing for the developers to handle. As a final test, ask yourself, 揇o I really understand the behavior of this use case??/p>
At this point in the case study, the development team realizes they still need a great deal of business user input to fully develop the use case descriptions. Also, since the business users are going to have to approve the descriptions anyway, the team decides to invest in a bit of use case training for the business folks. They hold a two-day workshop where everyone learns the basic use case symbols (not the entire UML), the proper use of the use case description template, and a few exercises. At the end of this workshop, the business people can write a use case description as well as the developers. Since the business people know their business and know what they want better than the development team does, the group decides that the business people will write the use case descriptions. This is more efficient since it eliminates 搕ranslation?errors by the development team and eliminates additional unneeded review and correction cycles. See Appendix B for OMaR's use case descriptions.
There is one caveat when pursuing this direction. Some of the business folks may really get the hang of modeling and may become very 揷onfident?in their abilities. As you proceed further into analysis and design you must enforce the rule that only the designers model. Business people direct what the system must do, focusing on the business level flows of control and data (stopping at the system boundary). The designers and implementers determine how these capabilities are modeled and implemented, respectively. Allow this rule to be broken and you risk your system due to models that may be semantically incorrect.