Vital Records Medicolegal Death Investigation (MDI) FHIR Implementation Guide
2.0.0-ballot - ballot United States of America flag

This page is part of the Medicolegal Death Investigation (MDI) (v2.0.0-ballot: STU 2 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 1.1.0. 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: 2.0.0-ballot
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 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

CapabilityStatement - Electronic Death Reporting System (EDRS) Server

  • Title:CapabilityStatement - Electronic Death Reporting System (EDRS) Server
  • Implementation Guide Version: 2.0.0-ballot
  • 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

Description:

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.



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, Observation - 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 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 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