Medicolegal Death Investigation (MDI) FHIR Implementation Guide
2.0.0-ballot2 - STU2 ballot 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-ballot2 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

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

Official URL: http://hl7.org/fhir/us/mdi/CapabilityStatement/CapabilityStatement-edrs-server Version: 2.0.0-ballot2
Active as of 2022-07-03 Computable Name: CapabilityStatementEDRSServer
Other Identifiers: OID:2.16.840.1.113883.4.642.40.11.13.1

This resource describes the expected minimum capabilities of the Electronic Death Registration System (EDRS) server, which is responsible for providing responses to the queries submitted by a client. 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

CapabilityStatement - Electronic Death Reporting System (EDRS) Server

  • Title:CapabilityStatement - Electronic Death Reporting System (EDRS) Server
  • Implementation Guide Version: 2.0.0-ballot2
  • FHIR Version: 4.0.1
  • Intended Use: Requirements
  • Supported Formats: application/fhir+xml; xml; application/fhir+json; json;
  • Published: 2022-07-03
  • Published by: HL7 International / Public Health
  • Status: Active
  • Copyright:

Description:

This resource describes the expected minimum capabilities of the Electronic Death Registration System (EDRS) server, which is responsible for providing responses to the queries submitted by a client. Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.



Jump to:


FHIR Server RESTful Capabilities

Summary of Resource/Profile Capabilities

Resource Type Supported Interactions Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations
Composition read, search-type, Composition - MDI and EDRS, subject, patient, $operation-composition-document
Patient read, search-type, US Core Patient Profile, _id, birthdate, family, given, gender, name,
Location read, search-type, Death Location, address,
Observation read, search-type, Death Date, date,

RESTful Server Capabilities by Resource/Profile:

Composition

Conformance Expectation: SHALL

Supported Profiles:

Composition Interaction Summary:

  • SHALL support read, search-type,

Fetch and Search Criteria:

  • A Server SHALL be capable of a read interaction returning a Composition resource using: GET [base]/Composition/[id]
  • A Server SHALL be capable of a search-type interaction returning Composition resources matching a search query using: GET [base]/Composition/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example
SHALL subject Token GET [base]/Composition?subject=[system]|[code]
SHALL patient Token GET [base]/Composition?patient=[system]|[code]

Patient

Conformance Expectation: SHALL

Supported Profiles:


Fetch and Search Criteria:

  • A Server SHALL be capable of a read interaction returning a Patient resource using: GET [base]/Patient/[id]
  • A Server SHALL be capable of a search-type interaction returning Patient resources matching a search query using: GET [base]/Patient/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example
SHALL _id Token GET [base]/Patient?_id=[id]
SHALL birthdate Date/DateTime GET [base]/Patient?birthdate=[dateTime]
SHALL family String GET [base]/Patient?family=[family]
SHALL given String GET [base]/Patient?given=[given]
SHALL gender Token GET [base]/Patient?gender=[system]|[code]
SHALL name String GET [base]/Patient?name=[name]

Location

Conformance Expectation: SHALL

Supported Profiles:


Fetch and Search Criteria:

  • A Server SHALL be capable of a read interaction returning a Location resource using: GET [base]/Location/[id]
  • A Server SHALL be capable of a search-type interaction returning Location resources matching a search query using: GET [base]/Location/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example
SHALL address String GET [base]/Location?address=[address]

Observation

Conformance Expectation: SHALL

Supported Profiles:


Fetch and Search Criteria:

  • A Server SHALL be capable of a read interaction returning a Observation resource using: GET [base]/Observation/[id]
  • A Server SHALL be capable of a search-type interaction returning Observation resources matching a search query using: GET [base]/Observation/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

Conformance Parameter Type Example
SHALL date Date/DateTime GET [base]/Observation?date=[dateTime]

FHIR Client RESTful Capabilities

Summary of Resource/Profile Capabilities

Resource Type Supported Interactions Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations
Bundle read, Bundle - Document MDI and EDRS,

RESTful Client Capabilities by Resource/Profile:

Bundle

Conformance Expectation:

Supported Profiles:


Fetch and Search Criteria:

  • A Client (conformance expectation undefined) be capable of a read interaction fetching a Bundle resource using: GET [base]/Bundle/[id]


Documents

Mode Profile Notes
Producer Composition - MDI and EDRS
Consumer Composition - MDI and EDRS