The Next Frontier of Interoperability: Dental, Devices, Social Determinants, and Behavioral Health Data

Hospital EHR interoperability is largely a solved problem. Epic, Oracle Health (Cerner), and MEDITECH systems exchange clinical data through FHIR R4 APIs, TEFCA-enabled QHINs, and mature HL7v2 interfaces. The ONC's certification requirements, CMS interoperability mandates, and the 21st Century Cures Act information blocking rules have created a regulatory environment where acute care EHR data exchange is not just possible but expected. US Core Implementation Guide adoption exceeds 90% among certified health IT products. FHIR US Core has become the lingua franca of hospital data exchange.

But step outside the hospital EHR ecosystem, and the interoperability landscape looks radically different. Four critical domains of health data remain almost entirely disconnected from the broader healthcare data ecosystem: dental records, medical device and IoT data, social determinants of health (SDOH) information, and behavioral health data. Together, these domains represent hundreds of millions of patient data points that clinicians, population health analysts, and care coordinators cannot access when they need them most.

This is not a theoretical problem. A primary care physician treating a diabetic patient cannot see that same patient's periodontal disease progression from their dental EHR, even though oral-systemic health connections are well-documented. An ICU clinician cannot automatically pull continuous vital signs from a bedside ventilator into the EHR without proprietary middleware. A care manager cannot electronically verify whether a patient referred to a food bank actually received services. And a psychiatrist treating co-occurring substance use disorder faces regulatory barriers that effectively wall off treatment records from the rest of the care team.

This guide maps the interoperability frontier: what is connected, what is not, why each gap exists, and the specific standards, implementation guides, and policy changes needed to close them. If hospital EHR interoperability was the first chapter of health data exchange, these four domains are the next chapter, and the organizations that solve them will define the future of whole-person care.

The Interoperability Map: What Is Connected vs. What Is Not

To understand the magnitude of the remaining interoperability challenge, it is useful to map the current state of health data exchange across domains.

Connected Zones: Where Interoperability Works Today

Hospital EHR systems represent the most mature interoperability domain. Epic's Care Everywhere network alone facilitates over 200 million patient record exchanges per month. Oracle Health's CommonWell Health Alliance and the Carequality framework enable cross-vendor data exchange. With TEFCA's Qualified Health Information Networks (QHINs) going live, nationwide query-based exchange is becoming operational reality. FHIR R4 APIs certified under ONC's Health IT Certification Program support standardized patient access and provider-to-provider exchange.

Health Information Exchanges (HIEs) aggregate clinical data from hospitals, ambulatory practices, and post-acute facilities. State-designated HIEs like Indiana's IHIE, New York's SHIN-NY, and California's CalHIE have demonstrated sustainable models for community-wide data sharing. The Sequoia Project's Carequality framework connects over 70% of US hospitals through a network of networks.

Laboratory and pharmacy systems are deeply integrated through decades of HL7v2 messaging (ORM/ORU for lab orders and results, RDE/RDS for pharmacy). Electronic lab reporting to public health agencies is mandated and mature. Pharmacy benefit management systems exchange data through NCPDP SCRIPT standards. While FHIR adoption is growing in this space, the existing HL7v2 infrastructure works reliably.

Claims and billing systems use X12 EDI standards (837/835 for claims and remittance, 270/271 for eligibility, 278 for prior authorization) that have been mandated under HIPAA since 2003. The CMS-0057-F rule is adding FHIR-based APIs for prior authorization and payer-to-payer data exchange, building a modern layer on top of proven EDI infrastructure.

Dark Zones: Where Interoperability Fails

In contrast, four domains remain largely disconnected from this ecosystem. Each has different root causes, different standards trajectories, and different timelines to resolution.

Domain 1: Dental Data — The Oral-Systemic Divide

Dentistry operates in a parallel universe from the rest of healthcare IT. While hospital EHRs have converged around a handful of major vendors with standardized interfaces, the dental ecosystem is fragmented across hundreds of practice management systems and electronic dental records (EDRs) that were never designed to exchange data with medical systems.

The Scale of the Problem

According to the American Dental Association (ADA) and recent research published in PMC, only 42% of dental providers in co-located facilities can enter information into patients' general medical records via the health center's EHR system. The remaining 58% operate in complete isolation from the medical record. Even at federally qualified health centers (FQHCs) that offer both medical and dental services under one roof, the dental and medical records often exist in separate, non-communicating systems.

The dominant dental software platforms, including Henry Schein's Dentrix, Patterson's EagleSoft, and the open-source Open Dental, function primarily as practice management systems (scheduling, billing, charting) rather than clinical interoperability platforms. They were built to manage the business of a dental practice, not to participate in health information exchange. Most do not natively support FHIR, HL7v2, or CDA document exchange with medical systems.

