Medicolegal Death Investigation (MDI) FHIR Implementation Guide, published by HL7 International / Public Health. This guide is not an authorized publication; it is the continuous build for version 2.0.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-mdi-ig/ and changes regularly. See the Directory of published versions
This MDI FHIR IG 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.
The Bundle - Document MDI and EDRS profile represents a document exchanged between an MDI CMS and EDRS. It can be used for bi-directional exchange during the process of case record creation and updating. The Bundle contains a Composition - MDI and EDRS. The Composition - MDI and EDRS profile represents data exchanged between an MDI CMS and an EDRS, which can be in “draft” (non-finalized) by:
This MDI IG uses the US Core Patient for the decedent subject of:
The US Core Patient provides structure for capturing basic demographic information (race, ethnicity, birth sex, gender identity, birth date, telecom, address, and marital status). The Composition - MDI and 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 US Core Patient profile requires
These three data elements may not be known during early stages of medicolegal data collection. US Core provide guidance on such cases of missing data.
In addition to the Patient.gender required data element described above, implementers have the option to describe the decedent’s sex at birth via the US Core Birth Sex Extension, which provides codes for classifying the person’s sex assigned at birth.
The US Core Patient Profile contains the optional data element Patient.deceased. It may be used to indicate if the individual is deceased or not. An implementer has a choice of using Boolean (true/false) values or dateTime. If dateTime is used, it should match the Observation - Death Date value[x]. The Participant & Supporting Examples section of the Artifacts Index page provides an example of a US Core Patient for which no information known about the decedent's name.
This MDI IG provides opportunities for both identifiers and tracking numbers.
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 CMS to an EDRS can use the status data element to indicate preliminary or final and certified.
This MDI FHIR IG 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 and EDRS author and attester are required and are the individual who will be listed as the certifier on the death certificate.
Unknown author/attester: Use the Extension: Data Absent Reason for instances when the author and/or attester is not yet known, for example in initial drafts of the MDI Composition.
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:
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.
Options for qualifying the accuracy of the date 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 MDI CMS certifies the content of the data elements, the data must not risk being truncated or lost by the receiving systems along the entire dataflow. 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.
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: Medical examiners and coroners 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 choice of text or code allows exchange of results 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:
This MDI FHIR IG is designed for RESTful API implementations supporting data exchange interactions between systems via FHIR extended operations. (See RESTful API for an overview.) This MDI IG 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 FHIR IG must conform to common design rules:
The CapabilityStatement resources defined in this MDI FHIR IG are of kind=requirements, so represent recommended capabilities of systems involved in MDI data exchange. They specify the bare minimum interactions and operations for a limited group of MDI resources.
It is expected that any specific FHIR server implementing this MDI FHIR IG may allow or require more interactions and operations for a larger set of resources than those specified in the CapabilityStatement resources listed above. An example of a CapabilityStatement that defines the full capabilities of a specific FHIR server (kind=instance), is available for the Raven FHIR Server, maintained by Georgia Tech Research Institute (GTRI):
An MDI-based Search API enables an MDI CMS to search an EDRS server for decedent cases, and vice versa. This is an idempotent operation (i.e., it has no additional effect if it is called more than once with the same input parameters). At a minimum, both POST and GET should be allowed with the following endpoint URL pattern:
Table: Summary of Minimum MDI Search Parameter Definitions
Search Parameter Name | Cardinality | Type | Description |
In Parameters | |||
id | 0..1 | uri | Composition.id of Composition - MDI and EDRS |
tracking-number | 0..* | token | Composition.extension:extension-tracking-number of Composition - MDI and EDRS |
patient | 0..* | One or more decedent-related search parameters | |
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 |
death-location | 0..1 | string | Location.address in Location-death |
death-date | 0..1 | date | Value[x] (actual or presumed date of death) in Observation - Death Date (either dateTime or Period) |
death-date-pronounced | 0..1 | date | Observation.component:datetimePronouncedDead in Observation - Death Date (either time or dateTime) |
Out Parameters | |||
return | 0..1 | Bundle | Bundle - Searchset or Bundle - Document MDI and EDRS. If [id] is supplied, then this should be Bundle - Document MDI and EDRS |
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]/$document), then the output response should be an MDI document bundle as there will be only one or zero result.