Medicolegal Death Investigation (MDI)
1.0.0 - STU 1 US

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

Specification

This page describes normative content of the specification. For an introduction to FHIR, please visit HL7’s FHIR Summary as well as the overviews for developers and for clinicians. Also, refer to “Getting Started with FHIR”.

FHIR Exchange Paradigms Supported

  • RESTful API - Optional for all systems
  • Document Bundle - Required for MDI systems & EDRS
  • Message Bundle - Required for Forensic toxicology LIMS & MDI systems

Actors & Roles

This specification defines three actors:

  • Forensic toxicology LIMS: This is a data source for the Message Bundle that contains the Toxicology Lab Result to MDI Diagnostic Report.
  • MDI system: This is an application used by ME/Cs and is a data consumer of the Message Bundle from the Forensic Toxicology LIMS and a data source of the Document Bundle MDI to EDRS.
  • Electronic death registration system (EDRS): This is an application used by jurisdictional vital records agencies and is both a data source and a data consumer of the Document Bundle MDI to EDRS.

This specification requires two roles in any data exchange:

  • Data Source: An application that exposes a FHIR document bundle or message bundle to a data consumer. This can be thought of as the server in a client/server interaction.
  • Data Consumer: An application that consumes a FHIR document bundle or message bundle. This can be thought of as the client in a client/server interaction.

MDI Implementation Guide Actors & Roles Summary Table

Actor Data Source for: Data Consumer of:
Forensic Toxicology LIMS Bundle - Message Toxicology to MDI  
MDI System Bundle - Document MDI to EDRS Bundle - Message Toxicology to MDI
Bundle - Document MDI to EDRS
EDRS Bundle - Document MDI to EDRS Bundle - Document MDI to EDRS

Capability Statements & Claiming Conformance to This Specification

To claim conformance to this specification, FHIR servers SHALL be able to populate all profile data elements that have a minimum cardinality >= 1 and/or are flagged as MustSupport as defined by that profile’s StructureDefinition.

Forensic toxicology LIMS server is responsible for:

  • Producing a valid DiagnosticReport - Toxicology Lab Result to MDI
  • Producing a valid Bundle - Message Toxicology to MDI that includes the DiagnosticReport
  • Sending the Bundle Message to an MDI system data consumer

MDI system server is responsible for:

  • Consuming a valid Bundle - Message Toxicology to MDI received from a forensic toxicology LIMS
  • Querying an EDRS for an existing case record and receiving a response (Bundle - Document MDI to EDRS) from an EDRS data source
  • Updating an existing Bundle - Document MDI to EDRS
  • Creating a new valid Bundle - Document MDI to EDRS
  • Posting a valid Bundle - Document MDI to EDRS to an EDRS data consumer

Electronic Death Reporting System (EDRS) server is responsible for:

  • Receiving a query from an MDI system
  • Returning a valid Bundle - Document MDI to EDRS to an MDI system
  • Receiving and consuming a valid Bundle - Document MDI to EDRS from an MDI system

Conformance to Other Standards

This specification is based on US Core 4.0.0. It defines 16 new profiles in total. These profiles are based on a US Core profile where possible. Conformance to US Core profiles is expected in all cases where 1) a US Core Profile exists and 2) where no profile has been defined by this MDI specification. For example, instances of Patients, Practitioners, and Organizations are expected to conform to US Core profiles, respectively.

This specification uses or references US Core profiles:

Resources and Profiles

This specification defines the following resources. An overview and list of examples is available on the Artifact Index page.

Profiles defined for MDI to EDRS exchange use case:

  • Bundle - Document MDI to EDRS
  • Composition - MDI to EDRS
  • Observation - Cause of Death Part 1
  • Observation - Contributing Cause of Death Part 2
  • Observation - Death Date
  • Observation - How Death Injury Occurred
  • Observation - Manner of Death
  • Observation - Decedent Pregnancy
  • Observation - Tobacco Use Contributed to Death
  • Observation - Autopsy Performed Indicator
  • Procedure - Death Certification
  • Location - Death
  • Location - Injury

Profiles for forensic toxicology to MDI exchange use case:

  • Bundle - Message Toxicology to MDI
  • MessageHeader - Toxicology to MDI
  • DiagnosticReport - Toxicology Lab Result to MDI
  • Specimen - Toxicology Lab
  • Observation - Toxicology Lab Result

Extensions:

  • Extension - Tracking Number
  • Extension - Date Time
  • Extension - Date Day
  • Extension - Date Month
  • Extension - Date Year
  • Extension - Partial DateTime

Value Sets:

  • ValueSet - Contributory Tobacco Use
  • ValueSet - Certifier Types
  • ValueSet - Date Establishment Approach
  • ValueSet - Death Pregnancy Status
  • ValueSet - Manner of Death
  • ValueSet - Place of Death
  • ValueSet - Tracking Number Type
  • ValueSet - Transportation Incident Role
  • ValueSet - Units of Age
  • ValueSet - Yes No Unknown
  • ValueSet - Yes No Unknown NotApplicable
  • ValueSet - Yes, No, Not Applicable

Code System:

  • CodeSystem - MDI
  • CodeSystem - Death Pregnancy Status
  • CodeSystem - Local Component Codes

MustSupport and Missing Data

Systems claiming to conform to an MDI profile SHALL support the elements in the profile as defined below. This guide adopts the following definitions of MustSupport for all direct transactions between the data source systems and data consumer systems.

Data Source Systems

  • As part of the sending of a Message Bundle or Document Bundle, the Data Source system SHALL be capable of including all elements defined in the profiles that have a MustSupport flag and SHALL populate all elements with a MustSupport flag if the information exists.
  • In situations where information on a particular data element is not present, the Data Source system SHALL NOT include the data element in the resource instance if the cardinality is 0..n.
  • If the information does not exist and the cardinality of the element is >= 1..*, the Data Source system SHALL follow the US Core Missing Data guidance.

Data Consumer Systems

  • Data Consumer systems SHALL be capable of processing resource instances containing required and allowed data elements without generating an error or causing the application to fail.
  • Data Consumer systems SHOULD be capable of processing (display, store, etc.) the data elements based on the utility of the specific element to the receiver.
  • When receiving a transaction from a Data Source system, the Data Consumer system SHALL interpret missing data elements within resource instances as data not present in the Data Source system.
  • Data Consumer systems SHALL be able to process resource instances containing data elements asserting missing information without generating an error or causing the application to fail.

This implementation guide does not define any new FHIR Search capabilities or parameters.

Privacy and Security

This Implementation Guide is adopting the security considerations from US Core Security

Data Models

Figure: MDI Profile Relationships

Figure: Forensic Toxicology Profile Relationships