Fact Of Death Direct Enquiry Response Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Home

FODDER Implementation Guide

Introduction

Welcome to the Fact Of Death Direct Enquiry Response (FODDER) Implementation Guide. FODDER defines a FHIR interface for querying deceased patient records from the Veritas Data Research Fact of Death API. This guide is developed in collaboration by Onyx Technology, LLC and Veritas Data Research to provide a standardized, secure method for healthcare organizations to verify patient death records.

Purpose

FODDER enables healthcare organizations to:

• Query Deceased Patient Records - Look up death records using standard FHIR Patient/$match operation
• Integrate Death Verification - Verify patient status before processing claims or providing services
• Ensure Accuracy - Receive confidence scores on match results for quality control
• Maintain Security - Use OAuth 2.0 SMART on FHIR authorization for system-to-system access
• Support Compliance - Document death verification for regulatory and audit requirements
• Reduce Manual Effort - Automate death record lookups that were previously manual processes

Key Features

FHIR-Based Interface

• Standard Operations: Uses the standard FHIR Patient/$match operation
• Profiled Resources: DeceasedPatient profile constraining US Core Patient, DeathRecordDocumentReference profile for optional death record PDFs
• Standard Extensions: Uses the FHIR match-grade extension for match quality (certain, probable, possible, certainly-not)
• Validation: All examples validate against defined profiles

Security and Authorization

• OAuth 2.0 Client Credentials: System-to-system authentication per SMART on FHIR STU 2.2.0
• Scoped Access: Specific system/Patient.s?operation=match scope
• TLS Encryption: All communications encrypted in transit
• Audit Logging: Track all API calls for compliance

Dual Publisher Support

• Onyx Technology, LLC: Healthcare technology and FHIR implementation leader
• Veritas Data Research: Provider of comprehensive death record data from public records

Use Cases

1. Insurance Claim Prevention

Verify deceased status before processing claims, preventing improper claim payments.

2. Eligibility Management

Update eligibility systems when patient death is confirmed through FODDER.

3. Deceased Identifier Reconciliation

Identify and flag records for patients known to be deceased in external databases.

4. Death Notification Verification

Confirm death notifications received from other sources against authoritative death records.

5. Registry Maintenance

Keep healthcare provider registries current by identifying deceased patients.

Technical Overview

Base Specifications

• FHIR Version: R4 (4.0.1)
• US Core Dependency: 6.1.0
• SMART on FHIR: STU 2.2.0
• IG Version: 0.1.0

Core Artifacts

DeceasedPatient Profile

Constrains the US Core Patient Profile to represent confirmed deceased individuals:

• Required: deceasedDateTime (exact date and time of death)
• Prohibited: deceasedBoolean (must use dateTime, not boolean)
• Identifiers: At least one identifier required (SSN, MRN, etc.)

DeathRecordDocumentReference Profile

Optionally includes a death record PDF in the $match response:

• Type: LOINC 64297-5 "Death certificate"
• Content: PDF attachment (inline base64 or by-reference URL)
• Placement: Bundle entry with search.mode = "include"

Standard match-grade Extension

Uses the FHIR-defined match-grade extension on Bundle entries:

• Values: certain, probable, possible, certainly-not
• Placed on Bundle.entry.search, not on the Patient resource

Patient/$match Operation

Standard FHIR operation for querying patients:

• Input: Standard FHIR Patient search parameters
• Output: Bundle of matching DeceasedPatient resources with optional DocumentReference entries
• Scoring: Match scores from 0.0 (no match) to 1.0 (exact match) paired with match-grade codes

Quick Start

For Implementers

1. Understand the Specification - Review the Specification page
2. Review Security - Check the Security page for authentication details
3. See Examples - Browse Examples for real-world query scenarios
4. Get OAuth Token - Configure client credentials and obtain OAuth 2.0 access token
5. Execute Queries - Start querying deceased patient records

Typical Query Flow

1. Get OAuth Token
   POST /oauth/token with client credentials
   
2. Execute Match Query
   POST /Patient/$match with patient identifiers
   
3. Process Results
   Review matches and confidence scores
   
4. Update Systems
   Update patient status or eligibility
   
5. Maintain Audit Log
   Log query and result for compliance

Scope

This implementation guide includes:

• Profiles: DeceasedPatient profile constraining US Core, DeathRecordDocumentReference profile for death record PDFs
• Standard Extensions: Uses the FHIR match-grade extension for match quality classification
• Examples: Realistic deceased patient and $match response examples with DocumentReference
• Operations: Patient/$match operation specification
• Security: OAuth 2.0 and authorization documentation
• Guidance: Implementation best practices and use case examples

Publisher Information

Onyx Technology, LLC and Veritas Data Research

Developed collaboratively to provide healthcare organizations with a standards-based interface to death record verification services.

• Onyx Technology: https://onyxhealth.io
• Veritas Data Research: https://www.veritasdr.com

Author Information

Mark Scrimshire

• Email: Mark.Scrimshire@onyxhealth.io
• Organization: Onyx Technology, LLC

Getting Help

For questions about FODDER implementation:

1. Review the Security page for authentication issues
2. Check Examples for common query patterns
3. Contact your system administrator or service provider

References

• FHIR R4 Specification
• US Core 6.1.0 Implementation Guide
• SMART App Launch STU 2.2.0
• FHIR Patient/$match Operation

Acknowledgments

This implementation guide is developed for graduate-level academic work and represents best practices in FHIR standards compliance and healthcare interoperability.