Medical Examiner and Coroner Case Management: Why One Death Gets Typed Into Three Different Systems

Why nobody has built the product you are looking for

If you have searched for medical examiner case management software and come away frustrated, that is not your search skills. This category has no dominant packaged vendor the way corrections or court administration does, and the reason is structural. There are only a few thousand jurisdictions in the country, each operating under a different state statute, some as physician-led medical examiner offices and some as elected coroner offices with no physician on staff. The requirements diverge so sharply that a product built for one is close to useless for another, and the total market is too small to fund the variants. So offices improvise.

The improvisation looks the same everywhere. A Microsoft Access database or a spreadsheet built by someone who left in 2016. Word templates for the autopsy report, with the findings retyped from a dictation. A separate login to the state electronic death registration system where the cause and manner get entered again. A separate entry into the national missing and unidentified persons database for unidentified decedents. A shared drive of scene photographs organised by year and case number, mostly. And a paper log book at the cooler door that is, honestly, the most reliable record in the building.

That improvisation holds until it becomes evidence. A homicide prosecution three years later requires the complete file, and the defence will ask when each finding was recorded and whether it changed. An accreditation inspection asks for turnaround time statistics and case-type breakdowns you cannot produce without counting by hand. A family, or a reporter, requests records that are simultaneously a public record and protected medical information, and the office has to decide line by line what is released. None of those demands are unusual. They are just impossible to meet with a folder structure.

Problem 1: one death, three keyboards

A death investigator takes a call at two in the morning. Decedent name, date of birth, address, next of kin, the reporting agency's case number, the pronouncing physician, circumstances, scene observations. That gets written on a scene form. Back at the office it gets typed into the case database. When the cause and manner are determined, the demographics get typed again into the electronic death registration system, which has its own field validation and its own idea of an acceptable address format. If the decedent is unidentified, the same demographics get typed a third time into the national database, plus dental and DNA status.

Every one of those retypings is a transcription error waiting to happen, and the errors are the kind that matter. A misspelled surname on a death certificate requires an amendment process. A date of birth that does not match creates a duplicate person in a state registry. And the time cost is real: across the offices we have worked with, investigators and administrative staff routinely spend a quarter of their day moving data that already exists in the building from one screen to another.

What a custom build does: the case is entered once at the scene, on a phone or tablet that works with no signal, and everything downstream reads from it. The death certificate handoff becomes a prefilled submission rather than a re-entry, with the office reviewing what the system produced instead of authoring it from scratch. Where a state registration system exposes an interface, you use it. Where it does not, and many do not, you still eliminate the retyping inside your own walls and reduce the external step to a review and paste, which cuts the error surface by most of what matters.

Problem 2: the case is not linear and most software assumes it is

Software built around a workflow assumes stages advance. A death investigation does not. Toxicology comes back in six weeks and reverses a preliminary opinion. An anthropology consult on skeletal remains takes months. A dental comparison identifies a decedent who has been a case number for two years, at which point the demographics, the death certificate and the notification all activate at once, retroactively. A case is signed out as undetermined and reopened when the police develop new information.

This is why generic case management tools fail here, and why every office that tried one is back on Access. They model a case as a record with a status field. A death investigation is better modelled as a set of parallel evidentiary threads, scene, autopsy, histology, toxicology, anthropology, odontology, identification, that each have their own clock and their own completion state, converging on a certification decision that itself has versions.

What a custom build does: threads are first-class. Each has an owner, an expected turnaround, an escalation when it exceeds it, and a record of every result received. The certification is a versioned document: the original, the amended, and the reason for the amendment, all preserved. That structure is what lets you answer the defence question about when a finding was recorded and whether it changed, and it is the single most important design decision in this domain.

Problem 3: the pending case nobody is looking at

Ask any office what their oldest pending case is and watch the pause. Cases go pending on toxicology and then age quietly. Six weeks becomes six months because the reference lab requeued a sample, the pathologist who ordered it left, and no report ever came back. The family calls at month five and the office finds out from them.

Nothing in a folder structure creates pressure. The paper log does not know that a case has been pending 140 days. The pathologist knows the cases they are actively thinking about, which is a small subset. Accreditation programs care about this specifically, because turnaround time is one of the few externally visible measures of whether an office is functioning.

What a custom build does: every pending thread has an expected date derived from its type and the lab it was sent to, and the aging report is the first screen the chief sees each morning. When a result arrives, the system matches it to the case by accession number rather than by a human reading an email, and it notifies the assigned pathologist. When a lab is slow across many cases, that becomes visible as a pattern rather than as individual frustrations, which is what you need to renegotiate a contract or change vendors.

Problem 4: decedent property and the notification you cannot lose