Why the Dental-Medical Gap Matters Clinically

The oral-systemic health connection is well-established in clinical literature. Research published in PMC documents the bidirectional relationship between periodontal disease and systemic conditions including diabetes, cardiovascular disease, adverse pregnancy outcomes, and respiratory infections. Patients with uncontrolled diabetes are three times more likely to develop periodontal disease, and periodontal disease makes glycemic control more difficult, creating a vicious cycle that neither the dentist nor the endocrinologist can see in full because the data lives in disconnected systems.

A practical example: a patient presents to their primary care physician with elevated HbA1c despite medication adherence. The physician adjusts the diabetes medication. Meanwhile, the patient's dentist is treating severe periodontal disease that is contributing to systemic inflammation and insulin resistance. Neither provider sees the other's data. Neither can coordinate a treatment plan that addresses both the oral and systemic components. The result is suboptimal outcomes and wasted resources on both sides.

Emerging Standards: HL7 Dental Data Exchange IG

The HL7 Dental Data Exchange Implementation Guide (currently in version 2.0.0-ballot as of April 2025) defines FHIR-based profiles for bi-directional information exchange between medical and dental providers. The IG specifies how to represent dental conditions, procedures, and observations using FHIR R4 resources including Condition, Procedure, Observation, and ServiceRequest.

Key capabilities defined in the Dental Data Exchange IG include:

• Dental referral workflows: A medical provider can electronically refer a patient to a dentist with structured clinical context (relevant diagnoses, medications, allergies) using FHIR ServiceRequest
• Dental consultation notes: A dentist can return a structured consultation note to the referring medical provider using FHIR DiagnosticReport and associated Observations
• Dental condition exchange: Periodontal disease status, caries risk assessments, and oral health findings can be represented as FHIR Condition resources with SNODENT-coded diagnoses
• Medication reconciliation: Dental providers can access and contribute to a patient's medication list, critical for managing drug interactions with dental anesthetics and antibiotics

The ADA has also developed the Oral Dataset Interoperability Network (ODIN), which aims to create a standardized dataset for oral health information that can be shared across systems. SNODENT, the Systematized Nomenclature of Dentistry (a subset of SNOMED CT), provides the terminology foundation for coded dental data.

The FDI World Dental Federation's 2025 Consensus Statement on Integrated Electronic Health Records calls for the adoption of common data models and internationally recognized interoperability standards including FHIR and DICOM for dental imaging. However, as the statement acknowledges, dentistry has been slower to achieve full integration into national and international EHR frameworks.

What Is Needed to Close the Dental Gap

Three concurrent developments are required. First, dental software vendors must implement FHIR R4 APIs in their products, which requires both technical investment and market incentive (currently lacking because ONC certification does not apply to dental software). Second, HIEs must extend their networks to include dental providers, which requires new participant agreements and data governance frameworks. Third, clinicians on both sides need education on the value of dental-medical data exchange, because interoperability is worthless if no one uses the data once it is available.

Domain 2: Medical Devices and IoT — The Proprietary Protocol Problem

Medical devices generate some of the most clinically valuable data in healthcare: continuous vital signs, ventilator parameters, infusion pump rates, blood glucose trends, cardiac rhythm data, and thousands of other measurements that drive minute-to-minute clinical decisions. Yet this data overwhelmingly flows through proprietary protocols that make integration with EHRs and analytics platforms extraordinarily difficult.

The Current State: A Tower of Babel

The medical device ecosystem is characterized by extreme fragmentation. A typical ICU contains devices from 10-15 different manufacturers, each with its own data format, communication protocol, and integration requirements. HL7 estimates that the lack of standardized device interoperability costs the US healthcare system billions of dollars annually in middleware, custom integrations, manual transcription, and lost clinical intelligence.

Major device manufacturers including Philips, GE HealthCare, Medtronic, Baxter, and Dräger each maintain proprietary communication stacks. While some support IEEE 11073 standards to varying degrees, implementation is inconsistent. A Philips patient monitor and a GE ventilator in the same ICU bay may speak entirely different data languages, requiring separate integration paths to the EHR.

IEEE 11073 and SDC: The Standards Landscape

The IEEE 11073 family of standards has been the primary attempt to standardize medical device communication. IEEE 11073 SDC (Service-oriented Device Connectivity) uses a service-oriented architecture including MDPWS (Medical Devices Communication Profile for Web Services) and a Domain Information Model (DIM) to provide detailed, real-time semantic interoperability for what the standard calls "plug-and-trust" communication.

However, IEEE 11073 adoption has been limited by several factors:

