This page is part of the Medicolegal Death Investigation (MDI) (v1.0.0-ballot: STU1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.0.0. 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 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.

• 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. 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.

Data Elements Available as Certifiers of MDI Information Summary Table

Profile	Data Element & Reference	Cardinality & Must Support	Description
Bundle - Document MDI to EDRS	signature	[0..1]	Digital Signature
Composition - MDI to EDRS	attester	[0..*], Must Support	Attests to accuracy of composition
Observation - Cause of Death Condition	performer Reference (US CorePractitioner Profile)	[1..1], Must Support	Who is responsible for the observation This profile identifies one of the eventually ordered causes of death asserted by the death certifier. The cause of death is initially specified with text.
Observation - Condition Contributing to Death	performer Reference (US CorePractitioner Profile)	[1..1], Must Support	Who is responsible for the observation This profile identifies factors contributing to the cause of death as asserted by the death certifier.
List - Cause of Death Pathway	[none]
Observation – Death Date	performer Reference (US CorePractitioner Profile)	[0..1], Must Support	Who is responsible for the observation
Observation – Death Injury/Event Occurred at Work	Performer Reference (Practitioner | PractitionerRole |Organization | CareTeam | Patient | RelatedPerson)	[0..*]	Who is responsible for the observation
Observation – Decedent Pregnancy	performer Reference (Practitioner |PractitionerRole | Organization | CareTeam | Patient | RelatedPerson)	[0..*]	Who is responsible for the observation
Observation - How Death Injury Occurred	performer Reference (US CorePractitioner Profile)	[0..1], Must Support	Certifier of the explanation. This Observation provides the certified explanation of how the injury leading to death occurred.
Observation - Manner of Death	performer Reference (US CorePractitioner Profile)	[1..1], Must Support	performer
Observation - Tobacco Use Contributed to Death	performer Reference (Practitioner |PractitionerRole | Organization | CareTeam | Patient | RelatedPerson)	[0..*]	Who is responsible for the observation
Bundle Message Toxicology to MDI	signature	[0..1]	Digital Signature
MessageHeader – Toxicology to MDI	responsible Reference (Practitioner |PractitionerRole | Organization)	[0..1]	Final responsibility for event The person or organization that accepts overall responsibility for the contents of the message. The implication is that the message event happened under the policies of the responsible party.
DiagnosticReport -Toxicology Lab Result to MDI	performer Reference (US CorePractitioner Profile | US Core PractitionerRole Profile)	[0..*], Must Support	Responsible Diagnostic Service
DiagnosticReport -Toxicology Lab Result to MDI	resultsInterpreter Reference (Practitioner |PractitionerRole | Organization | CareTeam)	[0..*]	Primary result interpreter
Specimen – Toxicology Lab	[none]
Observation - Toxicology Lab Result	performer Reference (Practitioner |PractitionerRole | Organization | CareTeam | Patient | RelatedPerson)	[0..*]	Who is responsible for the observation

Forensic Toxicology Laboratory Specimens & Results

One-to-many specimen to results relationship: Each 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”)

Death Date

The Observation – Death Date profile represents the actual or presumed date of death. It 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).

Qualifying the accuracy of the date of death:

• Use the status resource for qualifiers contained in the value set observation-status (registered, preliminary, final, etc.). This value set contains eight concepts and is not extensible (cannot be added to by local implementations).
• Use the interpretation resource codes from the extensible ValueSet - Date Death Qualifiers (exact, approximate, etc.)

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

Name	Cardinality	Type	Documentation
In Parameters
id	0..1	uri	Resource ID of Composition - MDI to EDRS
patient.birthdate	0..1	date	Decedent’s date of birth
patient.family	0..1	string	Decedent’s last name
patient.given	0..1	string	Decedent’s first name
patient.gender	0..1	token	Decedent’s gender
tracking-number	0..1	token	Search by identifier in Composition - MDI to EDRS
death-location	0..1	string	District of Death Location
death-date.[actual | pronounced | all]	0..1	date	Date of Death. “all” applies to both actual/presumed and pronounced
Out Parameters
return	0..1	resource (Bundle - Document MDI to EDRS)	Searchset Bundle that includes MDI document bundles. If [id] is supplied, then this should be Bundle - Document MDI to EDRS

The name of search parameters is formatted as [profile].[parameter]. If [profile] is missing, then it applies to the Composition – MDI to EDRS profile.