The Design

From the problem statement provided and interviews with numerous staff people at EAB Healthcare, it became apparent that the company's goal is not to re design all of the business processes. We are not doing Business Process Reengineering. The business people want to focus only on those parts of the business that use the clinical records. As a result, in the business model, you won't see the human resources, facility maintenance, accounts payable, or other key business processes at EAB. The focus is on the main process of the business ”providing resident care.

The Business Use Case Model

The first part of the business model is the business use case model, which focuses on how the business is viewed by external actors and their interactions with the business. The external actors, which can be people or systems, are known as business actors. One of the earliest discussions with EAB was to identify these business actors. The results are shown in Figure 3-5.

Figure 3-5. Overview business use case model for EAB Healthcare

This business use case model shows the business actors (the stick figures with slashes), the business use cases (the ovals with slashes ), and the associations between them (the arrows). It is a very simple model showing which business actors interface with (that is, use) which business use cases. Once again we must stress the importance of keeping the modeling effort in context. These obviously are not all the actors that participate in some way to render resident care. For example, Ken, who works in the kitchen, provides a form of resident care. However, he is not involved with the clinical records system in any way. Therefore, he is not included in this model.

Each of these business actors has a textual description in the model. Some are self-evident, such as Physician , Chaplain, Insurance Company, and so on. Some are not, such as Data Broker (a contractor to government agencies who provides various data analysis functions) and Resident (whom laypeople would call the patient ”the person receiving the wonderful care EAB provides). The Resident is interesting; we have represented this actor in the model as a business actor. This implies the Resident is external. But since this is a person who lives in the EAB Healthcare facility, it would seem natural to consider this actor to be internal ”and this would be incorrect. The Resident does use the system, as we shall see later. Also, EAB does provide services to the Resident. The Resident actor is indeed external ”a business actor.

Whether or not these business actors' definitions are self-evident to the business people with whom you are working, each business actor should be given a definition. The people who eventually build this system may not have a full understanding of what these self-evident business actors are or do. Even the most seemingly obvious actors may need some explanation. For example, the Physician in this model is external to EAB. This is not to imply that EAB has no physicians on staff. Some will and some will not be on staff. However, the status of their employment is not the issue here. The Physicians are external users of the business system modeled here. For example, a Physician may request a Resident's clinical records. An internal worker, the Medical Records Manager, may fulfill this external request. Such key distinctions need to be captured.

Finally, notice that the model in Figure 3-5 is referred to as an overview business use case model [Jacobson et al. 1995]. This is because the use case Provide Resident Care represents a huge business function with many different business processes. Provide Resident Care will actually be realized by a number of other business use cases that are more limited in scope. Note that this does not imply functional decomposition. This is merely a higher level of abstraction that allows us to understand the overall context.

So what are the business use cases that realize Provide Resident Care? Further discussion with the EAB staff yields over 30 potential business use cases. That number is far too high for this one part of EAB's overall business, so we have to WAVE some away. That is, we apply the following tests:

W	Does the use case describe W hat to do and not how?
A	Is the use case described from the A ctor's viewpoint?
V	Does the use case include V alue for the actor?
E	Is the flow of events an E ntire business process?

Many of the initial business use cases that come up during discussion are merely one or two steps in a longer process. We include these in larger business use cases. Some are minor variants of the same actions. These we make common to be used by other business use cases. The ones that had no or little value are either deleted or added to other business use cases, respectively. Those that are focused on systems or implementation, instead of one or more actors, are eliminated. The results are shown in Figure 3-6.

Figure 3-6. Business use case model to Provide Resident Care

Here we see a more refined and manageable view of the business. Also, during this activity, new business actors are added ”Transport Service (companies that provide transportation of the Resident, and clinical records, to and from the EAB Healthcare facility) and Inquirer (someone inquiring on the condition of the Resident). This kind of discovery happens often in iterative design. This is not a sign of omission but a sign of gaining a deeper understanding of the business.

The Provide Clinical Care business use case is the process of providing day-to-day medical care for the residents. The Accounts Receivable business use case is a billing function that uses the clinical records to determine the amount of reimbursement owed to the facility. Comply with Regulations is the business use case that EAB must perform in order to have government approval to operate as a business. (This is a critical business process. The staff actually spends as much time handling all the paperwork to ensure compliance as they do providing medical care to the Residents.) Manage Clinical Records is the record management and maintenance business process. Respond to Inquiry is the constant process of the staff answering questions about the Residents and the care they are receiving. All of these business use cases must be performed properly as part of Provide Resident Care (the overview business use case).

