Medicolegal Death Investigation (MDI) FHIR Implementation Guide
2.0.0-cibuild - ci-build United States of America flag

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

MDI 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 CMS & EDRS
  • Message Bundle - Required for Forensic Toxicology LIMS & MDI CMS

Actors & Roles

This specification defines three actors:

  • Forensic Toxicology LIMS: A data source for the Message Bundle that contains the Toxicology Lab Result to MDI Diagnostic Report.
  • MDI CMS: An application used by medical examiner and coroner offices that is a data consumer of the Message Bundle from the forensic toxicology LIMS and a data source and consumer of the Document Bundle MDI to EDRS.
  • EDRS: An application used by jurisdictional vital records agencies that 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 CMS 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 CMS data consumer

MDI CMS 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

EDRS server is responsible for:

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

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 Artifacts Index Summary.

Profiles defined for MDI CMS and 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 CMS 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

Administrative profile for exchanging PDF documents:

  • DocumentReference - MDI Report

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 - Yes No Unknown
  • ValueSet - Yes No Unknown NotApplicable

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 IG does not define any new FHIR Search capabilities or parameters.

Data Models

Figure: MDI Profile Relationships

Figure: Forensic Toxicology Profile Relationships

Cross Version Analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (hl7.fhir.us.mdi.r4) and R4B (hl7.fhir.us.mdi.r4b) are available.

Dependency Table

IGPackageFHIRComment
.. Medicolegal Death Investigation (MDI) FHIR Implementation Guidehl7.fhir.us.mdi#2.0.0-cibuildR4
... HL7 Terminology (THO)hl7.terminology.r4#6.0.2R4Automatically added as a dependency - all IGs depend on HL7 Terminology
... FHIR Extensions Packhl7.fhir.uv.extensions.r4#5.1.0R4Automatically added as a dependency - all IGs depend on the HL7 Extension Pack
... US Core Implementation Guidehl7.fhir.us.core#5.0.1R4
.... HL7 Terminology (THO)hl7.terminology.r4#3.1.0R4
.... Bulk Data Access IGhl7.fhir.uv.bulkdata#2.0.0R4
.... SMART App Launchhl7.fhir.uv.smart-app-launch#2.0.0R4
.... VSACus.nlm.vsac#0.7.0R4
.... Structured Data Capturehl7.fhir.uv.sdc#3.0.0R4
... VSACus.nlm.vsac#0.15.0R4
... PHINVadsus.cdc.phinvads#0.12.0R4
... HL7 FHIR Profile: Occupational Data for Health (ODH), Release 1, STU 1.2 (Standard for Trial Use)hl7.fhir.us.odh#1.2.0R4
.... US Corehl7.fhir.us.core#3.1.1R4
... Vital Records Common Library (VRCL) FHIR Implementation Guidehl7.fhir.us.vr-common-library#2.0.0R4
.... VSACus.nlm.vsac#0.19.0R4
... Vital Records Death Reporting (VRDR) FHIR Implementation Guidehl7.fhir.us.vrdr#3.0.0R4
.... HL7 FHIR Profile: Occupational Data for Health (ODH), Release 1, STU 1.3 (Standard for Trial Use)hl7.fhir.us.odh#1.3.0R4
..... HL7 Terminology (THO)hl7.terminology.r4#5.0.0R4

Package hl7.fhir.uv.extensions.r4#5.1.0

This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, Apr 27, 2024 18:39+1000+10:00)

Package hl7.fhir.uv.bulkdata#2.0.0

FHIR based approach for exporting large data sets from a FHIR server to a client application (built Fri, Nov 26, 2021 05:56+1100+11:00)

Package hl7.fhir.uv.sdc#3.0.0

The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR.
This includes two components:
* Support more sophisticated questionnaire/form use-cases such as those needed for research, oncology, pathology and other clinical domains.
*Support pre-population and auto-population of EHR data into forms/questionnaires for uses outside direct clinical care (patient safety, adverse event reporting, public health reporting, etc.). (built Tue, Mar 8, 2022 18:32+0000+00:00)

Package hl7.fhir.us.core#5.0.1

The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Wed, Jun 22, 2022 19:44+0000+00:00)

Package hl7.fhir.us.odh#1.2.0

HL7 FHIR Profile: Occupational Data for Health (ODH), Release 1.2 (Standard for Trial Use)

This Implementation Guide is a reconciled version, containing changes in response to comments received in the Sept. 2018 ballot. It has been updated to FHIR R4.0.1.

Introduction and Guidance

