Wide
Admin, FD or Megan opens the case in Mortware, as today.
RequiemOS isn’t involved yet.
After Garden Hill, how does RequiemOS come into Kearney? The options we considered, why we recommend Narrow, and one cremation case followed from first call to close.
For every step of the case: who does it, where, when, and in which system. It's shown three ways: under Wide, and under Narrow for a case at an R/OS location and a case at a legacy location.
Garden Hill uses Kearney’s process except at the start and end of each case. While it runs, we keep building the MVP. After that there are two broad ways into Kearney. Wide replaces SRS for chain of custody everywhere and leaves Mortware in place. Narrow puts the full product into a limited set of locations first.
This isn’t mainly a technology choice. It’s about what Kearney expects from a new system, how change lands on their people, and what a team of three can support while still building the product.
Wide announces a new system to all of Kearney that delivers only chain of custody. Contracts, documents, arrangement and readiness stay out of sight. It under-delivers, and every later location cutover starts from that impression.
A company-wide launch makes every location a stakeholder, with its own questions, expectations and requests to make a custody tool do more. Narrow’s audience is the hub and a few locations, so development keeps moving.
RequiemOS is built around full cases. Custody alone means extra work for every case: an R/OS case per decedent just to carry the barcode, then ending it and linking it to Mortware. In Wide that workaround is the whole deployment. In Narrow it’s a temporary mode for legacy cases only.
The retort is the step that can’t be undone. Kearney’s two-person identification exists because of a past cremation that should have been a burial. Both options that put the hub on RequiemOS keep one scanning system there. The hub-stays-on-SRS version doesn’t.
At an R/OS location, the permit, prep sheet and authorization are on the case, so the crematorium request waits for them. Under Wide those facts sit in Mortware, and every check stays manual.
Moving directors off Mortware is the hard part, and Wide leaves all of it ahead. Narrow proves it at a few locations. Each later location follows the same process, and its existing cases are found by Mortware number rather than created twice.
Each step shows three paths. Wide: every case works the same way. Narrow, R/OS location: a case at a location running the full product. Narrow, legacy location: a case at a location still on Mortware. Dashed boxes mean “same as the column to the left.” Red boxes mark friction.
Admin, FD or Megan opens the case in Mortware, as today.
RequiemOS isn’t involved yet.
Admin or FD opens the case in R/OS, which assigns the case number.
Calls with no location assigned yet (the shared after-hours inbox, or calls to Megan directly) go into R/OS as unassigned. The daily standup assigns them.
The case exists before anyone picks up the deceasedAdmin or FD opens the case in Mortware, as today.
If an unassigned call is assigned here, someone prints the first-call sheet from R/OS and sends it over, and the funeral home enters it into Mortware.
An extra hand-off step for unassigned callsFD sends the Release Form from Mortware for hospital or morgue deaths. Verbal authorization covers home deaths.
FD requests the transfer from Megan by email or phone, quoting the Mortware case number. Drivers, or Global overnight, pick up.
FD generates the Release Form from R/OS. The signed copy is scanned back to the case.
FD requests the transfer from Megan, quoting the R/OS case number. Drivers, or Global overnight, pick up.
Same as Wide.
Megan’s team creates an R/OS case for the decedent and records the Mortware case number from the transfer request.
They print the wristband and the Initial Analysis from R/OS, then fill in the KGY section of the Initial Analysis by hand.
Every decedent gets a second case number, just to carry the barcodeMegan’s team finds the existing case in R/OS. Nothing is re-entered.
They print the wristband and the Initial Analysis from R/OS, then fill in the KGY section by hand.
Replaces today’s SRS entryMegan’s team creates an R/OS case, as in Wide, with the Mortware number. For an unassigned first call the case already exists, and they add the Mortware number once it arrives.
Wristband and Initial Analysis as for the R/OS location.
Two case numbers, but only at the hubCare Centre staff and funeral attendants scan in R/OS on every entry and exit: from BTC, and out to the crematory or a viewing.
They fill in the CC section of the Initial Analysis, which is then scanned to SharePoint. Personal effects are tracked on Paper, as today.
Same scanning in R/OS.
The Initial Analysis is scanned to the R/OS case. Personal effects are recorded in R/OS (on paper as a fallback).
Same as Wide.
FD and family: contract, consents, authorizations and effects inventory in Mortware and SharePoint, as today.
RequiemOS adds nothing here, where directors and families would see itFD captures everything in R/OS, generates the document set, and runs one signing session with the family.
The product working as designedSame as Wide, as today.
Sarah submits the death registration from Mortware.
The permit arrives carrying the Mortware case number. Megan matches it to the R/OS case by that number. The permit itself is filed in SharePoint.
Sarah submits using the data captured in R/OS.
The permit carries the R/OS case number. Megan’s team attaches it to the case.
Sarah works in two systemsSame as Wide.
FD handwrites the prep sheet. The FDA keys it into Mortware, and embalmers work from the paper.
Family identification (KFS Identification Acknowledgement) and the two-staff verification are on Paper, filed to SharePoint.
FD fills in the prep sheet in R/OS. Pacemaker, communicable-disease and nuclear-therapy questions must be answered yes or no. Embalmers get a printout.
The identification forms are generated from R/OS, signed on Paper, and scanned back to the case.
No re-keyingSame as Wide.
Megan checks the permit and pacemaker status by hand against SharePoint, then books West Shore or Fraser Valley.
The packet is mixed: the casket tag comes from R/OS, and the transfer form, authorization and permit from SharePoint. Every decedent goes through the metal detector, and the Care Centre scans them out in R/OS.
RequiemOS can’t see the facts that decide whether cremation may proceedThe permit, prep sheet and identification are on the R/OS case, so the crematorium request waits until they’re all in place. Megan chooses the crematory.
The whole packet prints from R/OS. Then the metal detector, and the Care Centre scans the decedent out.
The check is built in, not done by memorySame as Wide: a manual check and a mixed packet.
The same desk handles enforced checks for some cases and manual checks for others. It must be unmistakable which applies.Cremationist scans the casket tag in R/OS on arrival and again after cremation. One scanning system for every case.
The crematory issues the Certificate of Cremation, filed to SharePoint. Maple Ridge, a third party, doesn’t scan.
Same scanning in R/OS.
The Certificate of Cremation is added to the R/OS case.
One system at the retort, for every Kearney caseSame as Wide.
The cremains come back to Megan at BTC and are scanned in to R/OS. The urn sticker is printed (who prints it is still to confirm).
Megan’s team scans them out to the funeral home and cancels the R/OS case as handed off. Custody in RequiemOS ends here.
Scanned back in and out as in Wide.
The R/OS case carries on to the funeral home.
Same as Wide: Megan’s team cancels the R/OS case as handed off at dispatch.
FD calls the family, then handles release of the cremains, return of effects and jewellery, and handover of death certificates on Paper and in Mortware. The case closes in Mortware.
FD records the pickup, the returns and the certificates in R/OS, then closes the case there. RequiemOS won’t close a case while any personal effects are still outstanding.
One record from first call to closeSame as Wide, as today.
| Person | Wide | Narrow · R/OS location | Narrow · legacy location |
|---|---|---|---|
| Admin | No change | First calls go into RequiemOS | No change |
| Funeral director | Stops “Complete SRS Entry” | Everything in RequiemOS, arrangement to close | Stops “Complete SRS Entry” |
| FD’s assistant | No change | No more keying the prep sheet | No change |
| Megan & team | RequiemOS instead of SRS; creates a case for every decedent | RequiemOS for every case. Finds the case for an R/OS location, creates one for a legacy location; cancels legacy cases at dispatch. | |
| Care Centre & attendants | Scan in RequiemOS instead of SRS, for every case. Documents come from RequiemOS or SharePoint depending on the location. | ||
| Cremationists | Scan in RequiemOS instead of SRS, for every case. | ||
| Sarah | No change | Two systems: RequiemOS for R/OS locations, Mortware for legacy | |
| Family | No change | A new document set at arrangement | No change |