This page is part of the Medicolegal Death Investigation (MDI) (v1.0.0: STU 1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Best Practices

This MDI specification is designed to be flexible to accommodate a variety of systems, recognizing that information management systems used for assembling MDI data vary widely by state, jurisdiction, and agency. This means that many data concepts have few requirements but many “must support” designations. This section provides best practice recommendations on how to address select concepts.

Decedent

This MDI implementation guide uses the US Core Patient for the decedent subject of:

• Composition - MDI to EDRS and the profiles referenced in its section entries
• DiagnosticReport - Toxicology Lab Result to MDI and the profiles referenced for its specimens and results

The US Core Patient profile requires

• 1..* patient identifier, each identifier specifying a system and value
• 1..* patient name
• 1..1 gender code (AdministrativeGender). Note modeling gender and sex information is ongoing in HL7. Refer to US Core Patient profile, “Mandatory and Must Support Data Elements.” The three data elements may not be known during early stages of medicolegal data collection. US Core provide guidance on such cases of missing data.

The US Core Patient provides structure for capturing basic demographic information (race, ethnicity, birth sex, gender identity, birth date, telecom, address, martial status). The Composition - MDI to EDRS also provides a section, additional-demographics for text on demographic information about the decedent that is not represented in the decedent Patient profile.

The Participant & Supporting Examples section of the Artifacts page provides an example of a US Core Patient for which no information known about the decedent’ name.

Identifiers and Tracking Numbers

This MDI implementation guide provides opportunities for both identifiers and tracking numbers. Tracking Numbers are for document and are used for interoperable communication. Identifiers are for individual resources and are assigned from the data source.

• Identifiers: Identifiers are unique to a particular instance of the FHIR resource being transmitted and are often automatically generated by a system.
• Tracking numbers: Tracking numbers in this MDI implementation guide represent case or record numbers, usually assigned by the originating organization such as an ME/C office or an EDRS and usually persisting throughout updates to the death investigation data. They are optional and multiple tracking numbers may be recorded. A system receiving a record with a tracking number may append its own tracking number and return/send the record with both tracking numbers. The extensible ValueSet - Tracking Number Type contains codes to identify the type of tracking number and may be augmented by local implementations of this specification.

Certification

Agencies and jurisdictions have a range of requirements for certification of information during the process of collecting and exchanging MDI data. Typically, a forensic toxicology diagnostic report will be considered certified when the final version is sent. A document bundle sent from an MDI system to an EDRS can use the status data element to indicate preliminary or final and certified.

This MDI specification provides opportunities on most profiles for naming the responsible party. The legal nature of certification is a business requirement to be assigned by each agency or jurisdiction implementing this specification.

The Composition - MDI to EDRS attester is required and is the individual who will be listed as the Certifier on the Death Certificate.

Death Date

The Observation – Death Date profile represents the actual or presumed date of death. It should be used to record information about both the date and time of death and the certainty of those data. Note that the US Core Patient profile used for the decedent has an optional Patient.deceased[x] data modifier that may be used in addition to, but not instead of, the Observation – Death Date profile. If the Patient.deceased[x] is used, it must either be Boolean=true or the dateTime must match Observation – Death Date.

The Observation – Death Date profile provides several opportunities to explain the date listed as Death Date:

• Observation.value[x]: Actual or presumed date of death
• Observation.component: Date and time pronounced dead [US Standard Certificate of Death]

Specific date or range of dates: If the actual date of death is known (date, date-time, or partial date such as year or year + month), set value resource type to dateTime. If the date of death is not known, and a range is known, set value resource type to Period, defined by a start and end dateTime.

Unknown date: Use the dataAbsentReason resource for missing all or part of the decedent’s death date (further information can be recorded in the note data element).

Options for qualifying the accuracy of the date of death:

• Use the Observation.status data element for modifiers contained in the value set ObservationStatus (registered, preliminary, final, etc.). This value set contains eight concepts and is not extensible (cannot be added to by local implementations).
• Use the method codes from the extensible ValueSet - Date Establishment Approach (exact, approximate, court-appointed)

Causes of Death

The Observation.value[x].text is limited for both Observation - Cause of Death Condition and Observation - Condition Contributing to Death because the receiving EDRS sends the data to NCHS (ultimate receiving system). That NCHS system restricts the text string length for these data elements. Because the originating ME/C case management system is certifying the content of the data elements, the data must not risk being truncated or lost by the receiving systems along the entire worfkflow. Therefore, the originating system must abide by the character limit of the ultimate receiving system at the time of data capture, potentially including direct entry by the user if that is the mechanism of capturing the data.

Forensic Toxicology Laboratory Specimens & Results

One-to-many specimen to results relationship: Each analyzed specimen, represented by a Specimen - Toxicology Lab resource, must be referenced by at least one Observation - Toxicology Lab Result and may be referenced by more than one Observation - Toxicology Lab Result. For example, a single blood specimen may be analyzed for several different analytes or by several different methods. Each of those specimen/analyte or specimen/method combinations will be represented by an Observation - Toxicology Lab Result.

Specimens received but not analyzed: ME/Cs may need to know if a forensic toxicology laboratory received a specimen but did not analyze it. In such cases, the laboratory should provide a reason for no analysis in the DiagnosticReport.conclusion and/or each unanalyzed specimen’s Specimen - Toxicology Lab Specimen.note. Additionally, the Specimen - Toxicology Lab may use the Specimen.condition to describe the state of the specimen via codes from the extensible value set hl7VS-specimenCondition and/or use the Specimen.note to describe details or issues about the specimen.

Reporting results: The result of a specimen analysis is required to be reported as text and may also be represented by a code. This allows exchange of the result meaning among systems that do not share code systems or do not use standardized code systems. The value of the result may be reported in several text formats:

• Word or phrase indicating presence or absences with no quantity (e.g., “Detected”, “Not detected”)
• Mathematical expression of quantity with units (e.g., “= 0.160 g/dL”)
• Mathematical expression of quantity range with units (e.g., “< 2.5 ng/mL”)

API Specifications & Search Operations

This MDI specification is designed for RESTful API implementations supporting data exchange interactions between systems via FHIR extended operations. (See RESTful API for an overview.) The MDI implementation guide uses extended operations with MDI-specific search parameters and a subset of the many RESTful API operations defined by FHIR. All API implementations of this MDI specification must conform to common design rules:

• MIME-type for FHIR resources is application/fhir+xml or application/fhir+json. This must be specified for Content-Type in the HTTP header.
• application/x-www-form-urlencoded can be used for POST search requests if HTTP Form is used.

An MDI-based Search API enables MDI systems to search EDRS for decedent cases. This is an idempotent operation (i.e., it has no additional effect if it is called more than once with the same input parameters). Both POST and GET can be used with the following endpoint URL pattern:

• POST [base]/Composition/$mdi-documents
• GET [base]/Composition/$mdi-documents?name=value&…

MDI Search Parameter Definition Summary Table

Search parameters related to patient are formatted with “.”. In FHIR, this means that the search parameters after “.” are part of a patient parameter. See the example below.

Code example:

{ 
  "resourceType": "Parameters", 
  "parameter": [ 
    { 
      "name": "patient", 
      "part": [ 
        {  
          "name": "family", 
          "valueString": "Hans" 
        }, 
        {  
          "name": "given", 
          "valueString": "Kennoby" 
        } 
      ] 
    } 
  ] 
} 

If [id] is provided within URL path (e.g., /Composition/[id]/$mdi-documents), then the output response should be an MDI document bundle as there will be only one or zero result.