Case hierarchy design: Injury and illness

Consider the following requirements by an automobile manufacturing company automating an Illness and Injury Reporting application.

Like many corporations, the automobile manufacturing company must log work-related fatalities, injuries, and illnesses. For example, if an employee contracts tuberculosis at work, then the illness must be logged in the company's safety records.

Certain extreme events, such as death, must be reported to the regulatory agency immediately. These reports are called submissions. Submission processes and requirements differ by country. Some countries have additional rules based on state or province. Typically, these rules are more stringent forms of the national guidelines. There are also some guidelines that are specific to injury type. A small subset of injuries requires injury-specific fields to be filled in. For example, with hearing loss, the actual assessment of the loss, measured in decibels, must be recorded.

The Illness and Injury Reporting application must support two processes.

First, any injury or illness must be recorded. This is a guided and dynamic data-entry procedure that is specific to the regulations of the country in which the plant is located. The culmination of these entries is an electronic logbook.

Second, the application must generate a summary of submission records for every plant per year. Each record summary must be verified, certified, and posted. Notably, severe events must be reported to the regulatory body of the corresponding country, and the status of this submission must be tracked. The reports of these record types are separate. There is never a need for a list of records that is a mix of Injury Records, Annual Summaries, and Submissions. However, because summaries are a culmination of injury records, and submissions are spawned by injury records, assuming that injury record information is included in the summary or submission report is reasonable.

The following table highlights the requirements:

Design a case structure to support this application.

You likely identified three independent case types with no subcase relationships:

• Illness Injury is for logging each illness or injury event
• Annual Summary is to track the end-of-year report for each plant
• Submission is for those events that must be reported to the regulatory agency.

An Annual Summary appears to be only a report. Still, you create a case because the requirements explicitly state that these reports' status must be tracked, indicating a dedicated process. Furthermore, these reports must contain static information. While the original content may be derived from a report, this content must be fixed and persisted.

Create a Submission case because the requirements state that the submission process, and status of each submission, must be tracked. Submission tracking is performed independently of the original injury record and is best kept as a separate case.

You might consider that Submission is a subclass of Injury Illness, but Submission is not a type of illness injury. Submission is a case that is spawned by an Illness injury case. Submission is not a subcase of Illness Injury since the Illness Injury is not dependent on the Submission processing being completed.