This Implementation Guide (IG) contains profiles to implement support for Occupational Data for Health (ODH). ODH describes structured work information primarily designed to facilitate clinical care, including population health and value-based care. ODH also can be used to support public health reporting. ODH is not designed to support billing activities. This set of FHIR profiles is specified as a composition resource, but it is not intended to be used as a stand-alone composition. Rather, the desired content should be included in broader IGs and available as a response to requests for ODH information. Some use cases may leverage only a subset of the ODH profiles, and these should be specified within those work products. For instance, in the Vital Records Death Reporting (VRDR) IG, the data requirements for work information are limited to those in the Usual Work profile. While this profile is specified for the US Realm, the design is intended to also support international needs. Three of the referenced value sets—Occupation, Industry, and Supervisory Level— are necessarily US specific. The remaining three value sets—Work Schedule, Employment Status, and Work Classification—use international concepts. Input is requested regarding whether these should be specified as ‘extensible’, ‘required’ (using ‘text only’ where a concept does not yet exist such as a new occupation), or as an ‘example’ for those US specific concepts.

Background

The majority of adults in the U.S. spend more than half their waking hours at work. Therefore, health and work are inextricably inter-related. For example, the management of chronic conditions requires taking the patient’s work environment into consideration. Work-related conditions are often first brought to the attention of a primary care provider. Some conditions related to exposure to hazards in the workplace can have a long latency, requiring knowledge of a person’s work history for recognition, diagnosis, and treatment. The recognition of new conditions related to previously unknown workplace hazards has often come from astute clinicians, which requires knowledge of the patient’s work. ONC has indicated recognition of the value of work information for health care. The incorporation of ODH into Electronic Health Records (EHRs) and other health IT systems presents an opportunity to improve health in relation to work. ODH provides a structure and standardization for work information that can be used across systems to take advantage of system tools for clinical decision support, population health, and public health. Research has been conducted and guidance is available to support clinicians, and the use of ODH by health IT systems can support identification of patients that would benefit the most from this knowledge.

Scope

The Occupational Data for Health (ODH) FHIR IG covers information about a patient’s work, including some voluntary work, or a patient’s household members’ work. ODH is designed for the social history section of a medical record, to facilitate clinical care in multiple disciplines and delivery environments. ODH can be used for clinical decision support, population health activities and value-based care, and public health reporting. The scope of the work information in ODH includes:

• Employment Status

• Retirement Date

• Combat Zone Period

• Past or Present Job for the patient or a household member, which includes:

	o	Past or Present Job Occupation
	
	o	Past or Present Job Industry
	
	o	Work Classification
	
	o	Work Schedule, which includes:
			
			- Weekly Work Days
			
			- Daily Work Hours
	
	o	Job Duty
	
	o	Occupational Hazard
	
	o	Employer name
	
	o	Employer address
	
	o	Related Subject (when it is Past or Present Job of a household member of the person)
	
	o	Start/End Dates

• Usual Work of the patient or a household member, which includes:

	o	Usual Occupation
	
	o	Usual Industry
	
	o	Usual Occupation Duration
	
	o	Related Subject (when it is Usual Work of a household member of the person)
	
	o	Start Date

Known Issues and Limitations

This IG includes more extensive occupational data than typically collected in current systems. The content and structure of this IG is intended to inform clinical care, support population health, and contribute to public health activities. While there may be some overlap with administrative and billing information maintained by some systems, the information in this IG is not designed to support billing and administrative needs. While multiple retirement dates are supported, the retirement date is not linked to any specific job, or usual occupation.

Credits

Co-Editor: Lori Reed-Fourquet e-HealthSign, LLC lfourquet@ehealthsign.com

Co-Editor: Rob Hausam Hausam Consulting rob@hausamconsulting.com

Co-Editor: Mark Kramer MITRE Corporation mkramer@mitre.org

This set of FHIR profiles was produced and developed through the efforts of a project of the National Institute of Occupational Safety and Health (NIOSH), the U.S. federal agency responsible for conducting research and making recommendations for the prevention of work-related injury and illness. NIOSH is a part of the U.S. Centers for Disease Control and Prevention (CDC). NIOSH consulted stakeholders in clinical care, public health, health IT, health informatics and U.S. government agencies to develop ODH. The HL7® Public Health and Emergency Response Work Group sponsored development of this set of FHIR profiles. Co-sponsoring HL7® Work Groups were Orders and Observations (OO), Patient Administration (PA), and Clinical Quality Initiative (CQI). The following individuals provided subject matter expertise for this set of FHIR profiles: Genevieve Barkocy Luensman, NIOSH; Eileen Storey, Professional Services Partners, formerly NIOSH; Margaret S. Filios, NIOSH; Christina Socias-Morales, NIOSH; Lauren Brewer, NIOSH; Barbara Wallace, Professional Services Partners.

Authors

Name Email/URL HL7 International - Public Health http://www.hl7.org/Special/committees/pher (built Wed, Aug 17, 2022 16:01+0000+00:00)

Package hl7.fhir.us.odh#1.3.0

HL7 FHIR Profile: Occupational Data for Health (ODH), Release 1.3 (Standard for Trial Use)

This Implementation Guide is a reconciled version, containing changes in response to comments received in the Sept. 2018 ballot. It has been updated to FHIR R4.0.1.

Introduction and Guidance

