Medicolegal Death Investigation (MDI)
1.1.0 - STU 1.1 United States of America flag

This page is part of the Medicolegal Death Investigation (MDI) (v1.1.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

CapabilityStatement: CapabilityStatement - Electronic Death Reporting System (EDRS) Server

Official URL: http://hl7.org/fhir/us/mdi/CapabilityStatement/CapabilityStatement-edrs-server Version: 1.1.0
Active as of 2022-07-03 Computable Name: CapabilityStatementEDRSServer

This resource describes the expected capabilities of the Electronic Death Registration System (EDRS) Server actor, which is responsible for providing responses to the queries submitted by the EDRS Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by EDRS Servers are defined. EDRS Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

Raw OpenAPI-Swagger Definition file | Download

EDRS Server Capabilities Summary

  • The EDRS Server should be a consumer of Composition-mdi-and-edrs, and may also be a producer of Composition-mdi-and-edrs
  • The EDRS Server may specify RESTful operations for resources. At a minimum, it should support read and search for the set of resources defined here.

API Specifications Search Operations

The EDRS Server may use extended operations with MDI-specific search parameters and a subset of the many (RESTful API)[https://hl7.org/FHIR/http.html].

All API implementations of this MDI FHIR IG 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 an MDI CMS to search an EDRS for decedent cases, and vice versa. This is an idempotent operation. At a minimum, both Both POST and GET can be used should be allowed with the following endpoint URL pattern:

  • POST [base]/Composition/$document
  • GET [base]/Composition/$document?name=value…

Summary of Minimum EDRS 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 US Core Patient 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