A body arrives with a wallet, a phone, jewellery, sometimes cash, sometimes a firearm. Some of it is evidence and goes to law enforcement. Some of it is returned to the family. Some of it sits in a locker for years because nobody claimed it and nobody knows the disposition rule. The chain on those items has the same evidentiary weight as the chain on the body, and it is typically kept in a bound book.

Next of kin notification carries a similar shape: it is a legal obligation, it is emotionally consequential, and it is documented in a field that says notified with a date, which tells you nothing about who was told, by whom, what was said, or whether the person told was actually the legal next of kin rather than the neighbour who called it in. When a family later says nobody contacted them, that field is your entire defence.

What a custom build does: property is inventoried at intake with photographs, tracked as items with custody events, and carries a disposition rule and a clock. Notification is a logged event with the person contacted, their relationship, the method, the staff member, and a free text record of the conversation, and the case cannot be released to the funeral home until the notification thread is closed or explicitly waived by a supervisor. These are unglamorous features and they are the two that most often prevent a complaint from becoming a lawsuit.

Problem 5: the file is evidence and a public record at the same time

Your autopsy report may be subject to disclosure under your state's public records law, while the photographs are exempt, while the toxicology on a decedent whose death is under active investigation may be withheld entirely, and the rules differ by state and sometimes by case status. Meanwhile the prosecutor needs the complete file, and a civil litigant needs a subpoenaed subset. Offices handle this by having a person read documents and black out lines, which is slow and inconsistent.

What a custom build does: sensitivity is a property of the data element, not of the document, so a release package is assembled by rule rather than by redaction. The narrative fields still need human review, and you should not believe anyone who promises otherwise. But when demographics, findings, photographs and toxicology are separate structured elements with their own release classifications, generating a compliant package for a specific requester type takes minutes and leaves a record of exactly what was released, to whom, under which exemption. That record is what you need when a release decision is challenged.

What this costs and how long it takes

A first release covering scene investigation with offline capture, body intake and cooler tracking, the autopsy record with structured findings, and the death certificate handoff runs $70,000 to $160,000 and ships in 14 to 20 weeks. A full system of record adding toxicology and ancillary thread management, identification casework including the national database submission, decedent property with custody, notification logging, records release with classification, and the statistical reporting an accreditation inspection asks for runs $200,000 to $500,000 phased over 8 to 16 months.

What drives cost up in this domain: multi-county or statewide operation, because each county's law enforcement partner and each district attorney wants something slightly different. Imaging, if you want postmortem CT or radiography series attached to the case rather than living on the scanner. Interfaces to a state death registration system, where the schedule risk is the state's approval queue rather than the code. Photograph volume, since a busy office generates a large archive that has to stay accessible and unaltered for decades, and decades is a real architectural requirement. And dictation, if pathologists will not type, which most will not.

What keeps cost down: accepting for the first release that the death certificate step remains a review and paste rather than an interface. It is the single biggest scope reduction available and it costs you very little operationally.

Build versus buy, and when not to build at all

Do not build if you are a small coroner office handling a few hundred cases a year with one investigator and a contracted pathologist. A structured shared drive, consistent naming, and the state registration system will genuinely hold that together, and a custom system you cannot afford to maintain is worse than a spreadsheet you understand. Do not build if your county is already funding a shared justice platform that will absorb you and you would be building something the county intends to retire.

Build when you are accredited or pursuing accreditation, because the statistics and turnaround requirements are effectively unmeetable by hand at volume. Build when you are a state chief medical examiner office or a regional system covering multiple counties, because the coordination between offices is exactly the part no shared drive can do. Build when your pending caseload has cases nobody can account for. And build when you have been asked for a complete file in litigation and the assembly took more than a day, because that is the moment your record-keeping stopped being an internal matter.

Our position on the empty vendor landscape: the absence of a packaged product here is not a gap waiting to be filled, it is a signal that the requirements really are local. Build accordingly. Build the parts that are yours, keep the state systems as the systems of record they are, and resist the urge to make the software the whole operation.

How to choose a developer for a medical examiner system

Ask them how they would model a case that is signed out, then amended eighteen months later after new toxicology. If the answer involves updating fields, stop the conversation. The correct answer preserves both versions and the reason, because the original certification existed in the world and cannot be unwritten.

Ask how they intend to handle photographs and imaging over a twenty year retention. Storage is cheap and that is not the question. The question is whether the archive stays readable, whether integrity can be demonstrated, and what happens when the office changes cloud providers in year eight.

Ask what they have built that operated with no connectivity. Scene work happens in basements, in fields, in parking structures. A system that requires signal is a system your investigators will bypass with a paper form, and then you have paid for nothing.

Ask who owns the code, the repository and the hosting accounts, and put it in writing before kickoff. At Digital Heroes that is yours from the first commit. Then bring your chief investigator and your administrative lead into design, not just the chief medical examiner. The investigator knows what happens at two in the morning, and that is the part the software either survives or does not.