• Voluntary adoption: Unlike HL7v2 for lab messaging or X12 for claims, there is no regulatory mandate requiring medical devices to support IEEE 11073. Manufacturers adopt it selectively, if at all.
• Complexity of the standard: IEEE 11073 SDC is a comprehensive but complex framework. Implementing it requires significant engineering investment, which device manufacturers are reluctant to make without clear market demand.
• Legacy installed base: Hospitals have millions of dollars of installed medical devices that predate IEEE 11073. These devices cannot be upgraded and must be supported through proprietary interfaces for their remaining useful life (often 7-15 years).
• Real-time requirements: Critical care devices generate data at millisecond intervals. FHIR's HTTP-based request/response pattern was not designed for this kind of real-time streaming, creating a gap between device data rates and EHR ingestion capabilities.

The Caliper FHIR Accelerator: Bridging Devices to FHIR

In a significant development, HL7 launched the Caliper FHIR Accelerator in 2025, a dedicated implementation community focused on health device interoperability. The Caliper Accelerator builds on nearly 10 years of progress by the HL7 Devices on FHIR initiative and the 20+ year activities of the HL7 Devices Working Group.

Founding members include Dexcom (continuous glucose monitors) and GE HealthCare (patient monitoring, imaging), organizations that bring real-world implementation experience. The accelerator's scope covers the full range of device technologies: from high-acuity OR and ICU devices to home and mobile health applications, including both regulated medical devices and consumer wellness technologies.

The FHIR resources relevant to device interoperability include:

• Device: Represents the physical device, including its manufacturer, model, serial number, and UDI (Unique Device Identifier)
• DeviceMetric: Describes the measurement capabilities of a device, including calibration status, measurement type, and operational status
• Observation: Captures the actual measurements produced by the device, linked to the Device and patient through references

Real-Time vs. Batch: The Architecture Challenge

The fundamental architectural challenge in device integration is the mismatch between device data generation rates and EHR data consumption patterns. A patient monitor generates waveform data at 250-500 samples per second. An EHR typically processes discrete observations (heart rate, blood pressure) at one-minute intervals. Bridging this gap requires a multi-tier architecture:

• Tier 1 — Device Gateway: Receives raw device data via proprietary protocols or IEEE 11073, buffers it, and performs initial normalization. Handles real-time alarm forwarding with sub-5-second latency.
• Tier 2 — FHIR Transformation Engine: Converts normalized device data into FHIR Observation and DeviceMetric resources. Applies clinical validation rules (range checks, unit conversion, patient matching). Supports both streaming (for alarms and acute changes) and batch (for trending data).
• Tier 3 — Integration Platform: Routes FHIR resources to appropriate consumers: EHR for clinical documentation, analytics platform for population health, alarm management system for critical alerts, and research databases for clinical trials.

FDA Implications

The FDA has expressed interest in FHIR for real-world data collection from medical devices, publishing a Request for Comments in 2025 on the use of FHIR for study data from real-world data sources. This signals a potential future regulatory driver for device FHIR adoption. If FDA begins accepting FHIR-formatted device data for post-market surveillance and real-world evidence studies, manufacturers will have a concrete business reason to implement FHIR interfaces.

Domain 3: Social Determinants of Health — From Paper Screens to Digital Referrals

Social determinants of health account for an estimated 30-55% of health outcomes, according to the World Health Organization. Where a patient lives, what they eat, whether they have stable housing, their employment status, their transportation access, and their social support network all have measurable, significant impacts on their health status and healthcare utilization. Yet the vast majority of SDOH data remains trapped in paper screening forms, siloed community databases, and informal provider notes that never enter the structured clinical data ecosystem.

The Current State: Islands of SDOH Data

