Case hierarchy design: Injury and illness
Consider the following requirements of 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 immediately reported to the regulatory agency. 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 by 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:
Process | Description |
---|---|
Record Injury/Illness |
A guided, dynamic data-entry procedure |
Submission | Severe events must be reported to the regulatory body Status must be tracked |
Annual Summary | One record for every plant year Must be verified, certified, and posted |
Design a case structure to support this application.
Solution
You most likely identified three independent case types with no subcase relationships:
- Illness Injury - for logging each illness or injury event
- Annual Summary - to track the end-of-year report for each plant
- Submission - for those events that must be reported to the regulatory agency.
Discussion
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, the reports must contain static information. While the original content can 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 itself is not a subcase of Illness Injury, because the Illness Injury is not dependent on the Submission processing being completed.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
Want to help us improve this content?