To complete the business use case model, we must elaborate the business flow in each of the business use cases. Activity diagrams depict the flow of the business process and who is performing the various parts of the process. A key factor to remember when modeling a business is to describe the business process from the viewpoint of the business actor. While this may sound simple, the business actors do not see all the behind-the-scenes activities that are performed to serve their needs. Therefore, the internal details of the business functions are not included in these activity diagrams. As you discuss the flow of these business use cases with the business people, they will probably provide you with both ex ternal and internal details. You must take care to avoid adding internal details at this level. A simple example of an activity diagram is shown in Figure 3-7.

Figure 3-7. Activity diagram to Transfer Records to the facility

Database Designer

As a designer you can get your first look into the initial components of a conceptual data model. Even at this early point, from the business use case model you can see information that probably will need to be in the database ”for example, clinical rec ords, residents, physicians, and accounts. Also, some access and processing information is available ”the External Facility, Transport Service, and Medical Rec ords Manager all have access to the clinical records. The Medical Records Manager receives the records. The term receives should cause you to question what receives means. This is a natural part of the requirement elicitation process.

This simple activity diagram shows the process flow of transferring the clinical records from the point of view of the business actors (External Facility and Transport Service). The swimlanes, vertical columns in the activity diagram, divide the diagram into areas of responsibility. In Figure 3-7, the External Facility is responsible for assembling the clinical records and giving the records to the Transport Service. The Transport Service's only responsibility is to give the records to the Facility. The ovals represent the activities that the various actors must perform. The arrows indicate the flow of the overall process, starting at the solid circle and ending at the outlined circle.

This business process, from the view of the business actors (External Facility and Transport Service) ends when the Medical Records Manager, who is an internal business worker ”not a business actor ”receives the records. The business actors do not see what the Medical Records Manager does with the records or any of the other internal workings of the business.

A slightly more complex activity diagram is shown in Figure 3-8. This shows the Provide Clinical Care process from the viewpoint of an External Care Provider (includes External Service Providers, External Facilities, Physicians, and Medical Supply Vendors). Note the addition of the synchronization points, represented as horizontal bars. These indicate points at which the process flow splits into independent flows or comes together (synchronizes) into a single flow.

Figure 3-8. Activity diagram for the Provide Clinical Care use case

Database Designer

The activity diagram shown in Figure 3-8 provides more insight to the conceptual data. We now see that the External Care Provider can review (read), update, and return (send) the clinical records. The Facility Staff can provide (send) and receive the clinical records.

The activity diagram for the Accounts Receivable business use case, Figure 3-9, adds a new construct ”the decision point (shown as a diamond). This is where the Auditor determines the eligibility for payment for the treatment received. Here we also see that the Auditor interfaces with two other actors, the Medical Records Manager and the Billing Manager.

Figure 3-9. Activity diagram for the Accounts Receivable use case for reimbursement

Once the remaining activity diagrams are completed, the business use case model is done. But just a word of warning about being done : at this point in the iterative analysis and design process, nothing is done for long. It is not unusual for important distinctions to be revealed at a later stage of analysis and design. This often causes a backward ripple, impacting the previous work you thought was complete. This can be frustrating to the designer and outright frightening to management. Be assured that this is a normal phenomenon to which you will become accustomed in time.

The Business Object Model

The other part of the business model is the business object model, which focuses on how the people inside the business (business workers) accomplish the business processes. This is an inside look at how the business workers interact with other business workers, business actors, and business entities to achieve the business processes (that is, business use cases) that were just defined in the business use case model.

Database Designer

In the activity diagram shown in Figure 3-9, we find new conceptual data ”billing records and reimbursement records. Also, note that eligibility may be a possible attribute (that is, column) of a treatment (another candidate data entity). As before, we also see which business actors can manipulate this data.