This Implementation Guide (IG) contains profiles to implement support for Occupational Data for Health (ODH). ODH describes structured work information primarily designed to facilitate clinical care, including population health and value-based care. ODH also can be used to support public health reporting. ODH is not designed to support billing activities. This set of FHIR profiles is specified as a composition resource, but it is not intended to be used as a stand-alone composition. Rather, the desired content should be included in broader IGs and available as a response to requests for ODH information. Some use cases may leverage only a subset of the ODH profiles, and these should be specified within those work products. For instance, in the Vital Records Death Reporting (VRDR) IG, the data requirements for work information are limited to those in the Usual Work profile. While this profile is specified for the US Realm, the design is intended to also support international needs. Three of the referenced value sets—Occupation, Industry, and Supervisory Level— are necessarily US specific. The remaining three value sets—Work Schedule, Employment Status, and Work Classification—use international concepts. Input is requested regarding whether these should be specified as ‘extensible’, ‘required’ (using ‘text only’ where a concept does not yet exist such as a new occupation), or as an ‘example’ for those US specific concepts.

Background

The majority of adults in the U.S. spend more than half their waking hours at work. Therefore, health and work are inextricably inter-related. For example, the management of chronic conditions requires taking the patient’s work environment into consideration. Work-related conditions are often first brought to the attention of a primary care provider. Some conditions related to exposure to hazards in the workplace can have a long latency, requiring knowledge of a person’s work history for recognition, diagnosis, and treatment. The recognition of new conditions related to previously unknown workplace hazards has often come from astute clinicians, which requires knowledge of the patient’s work. ONC has indicated recognition of the value of work information for health care. The incorporation of ODH into Electronic Health Records (EHRs) and other health IT systems presents an opportunity to improve health in relation to work. ODH provides a structure and standardization for work information that can be used across systems to take advantage of system tools for clinical decision support, population health, and public health. Research has been conducted and guidance is available to support clinicians, and the use of ODH by health IT systems can support identification of patients that would benefit the most from this knowledge.

Scope

The Occupational Data for Health (ODH) FHIR IG covers information about a patient’s work, including some voluntary work, or a patient’s household members’ work. ODH is designed for the social history section of a medical record, to facilitate clinical care in multiple disciplines and delivery environments. ODH can be used for clinical decision support, population health activities and value-based care, and public health reporting. The scope of the work information in ODH includes:

• Employment Status

• Retirement Date

• Combat Zone Period

• Past or Present Job for the patient or a household member, which includes:

o Past or Present Job Occupation

o Past or Present Job Industry

o Work Classification

o Work Schedule, which includes:

- Weekly Work Days

- Daily Work Hours

o Job Duty

o Occupational Hazard

o Employer name

o Employer address

o Related Subject (when it is Past or Present Job of a household member of the person)

o Start/End Dates

• Usual Work of the patient or a household member, which includes:

o Usual Occupation

o Usual Industry

o Usual Occupation Duration

o Related Subject (when it is Usual Work of a household member of the person)

o Start Date

Known Issues and Limitations

This IG includes more extensive occupational data than typically collected in current systems. The content and structure of this IG is intended to inform clinical care, support population health, and contribute to public health activities. While there may be some overlap with administrative and billing information maintained by some systems, the information in this IG is not designed to support billing and administrative needs. While multiple retirement dates are supported, the retirement date is not linked to any specific job, or usual occupation.

Credits

Co-Editor: Lori Reed-Fourquet e-HealthSign, LLC lfourquet@ehealthsign.com

Co-Editor: Rob Hausam Hausam Consulting rob@hausamconsulting.com

Co-Editor: Mark Kramer MITRE Corporation mkramer@mitre.org

This set of FHIR profiles was produced and developed through the efforts of a project of the National Institute of Occupational Safety and Health (NIOSH), the U.S. federal agency responsible for conducting research and making recommendations for the prevention of work-related injury and illness. NIOSH is a part of the U.S. Centers for Disease Control and Prevention (CDC). NIOSH consulted stakeholders in clinical care, public health, health IT, health informatics and U.S. government agencies to develop ODH. The HL7® Public Health and Emergency Response Work Group sponsored development of this set of FHIR profiles. Co-sponsoring HL7® Work Groups were Orders and Observations (OO), Patient Administration (PA), and Clinical Quality Initiative (CQI). The following individuals provided subject matter expertise for this set of FHIR profiles: Genevieve Barkocy Luensman, NIOSH; Eileen Storey, Professional Services Partners, formerly NIOSH; Margaret S. Filios, NIOSH; Christina Socias-Morales, NIOSH; Lauren Brewer, NIOSH; Barbara Wallace, Professional Services Partners.

Authors

Name Email/URL HL7 International - Public Health http://www.hl7.org/Special/committees/pher (built Wed, Mar 22, 2023 12:13+1100+11:00)

Global Profiles Table

There are no Global profiles defined

IP Statements

This publication includes IP covered under the following statements.