SDOH data exists in multiple disconnected locations. Clinical settings use validated screening tools like the AHC-HRSN (Accountable Health Communities Health-Related Social Needs) screening tool, PRAPARE (Protocol for Responding to and Assessing Patients' Assets, Risks, and Experiences), and the WellRx questionnaire. These screenings capture patient-reported social needs, but the data often stays in unstructured EHR notes or custom flowsheets that cannot be queried, aggregated, or shared.

Community-based organizations (CBOs) that actually deliver social services (food banks, housing assistance, transportation programs, utility assistance) typically use their own databases, spreadsheets, or the 211 information and referral system. These systems have no standard interface with healthcare systems. When a physician refers a patient to a food bank, the referral is typically made by phone, fax, or handoff of a printed resource list. The physician has no way to know whether the patient actually contacted the organization, received services, or had their need met.

Public health agencies maintain population-level SDOH data through the American Community Survey, Area Deprivation Index, and other geocoded datasets. But connecting individual patient-level social needs data with population-level SDOH indicators requires integration capabilities that most health systems lack.

The Gravity Project: Building the SDOH Interoperability Standard

The Gravity Project, now an HL7 FHIR Accelerator, is the most significant initiative addressing SDOH data interoperability. Launched in 2019, the Gravity Project develops consensus-driven data standards for the collection, use, and exchange of data to address social determinants of health.

The SDOH Clinical Care Implementation Guide (SDOH-CC IG), currently at STU 2.3 with STU 3.0 planned for ballot in January 2026, defines FHIR-based profiles for the complete SDOH workflow:

• Screening: FHIR Questionnaire and QuestionnaireResponse resources capture patient SDOH screening data using LOINC-coded instruments. Standardized screening tools (AHC-HRSN, PRAPARE, Hunger Vital Sign) have defined FHIR Questionnaire profiles.
• Assessment and diagnosis: Positive screening results are mapped to FHIR Condition resources coded with ICD-10-CM Z-codes (Z55-Z65 covering education, employment, housing, economic circumstances, social environment, and psychosocial factors). FHIR Observation resources capture individual SDOH risk factors.
• Goal setting: Patient and provider collaboratively set SDOH-related goals using FHIR Goal resources with Gravity-defined value sets (e.g., "Patient will secure stable housing within 60 days").
• Referral and intervention: FHIR ServiceRequest resources initiate referrals to community-based organizations. FHIR Task resources track referral fulfillment. FHIR Procedure resources document completed interventions.
• Closed-loop feedback: CBOs report intervention outcomes back to the referring provider through FHIR Task status updates, closing the referral loop and enabling care plan adjustments.

Z-Codes: The Terminology Foundation

ICD-10-CM Z-codes (Z55-Z65) provide the diagnostic coding foundation for SDOH conditions. The Gravity Project has worked with SNOMED CT International, the ICD-10-CM Coordination and Maintenance Committee, and the AMA to develop comprehensive value sets across 17 social risk domains including food insecurity, housing instability, transportation access, financial strain, social isolation, and intimate partner violence.

Despite their availability, Z-code adoption remains low. Fewer than 2% of Medicare claims include SDOH Z-codes, according to CMS data. Barriers include clinician unfamiliarity with Z-codes, lack of reimbursement incentive for SDOH screening, and EHR systems that do not make Z-code selection easy or intuitive.

State-Level Momentum

According to HL7 News (January 2026), state-level momentum around Gravity SDOH-CC IG implementation is growing significantly. CMS Medicaid policy now encourages states to align with Gravity standards for SDOH data exchange. Several state Medicaid programs have begun requiring managed care organizations to implement SDOH screening and referral workflows that align with Gravity-defined data standards.

The Data Architecture Gap: Connecting Clinical to Community

The technical architecture required to connect clinical SDOH screening to community service delivery spans three domains that have historically never been connected:

• Clinical EHR systems (Epic, Oracle Health) where screening occurs and diagnoses are recorded
• Referral platforms (Unite Us, findhelp/Aunt Bertha, NowPow) that match patients to community resources and manage the referral workflow
• CBO case management systems that track service delivery and outcomes at the community organization level

Each connection requires FHIR-based APIs, data governance agreements, patient consent management, and workflow integration. The Gravity Project provides the data standards, but the integration infrastructure, governance, and incentive structures are still being built.

Domain 4: Behavioral Health — The 42 CFR Part 2 Barrier

Behavioral health data, encompassing mental health treatment records and substance use disorder (SUD) treatment records, represents perhaps the most complex interoperability challenge of the four domains. The barriers are not primarily technical (although technical challenges exist). They are regulatory, cultural, and trust-based.

42 CFR Part 2: The Regulatory Wall

Since 1975, federal regulation 42 CFR Part 2 has imposed strict confidentiality requirements on substance use disorder patient records that are significantly more restrictive than HIPAA. Under the original Part 2 framework, SUD treatment records could not be disclosed without specific written consent from the patient for each intended recipient and each intended purpose. Redisclosure was prohibited: a hospital that received SUD records from a treatment facility could not share those records with another provider without obtaining a new consent from the patient.

This regulatory framework was designed to protect patients from the stigma and discrimination associated with substance use disorder. In the 1970s, when the regulation was written, the risk was real: SUD treatment information could be used to deny employment, housing, insurance, and even parental rights. The regulation served an important protective purpose.

However, the same regulation created a de facto information wall between SUD treatment and the rest of healthcare. Care coordination suffered. Emergency physicians could not access a patient's methadone dose when that patient presented to the ED. Primary care physicians could not see addiction treatment history when prescribing pain medications. Psychiatrists treating co-occurring mental health and substance use conditions had fragmented views of their patients' treatment history.

The 2024 Final Rule: Alignment with HIPAA

On February 8, 2024, the HHS Office for Civil Rights published a final rule significantly modernizing 42 CFR Part 2. Implementing section 3221 of the CARES Act, the rule became effective April 16, 2024, with a compliance date of February 16, 2026. Key changes include:

• Single consent for TPO: Patients can now provide a single, broad consent authorizing the use and disclosure of their Part 2 records for treatment, payment, and healthcare operations (TPO). This eliminates the previous requirement for separate, specific consents for each recipient and each purpose.
• Redisclosure permitted under TPO: Recipients of Part 2 records may redisclose the information for TPO purposes based on the patient's single consent. A hospital receiving SUD records can share them with a specialist without obtaining additional consent.
• HIPAA alignment: Part 2 records are now subject to HIPAA's individual rights provisions, including the right to access, the right to an accounting of disclosures, and breach notification requirements.
• Anti-discrimination protections: The rule prohibits the use of Part 2 information in civil, criminal, administrative, or legislative proceedings against the patient, and prohibits discrimination in employment, access to benefits, or provision of services based on Part 2 information.

According to NJII's analysis, the rule newly allows all federally assisted SUD providers to obtain a single, general record-sharing consent from a patient for all current and future disclosures, with redisclosure based on the single consent also newly applying to the recipients of Part 2 data. Data segmentation, while technically complex, is not required under federal law.

Remaining Challenges

Despite the significant progress represented by the 2024 final rule, substantial barriers to behavioral health data interoperability remain:

• Consent revocation complexity: Patients retain the right to revoke consent at any time. When a patient revokes consent, the revocation must propagate to all downstream recipients who received data under that consent. In a connected health ecosystem, tracking and enforcing consent revocation across multiple systems is technically demanding.
• State law variation: At least 14 states have behavioral health privacy laws that are stricter than the federal 42 CFR Part 2 requirements. Organizations operating across state lines must comply with the most restrictive applicable law, creating a patchwork of requirements that complicates national interoperability solutions.
• Stigma and trust: Even with regulatory modernization, many patients and providers remain cautious about sharing behavioral health data. The stigma associated with substance use disorder and mental health conditions has not disappeared, and patients may decline consent even when it is available as a single, simplified form.
• Technical segmentation: While data segmentation is not legally required, many EHR systems implemented segmentation capabilities to comply with the previous Part 2 framework. These segmentation architectures, once built, are difficult to remove. Some organizations may choose to maintain segmentation as a patient trust measure even when the law no longer requires it.
• Separate BH EHR systems: Many behavioral health providers use specialized EHR systems (Netsmart, Qualifacts, Credible) that are separate from the hospital EHR ecosystem. These systems have limited FHIR capabilities and limited connections to health information exchanges. Even if consent barriers are resolved, the technical plumbing for data exchange may not exist.

FHIR Consent Resource and Behavioral Health

The FHIR Consent resource provides a standardized way to represent patient consent decisions, including the scope of consent, the parties involved, the data categories covered, and the applicable policy. For behavioral health data sharing, the Consent resource can represent:

• Whether the patient has consented to Part 2 data sharing for TPO
• The date consent was granted and any revocation date
• Specific data categories or time periods covered or excluded
• The set of recipients authorized to receive the data

Operationalizing FHIR-based consent management for behavioral health requires integration between the consent management engine and every data exchange point in the system, ensuring that no data flows without validated consent and that consent revocations are enforced in real time.

USCDI v4 Through v7: What Is Being Added

The United States Core Data for Interoperability (USCDI) defines the minimum set of data classes and elements that must be exchanged across health IT systems. Each annual version expands the scope, and recent versions have directly addressed the four frontier domains discussed in this guide.

USCDI v4 (2024): Health Status Assessments and Facility Information

USCDI v4 added 20 data elements and one new data class (Facility Information) to USCDI v3. Critically for the frontier domains, v4 added:

• Alcohol Use and Substance Use data elements to the Health Status Assessments class, directly addressing the behavioral health data gap
• SDOH Assessment moved into the Health Status Assessments class, formalizing SDOH screening as a core data exchange requirement
• Physical Activity as a health status element, bridging device-generated activity data with the clinical record
• Treatment Intervention Preference and Care Experience Preference in Goals and Preferences, supporting patient-centered care across all domains
• Average Blood Pressure in Vital Signs, relevant to device-generated continuous BP monitoring data

USCDI v5 (2024) and v6 (2025): Continued Expansion

USCDI v5 added 16 data elements and two new data classes. USCDI v6, published July 2025, added 6 data elements including Care Plan, Portable Medical Order, and Unique Device Identifier (UDI), the last directly supporting medical device data integration.

USCDI v7 (2026 Draft): Significant Expansion

The Draft USCDI v7, published January 2026, proposes 30 new data elements across multiple data classes. This is the largest single-version expansion in USCDI history. Notable additions include the evolution of "Smoking Status" to "Tobacco Use" (a broader data element that captures all forms of tobacco and nicotine use), addressing the behavioral health screening gap.

USCDI+: Domain-Specific Extensions

ONC has also introduced USCDI+ domain-specific extensions that go beyond the core USCDI. USCDI+ Quality includes data elements specifically needed for quality measurement, while other USCDI+ variants address public health reporting, prior authorization, and behavioral health. These extensions allow federal programs to require additional data elements beyond the USCDI baseline without modifying the core standard.

Technical Architecture for Multi-Domain Integration

Connecting all four frontier domains to the healthcare data ecosystem requires a purposeful integration architecture that addresses the unique characteristics of each domain while providing a unified data layer for clinical, operational, and analytical consumers.

The Hub-and-Spoke FHIR Integration Pattern

The most viable architecture uses a central FHIR integration platform as a hub, with domain-specific adapters (spokes) that translate each domain's native data formats and protocols into standard FHIR resources:

• Dental spoke: Interfaces with dental practice management systems (Dentrix, EagleSoft) through their available APIs or export formats, translates dental conditions and procedures into FHIR Condition and Procedure resources using the Dental Data Exchange IG profiles, and maps SNODENT codes to SNOMED CT for cross-domain terminology alignment.
• Device spoke: Implements the IEEE 11073-to-FHIR bridge defined by the Caliper Accelerator. Handles real-time streaming for critical alarms (using FHIR Subscriptions or WebSocket connections) and batch processing for trending data (using standard FHIR REST operations). Maps device-specific codes to LOINC observation codes.
• SDOH spoke: Implements the Gravity Project SDOH-CC IG for screening, referral, and closed-loop feedback workflows. Integrates with referral platforms (Unite Us, findhelp) and CBO systems. Manages patient consent for SDOH data sharing.
• Behavioral health spoke: Implements FHIR Consent-based access control for Part 2 data. Interfaces with behavioral health EHR systems (Netsmart, Qualifacts). Enforces consent validation on every data access request and supports real-time consent revocation propagation.

Cross-Domain Data Governance

Multi-domain integration introduces governance challenges that do not exist in single-domain EHR exchange:

• Differential consent requirements: Behavioral health data requires explicit Part 2 consent. SDOH data may require patient consent for community organization sharing. Dental and device data typically fall under standard HIPAA TPO provisions. The integration platform must enforce the appropriate consent model for each data type.
• Data provenance and quality: Device data requires validation and calibration metadata. SDOH screening data requires provenance (which tool was used, when, by whom). Dental data requires mapping between dental-specific and medical terminologies. The integration platform must maintain comprehensive provenance records.
• Access control granularity: Not every consumer needs access to every domain. A population health analyst may need aggregated SDOH data but not individual behavioral health records. A dentist may need medical diagnoses and medications but not substance use treatment details. Role-based and attribute-based access control must be implemented at the domain level.

FHIR Resource Mapping Across Domains

Policy Changes Needed

Technical standards alone cannot close these interoperability gaps. Each domain requires policy changes that create the incentives, mandates, and governance structures necessary for implementation.

42 CFR Part 2 Modernization: Beyond the 2024 Rule

The 2024 final rule was a major step forward, but further modernization is needed. The February 2026 compliance date marks the beginning, not the end, of the alignment process. Needed next steps include:

• Federal preemption of state variations: The current patchwork of state behavioral health privacy laws creates compliance complexity that inhibits national interoperability solutions. Federal preemption for basic TPO consent would simplify implementation while allowing states to impose additional requirements for non-TPO uses.
• Standardized consent representation: A national standard for digitally representing Part 2 consent (building on the FHIR Consent resource) would enable automated consent enforcement across health IT systems.
• Integration with TEFCA: TEFCA's Common Agreement should explicitly address behavioral health data exchange, defining the consent and access control requirements for Part 2 data flowing through QHINs.

Medical Device Data Standards Mandate

Voluntary adoption of device interoperability standards has failed to achieve meaningful market penetration over 20+ years. Policy intervention is needed:

• FDA device interoperability requirements: The FDA should require new medical devices to support standardized data interfaces (IEEE 11073 or FHIR) as a condition of market clearance. The FDA's 2025 Request for Comments on FHIR for real-world data suggests the agency is moving in this direction.
• CMS Conditions of Participation: CMS could require hospitals to demonstrate medical device data integration capabilities as a Condition of Participation, creating demand-side pressure for device manufacturers to implement standards.
• UDI integration with EHRs: USCDI v6 added Unique Device Identifier as a core data element. Mandating UDI capture in EHRs for all implanted devices enables post-market surveillance and device recall management.

Dental FHIR Adoption Incentives

Without regulatory mandates comparable to ONC certification for medical EHRs, dental software vendors lack incentive to implement FHIR. Policy options include:

• Extension of ONC certification to dental software: Including dental EHR/EDR systems in ONC's Health IT Certification Program would create a baseline interoperability requirement for the dental market.
• CMS quality reporting incentives: Medicare and Medicaid dental quality measures that require dental-medical data exchange would create financial incentives for integration.
• FQHC integration requirements: Federally qualified health centers that receive federal funding for integrated medical-dental care should be required to demonstrate dental-medical record interoperability.

SDOH Data Exchange Infrastructure Funding

Community-based organizations, the essential counterparties in SDOH data exchange, typically lack the technical infrastructure and funding to implement FHIR-based interfaces. Policy support needed includes:

• Federal funding for CBO technology: Dedicated funding programs for community organizations to implement basic interoperability capabilities (FHIR APIs, referral platform integration).
• Medicaid SDOH data exchange requirements: Requiring Medicaid managed care organizations to implement closed-loop SDOH referral workflows using Gravity Project standards, as CMS Medicaid policy is already encouraging.
• TEFCA SDOH participation: Extending TEFCA's network to include social service organizations, not just healthcare entities, enabling SDOH data to flow through the same national infrastructure as clinical data.

Who Is Working on This: Key Organizations and Initiatives

Multiple organizations are actively developing standards, implementation guidance, and infrastructure for frontier domain interoperability. Understanding who is working on what helps organizations identify the right standards to adopt and the right communities to join.

Gravity Project (SDOH)

The Gravity Project is the definitive SDOH interoperability initiative. As an HL7 FHIR Accelerator, it develops the SDOH Clinical Care Implementation Guide, maintains SDOH-specific value sets for 17 social risk domains, and coordinates with CMS, ONC, and state Medicaid programs on SDOH data policy. The 2025-2026 Steering Committee co-chairs are Alex Lipton (Unite Us) and Lauren Riplinger (AHIMA).

Caliper Accelerator (Medical Devices)

HL7's Caliper FHIR Accelerator focuses exclusively on medical device interoperability. Building on the Devices on FHIR initiative and the HL7 Devices Working Group, Caliper brings together device manufacturers (Dexcom, GE HealthCare), health systems, and standards developers to create FHIR-based device integration specifications that work across the full acuity spectrum.

HL7 Dental Data Exchange Work Group

The HL7 work group responsible for the Dental Data Exchange Implementation Guide is advancing FHIR-based profiles for dental-medical data exchange. The v2.0.0-ballot (April 2025) represents the most comprehensive FHIR-based dental data exchange specification to date.

Da Vinci Project

The Da Vinci Project develops FHIR implementation guides for payer-provider data exchange, including Coverage Requirements Discovery (CRD), Prior Authorization Support (PAS), and Payer Data Exchange (PDEx). While not focused on the four frontier domains directly, Da Vinci's work on FHIR-based clinical data exchange infrastructure creates the platform on which domain-specific IGs can operate.

IHE (Integrating the Healthcare Enterprise)

IHE develops integration profiles that define how standards like FHIR, HL7v2, and DICOM should be used together in real-world workflows. IHE profiles for device data integration (Device Enterprise Communication — DEC) and cross-enterprise document sharing (XDS/XCA/MHD) provide implementation-level guidance that complements HL7's standards development.

ADA Standards Committee on Dental Informatics

The ADA's SCDI develops and maintains dental informatics standards including SNODENT, the dental subset of SNOMED CT, and participates in HL7's dental interoperability work. The ADA's ODIN (Oral Dataset Interoperability Network) initiative aims to define the core oral health dataset for cross-system exchange.

The Path Forward: Practical Steps for Health IT Leaders

For health IT leaders evaluating these frontier domains, the practical question is not whether to invest but where to start. Each domain is at a different maturity level, and the ROI profile differs by organization type.

If You Are a Health System

• Start with SDOH: The Gravity Project standards are the most mature of the four domains, CMS/Medicaid incentives are aligning, and referral platforms (Unite Us, findhelp) provide ready-made integration targets. Begin with standardized SDOH screening, Z-code documentation, and electronic referral workflows.
• Plan for 42 CFR Part 2 compliance: The February 2026 compliance date has arrived. If you have not updated your consent management processes and systems to support the single-consent TPO model, this is urgent operational work.
• Evaluate device integration for high-value use cases: Start with continuous glucose monitoring data integration (Dexcom and other CGM manufacturers are Caliper Accelerator members) or remote patient monitoring for chronic disease management. These use cases have clear ROI and growing standards support.
• Engage dental integration at FQHCs: If you operate federally qualified health centers with integrated dental services, dental-medical record integration should be a near-term priority given the clinical value and the growing availability of standards.

If You Are a Health IT Vendor

• Implement Gravity Project profiles: SDOH screening and referral capabilities are becoming expected EHR functionality. Implementing the SDOH-CC IG positions your product for CMS quality reporting requirements and Medicaid program mandates.
• Join the Caliper Accelerator: If you build medical device integration solutions, participation in the Caliper Accelerator gives you early access to emerging FHIR-based device integration specifications and influence over the standards development process.
• Build consent management for Part 2: FHIR Consent resource implementation, with the nuances of Part 2 consent management (revocation propagation, scope management, state law overlay), is a product differentiator in the behavioral health market.

If You Are a Policy Maker

• Extend ONC certification to dental: This single policy change would create more dental interoperability progress than a decade of voluntary adoption.
• Fund CBO technology infrastructure: SDOH closed-loop referral workflows cannot succeed if community organizations lack the technology to participate.
• Mandate device interoperability through FDA: Voluntary standards adoption for medical devices has been insufficient. Regulatory requirements tied to market clearance would accelerate adoption dramatically.

Hospital EHR interoperability was the necessary first chapter. These four frontier domains, dental, devices, SDOH, and behavioral health, are the chapters that will determine whether the US healthcare system achieves true whole-person care. The standards are emerging. The policy momentum is building. The question for every health IT leader is whether to be among the organizations that help write these chapters or those that wait to read them.

Frequently Asked Questions

Why are dental records not interoperable with medical EHRs?

Dental practices use separate practice management systems (Dentrix, EagleSoft, Open Dental) that were designed for scheduling, billing, and dental charting, not clinical data exchange. Unlike medical EHRs, dental software is not subject to ONC certification requirements, so there is no regulatory mandate to implement FHIR or other interoperability standards. The HL7 Dental Data Exchange Implementation Guide (v2.0.0-ballot, 2025) defines FHIR profiles for dental-medical exchange, but vendor adoption remains voluntary and limited. Only 42% of dental providers in co-located facilities can even enter data into the medical EHR.

What is the Gravity Project and how does it address SDOH data exchange?

The Gravity Project is an HL7 FHIR Accelerator that develops consensus-driven data standards for social determinants of health. Its SDOH Clinical Care Implementation Guide (currently STU 2.3) defines FHIR-based profiles for SDOH screening using standardized tools like AHC-HRSN and PRAPARE, diagnosis coding with ICD-10-CM Z-codes (Z55-Z65), electronic referrals to community-based organizations, and closed-loop feedback. The project has built value sets for 17 social risk domains and is now being adopted at the state level through CMS Medicaid guidance.

How did the 2024 final rule change 42 CFR Part 2 for behavioral health data sharing?

The February 2024 final rule (compliance date February 16, 2026) aligns 42 CFR Part 2 with HIPAA by allowing a single patient consent for treatment, payment, and healthcare operations (TPO). Previously, patients needed separate written consents for each recipient and each disclosure purpose, and redisclosure was prohibited. The new rule permits redisclosure under TPO, applies HIPAA individual rights provisions to Part 2 records, and clarifies that data segmentation is not required under federal law. However, at least 14 states maintain stricter requirements than the federal rule.

What is the Caliper FHIR Accelerator for medical device interoperability?

Caliper is HL7's newest FHIR Accelerator, launched in 2025, focused exclusively on medical device data interoperability. It builds on 20+ years of work by the HL7 Devices Working Group and the IEEE 11073 standards family. Founding members include Dexcom and GE HealthCare. The accelerator addresses the full spectrum from high-acuity ICU devices to consumer wearables, developing FHIR-based specifications for mapping proprietary device data to standard Device, DeviceMetric, and Observation resources. The goal is plug-and-play device integration that replaces today's custom middleware approach.

What new data elements in USCDI v4 through v7 address these frontier domains?

USCDI v4 (2024) added Alcohol Use, Substance Use, and Physical Activity to Health Status Assessments, and moved SDOH Assessment into this class. USCDI v5 added two new data classes. USCDI v6 (2025) added Unique Device Identifier (UDI), directly supporting device data integration. Draft USCDI v7 (January 2026) proposes 30 new data elements, the largest single expansion, including broadening Smoking Status to Tobacco Use. USCDI+ domain-specific extensions further address behavioral health, public health, and quality measurement data needs beyond the core standard.