Identifying Errors in Forensic Autopsy Reports Using a Novel Web-Based Program

Abstract

Introduction

Autopsy reports are often complex, with ample opportunity for errors and inconsistencies. These reports are often scrutinized by both families and attorneys. Identification of errors by proofreading physicians or clerical staff can be improved by utilizing a computer program to examine reports for discrepancies.

Methods

A webpage to review demographic consistency, organ descriptions, and pertinent information regarding gunshot wounds was developed to proofread reports. Thirty completed reports were analyzed from the Jefferson County Coroner/Medical Examiner Office. Additionally, a separate individual was instructed to sabotage reports and then determine if the software could detect the alterations.

Results

Of the 30 completed reports analyzed, no errors/omissions were identified; however, these reports were accurate upon manual inspection. Rarely, the computer triggered a warning that an organ should be confirmed if the author used a description that differed from the software's vocabulary (e.g., the author discussed “uterine wall” instead of “uterus”). The webpage detected eight out of ten errors supplied to the five sabotaged cases. These errors ranged from inconsistent age, race, and gender, to incomplete gunshot wound descriptions.

Conclusion

Identification of errors by a computer proofreading program can improve autopsy report quality. The webpage has been designed so that additional modules, such as strangulation proofreading, could easily be added. Furthermore, the ability of the software to detect errors will continue to improve as more words are added to its vocabulary. The webpage is freely available and can be adapted to other medical examiner offices needs from the GitHub website.

Introduction

Autopsy reports provide important insights into cause and manner of death. The circumstances surrounding the death vary widely, but regardless of the case, these reports must be accurate. While medical examiners (ME) should strive for excellence, autopsy reports are often complex, with ample opportunity for errors and inconsistencies. Complicating this process is the sheer case volume that MEs manage. The National Association of Medical Examiners (NAME), a professional organization promoting high forensic standards, recommends a limit of 250 cases per ME per year and caps numbers at 325 for purposes of accreditation (1,2). Furthermore, these reports are often scrutinized by both families and attorneys (3). While attentive physicians and/or clerical staff catch the majority of errors, the proofreading process can be improved by utilizing computers to examine reports for discrepancies (4). We present our development of novel software to detect clerical errors, report inconsistencies, and missing information.

Methods

Using a Dell XPS12 Ultrabook, we developed a webpage to review autopsy reports. Basic web development requires Hypertext Markup Language (HTML), JavaScript (JS), and Cascading Style Sheets (CSS). HTML is the language used to create webpages; web browsers, such as Internet Explorer or Google Chrome, interpret this code and render a webpage for the user (5). The webpage acquires functionality through the programming language JS (6). Developing useful buttons, performing background calculations, and generating webpage output are only a few of the functions JS imparts. CSS files, if used effectively, format the page into a user friendly environment (7). The author implemented Twitter Bootstrap to facilitate a clean, easy-to-use design that was compatible with both computers and tablets (8).

Initially, HTML was used to craft the basic framework of textboxes and buttons. This page was linked to several JS files that performed the majority of the webpage's tasks. First, a “main” JS file was created to handle processing of text inside a copied report. Important variables, such as name and demographic data, were assigned after the software scanned the report. For our office, these reports have a front page that displays demographic information about the decedent (e.g., Age: 32 years). Subsequently, multiple functions executed to find all instances of each demographic detail via a set of phrases, such as “40-year-old white male.” Each instance was compared to the value used on the front page of the report (saved as a variable in the code); any deviations were added to an error/discrepancy list. Following the age and demographic evaluation, each organ system was examined. The authors designed a comprehensive vocabulary list that enabled the software to interpret organ system information. This examination confirmed no organs were omitted and ensured consistency by searching for incompatible sex-specific anatomy (e.g., ovaries in a man).

Separate JS files were created to address specific case scenarios, such as descriptions of gunshot wounds and evaluation of neck structures in cases of strangulations. While these features could have been included in our main JS file, we felt that the software would be easier to expand if it used a modular format with files designed to handle specific circumstances. In the gunshot module, the user specifies the number of gunshot injuries. The program then reviews the clothing section for “gunshot holes” or “gunshot defects” and checks for the presence of key words, such as soot and gunpowder. Under the “Evidence of Injury” portion of the report, the program reviews the wounds and counts the number of times “soot”, “stippling”, and “muzzle imprint” appear. The strangulation module runs similar to the organ system functions; the program confirms that pertinent structures, such as hyoid bone, are discussed within the report. Errors from either the gunshot or strangulation module are logged in the error section and are reported after the program concludes its report evaluation.

The webpage was initially deployed locally and tested by its programmer. The author tested each search module, such as the gender consistency, at least three times to confirm that basic errors were caught. After the basic debugging phase, 30 autopsy reports authored by four different attending physicians and co-authored by several different pathology residents were tested. Upon completion of this phase, the webpage was transferred to the free webhosting site, GitHub.

Individuals can share computer code as well as host a website for free on GitHub (9). After creating a membership, users have repositories for their projects. If a fellow member on GitHub has an interest in a project, he/she can fork the repository. Forking creates a copy of a repository so that it can be edited under another account without affecting the original code. While options are available to block access to code, we left our account open to the public so that individuals can modify the webpage to their needs.

Once the webpage was available to the general public, we tested the webpage with five forensic autopsy reports that had been sabotaged. The following errors were introduced: 1) omission of organs; 2) gender discrepancies, ranging from changing male to female throughout the report to including incompatible anatomy; 3) racial inconsistencies; 4) age changes (i.e., 40-year-old to 4-year-old); and 5) removing pertinent gunshot details.