The first component of the business object model is a class diagram that contains the business actors, business workers (a slashed circle with an arrow, containing a stick figure), business entities (a slashed circle with a flat base), and their associations with each other needed to accomplish the respective business use case. The business use case gives you the starting point for the business object model, that is, it gives you the external entities and the business workers with which to begin. The simplest example from EAB Healthcare is shown in Figure 3-10.

Figure 3-10. Business object model for the Respond to Inquiry business use case

Only one business entity needed to be added for this business object model ”the Clinical Records. While this class diagram shows the relationship between the appropriate entities for this business use case, the details of the internal processes need to be described as well. This can be done using an activity diagram. However, we prefer to use a sequence diagram for this purpose. Sequence diagrams enable you to be more detailed in the description of the process. Little is needed to explain the internal workings of the very simple Respond to Inquiry business use case. When asked a question, the Facility Staff merely looks in the Clinical Records to provide the answer (Figure 3-11).

Figure 3-11. Sequence diagram for the Respond to Inquiry business use case

Sequence diagrams are read vertically, from top to bottom. Time flows from the top to the bottom of the page. The participating entities (actors, business entities, business workers, and so on) are at the top of the page. The arrows depict the messages or requests that flow between these entities. In Figure 3-11, the Inquirer asks a question of the Facility Staff. The Facility Staff gets the Clinical Records, looks for the answers, provides the answers to the Inquirer, and then returns the Clinical Records.

To show just how much valuable information can be elicited from even simple business object models, let us follow, in detail, the development of a business object model that is just a bit more complex ”Manage Clinical Records. Let's begin building the business object model by looking back at the Manage Clinical Records business use case model's activity diagram for transferring records (Figure 3-7). From this activity diagram we get two actors (External Facility and Transport Service), one worker (Medical Records Manager), and one business entity (Clinical Records) involved in the process. Thus we begin the business object model for this business use case as shown in Figure 3-12.

Figure 3-12. Preliminary business object model for the Manage Clinical Records business use case

As we proceed to build the sequence diagram for this seemingly simple flow, the business person tells us that for Residents who are returning to the Facility, the only time the Medical Records Manager just takes the records from the External Facility and stuffs them into the Resident's previous file is when the Resident hasn't been away from the facility long (that is, the records are still open ). The Medical Records Manager creates a new file for incoming records of Residents whose files are closed or who are new to the facility. Figure 3-13 shows the flow for Residents entering the Facility.

Figure 3-13. Sequence diagram for Transfer Records In

Database Designer

So why bother building the sequence diagram for such a simple process? Even this simple sequence diagram provides needed information to the database designer. The Clinical Records must be accessed by the Facility Staff (read-only), the Facility Staff needs to be able to search through the rec ords (a query), and the records must be returned. (And what does returned mean? Does this mean released, as in releasing a lock that was put on the records?) Also, note that the Inquirer does not get access to the records.

You see on this diagram two special notes ”the rectangles with underlined text and the top right corners turned down. These are not just textual annotations; they are links to two other sequence diagrams. This indicates that, for example, the Admit Prior Resident sequence is performed if needed and then the rest of the Transfer Records In sequence is performed.

We now know there are various types of clinical records. This causes us to update the business object model as shown in Figure 3-14.

Figure 3-14. Updated business object model for Manage Clinical Records

The EAB staff indicates the flow is reversed when records are transferred out, so we ask if anything different happens in that case. The business people tell us that they close their records on that Resident if the Resident doesn't return within 15 days. No changes can be made when the records are closed. This implies that EAB must keep a schedule for the closure of records.

This leads to the question of what happens when the Resident returns after 15 days. In that case, the incoming clinical records are added to a new clinical record file and linked to the old (closed) records with a unique identification number. The files are not physically combined. And if the Resident returns before 15 days? The old records are removed from the closure schedule and the incoming records are moved into the existing records (see Figure 3-15).

Figure 3-15. Sequence diagram for Admit Prior Resident

This diagram shows a link at the beginning to another sequence diagram, Transfer Records In (Figure 3-13). This indicates that the Transfer Records In sequence is performed first and then this sequence, Admit Prior Resident, is performed.

What happens to all the clinical records that are closed or scheduled for closure? The EAB Medical Records Manager tells us that the closure schedule is reviewed regularly, the appropriate records are closed, and then these closed clinical records are archived for seven years. After seven years , the records are destroyed . She also reveals a new piece of information. There is another condition that forces the immediate closure of a Resident's records ”when the Resident passes away. This yields the following sequence diagrams, Figures 3-16 and 3-17, and our updated business object model, Figure 3-18.