Results

We successfully tested 30 completed autopsy reports on our software. Of these reports, no inconsistencies or omissions were discovered; however, these reports were accurate by manual inspection. The webpage rarely issued a warning about an organ omission when a report used a description outside the software's vocabulary. This process facilitated the growth of the programs vocabulary as these newly encountered words were incorporated. Specific examples include errors in evaluating female anatomy. Female anatomy can be addressed in numerous ways, so the software indicated the uterus was not discussed if the author only included a phrase about “the uterine wall” or “the endometrial lining.” These problems were fixed once the phrases were included, but it indicates that the vocabulary list will need to be updated as problems arise. Furthermore, this demonstrates the ability of users to adapt the program to suit their individual styles. The webpage detected eight out of ten errors supplied to the five sabotaged cases. As previously mentioned, these errors ranged from inconsistencies to flagrant omissions. The two errors not detected by the webpage were age inconsistency, an issue already corrected in the programming, and identification of gunshot details. The age inconsistency code was rewritten to increase sensitivity; however, if the report has a typographical error, such as “yaer” instead of “year”, the program will not be able to detect the age. The gunshot module recognized pertinent details, such as soot and stippling; however, these details may not be detected in the correct place of the report. For example, soot may be detected in the clothing section but the soot around a gunshot could be described in a separate location that was not evaluated by the program.

Examples of the webpage output are shown below in Figures 1, 2, and 3.

Figure 1:

Screenshot of the webpage when no errors are found in an autopsy report.

Figure 2:

Gender-specific anatomy that was incorrectly included in the report.

Figure 3:

The webpage has detected inconsistencies in both race and gender.

Discussion

We successfully deployed a webpage that evaluates reports for inconsistencies and important omissions. In its current form, the software correctly identifies missing organs, such as heart or thyroid, as well as alerts users to problematic areas in demographics, such as race changes or males possessing unremarkable ovaries. The webpage's searchable criteria will expand with continued use as new phrases are introduced to reports. Future developments include the following: 1) checking name consistency throughout the report; 2) consistent cause and manner of death; 3) bullets changing course throughout the report; 4) pertinent negatives in overdose cases; 5) detecting inconsistencies based on surgical history (i.e., appendectomy); and 6) confirming that date and time of death and autopsy are both consistent and acceptable (i.e., ensuring the autopsy occurred after death).

This webpage was designed to grow and adapt to other ME offices. GitHub hosts the webpage for free and allows users to “fork” the software's repository. Forking the repository allows users to have a copy of the repository under their own account that can be modified without altering the original author's code. The advantages of this solution are:

• 1.The webpage can be expanded to include new modules, such as burn cases. The individual modifying the code can offer the new web address of his or her repository to others or send the changes to Matthew D. Cain, at which point he may accept these changes and update the webpage.
• 2.If a section of the code needs to be modified for a specific office, an individual can make the necessary changes. For example, if an office does not have a front page to extract data, then it might be advantageous to create input boxes for demographics. Once these fields are created and incorporated into the code, the software should theoretically run without a problem.
• 3.Many stable tools and frameworks exist, such as the open source software, Huge (a free login framework), because a programming community contributed to a code repository (10,11). Some of these products were originally created by talented programmers but, these tools were made better by others in this diverse community. Our webpage is still early in development, and another programmer may have unique contributions and/or better ways to implement searches.
• 4.Our webpage does not store any part of the autopsy report outside of a temporary variable to store the report's text. By using GitHub, this confers a degree of transparency.

While GitHub is an easy solution for initial web hosting and development, its design is not necessarily for a finalized web product. For example, GitHub is limited by its inability to support databases; therefore, correction results from the webpage lack statistical analysis of errors. This limitation could be overcome if a user modifies the code to connect to a database management system that hosted on a separate server, such as MySQL (Structured Query Language) (12). In the future, a modified version of this software that is connected to a database will probably be deployed on either a webhosting service, such as Siteground or Host Gator, or on a university server.

The webpage works well for our office; however, our scripts may struggle to interpret other ME offices autopsy reports if the format deviates significantly. The ability to alter the code provides a workaround for this problem; however, adjustments to the webpage scripts require a decent amount of programming knowledge. Therefore, using standardized reports may be a more feasible solution. Our webpage includes instructions and an example report so that users can view a compatible format.

Several forms of artificial intelligence/machine learning exist; examples include natural language processing and neural network software. Programs that employ these technologies include email spam filters and predictive text services (13,14). In fact, programmers have free access to some of these fully developed scripts for incorporation into their own projects. Our group has not implemented these technologies yet, but it is a distant future consideration. Developing this technology from scratch would require a very significant amount of time and research; however, modifying an existing script for our software may be feasible but will still entail substantial effort.

Conclusion

Quality assessment/quality control (QA/QC) measures can benefit from our product. The webpage was designed for ease of use; thus both physicians and clerical staff can check autopsy reports. Currently, the webpage is used primarily by the physicians and fits in well with our bimonthly QA/QC conferences. Furthermore, younger physicians would probably benefit most from our webpage. Experienced physicians have seen nearly the full gamut of errors, ranging from incorrect case numbers to autopsy dates predating death. These errors are easily corrected if the ME searches for them; however, these less conventional errors could be easily found using software and potentially save a ME from embarrassment. Our webpage does not catch everything, but with time, we hope that our scripts will be able to scrutinize reports with an experienced eye and help both novice and veteran physicians.

Webpage URL: http://cainmd.github.io/forensic_corrector/.