Figure 3-16. Sequence diagram for Close Records

Figure 3-17. Sequence diagram for Destroy Records

Figure 3-18. Updated business object model for Manage Clinical Records (CRs, Clinical Records)

The External Clinical Records entity in Figure 3-18 is shown as being part of either the New Internal Records or the Old Internal Clinical Records. This constraint is depicted as a dotted line connecting the two composite relationships along with the text description of the constraint in the braces. Some of the relationships also have annotations on the ends that specify multiplicity. The n indicates many, the 0..n annotation means zero to many, and exact numbers specify that number as the multiplicity.

This representation of the Clinical Records in the business object model doesn't sit well with Angela, one of the data analysts on the team. The use of New Internal, Old Internal, and External in the Clinical Records entity names seems to be trying to capture the state of these entities. Also, the manner in which the constraint is used seems too easy, possibly masking undiscovered complexities. But since Figure 3-18 does correctly depict the handling of the External Clinical Records and since Angela has no better way in mind to model it, she notes her concern to the team and will wait to see if any further clarification of this comes about during requirements definition or analysis and design.

Database Designer

Let's summarize the information that we elicited, just from the Respond to Inquiry and Manage Clinical Records business object models that supports development of the conceptual data model.

New Business Entities

Archive	Records Closure Schedule
Records Destruction Schedule	External Clinical Records
New Internal Clinical Records	Old Internal Clinical Records

New Business Rules

Clinical Records are closed after the Resident leaves the Facility for 15 days.
Clinical Records are closed when the Resident passes away.
Clinical Records are archived after closure.
Clinical Records are destroyed after being archived for 7 years.
The only time Clinical Records are merged is when the Resident returns within the 15-day closure period. Otherwise, New Internal Clinical Records (incoming) are linked, via a unique identification number, to the Old Internal Clinical Records.
The closure and destruction schedules must be checked periodically.

New Access Information

The Clinical Records must be accessed by the Facility Staff (read-only) and the Medical Records Manager (read, write, create, destroy, archive).
The Medical Records Manager must be able to close (lock) the clinical records.
The Facility Staff needs to be able to search through the records. Inquirers do not have direct access to the records.

Considering access, asking about frequency of occurrence of the various actions can give you a head start on performance and sizing considerations. More details in this area will be revealed later in the development cycle as the system definition matures, but any such information known at this point can help with risk assessment and project planning.

Sequence diagrams reveal much of this access and frequency information. Just following the message flow between the entities gives you a direct indication of how heavily these entities, which will likely become tables, will be accessed. Here you can begin to consider your performance issues and gather insight on possible required indexes very early in the development cycle instead of as an afterthought. Also, the sequence diagrams are, in effect, transaction maps that can be used later to validate that your database can support the user 's needs.

All of this information is from the two simplest business object models. This is a good return from such a small investment of time. Participating in the business modeling is invaluable to the database designer.

The remaining business use case and business object models can be found in Appendix A. From these you can see the huge amount of information that business modeling gives us. One thing revealed is that many of the business actors and business workers perform many of the same functions. To simplify things these actors can be part of a generalization structure. For example, an Insurance Auditor, Medicare Auditor, Medicaid Auditor, Corporate Auditor, Government Agency, and Administrator are all types of Auditors . Figures 3-19 and 3-20 show the actor generalizations that were revealed as part of the business modeling effort. (Note: Not all the actors are included in these hierarchies.)

Figure 3-19. Actor generalization for care providers

Figure 3-20. Actor generalization for auditors and agents

From all the information revealed during business modeling we can also create a first attempt at a more traditional conceptual data model (Figures 3-21, 3-22, and 3-23). We use the term traditional since these models simply show the basic entities, relationships, and some additional high-level information.

Figure 3-21. Conceptual data model for clinical records

Figure 3-22. Conceptual data model for schedules and reports

Figure 3-23. Conceptual data model for miscellaneous entities

While these more traditionally styled data models do express the conceptual data concepts, a conceptual data model comprised of all the diagrams in the business use case and business object models provides a much more robust understanding to the development team.