USCDI v3 + TEFCA Compliance with Mirth Connect: January 2026 Deadline Engineering Checklist

The January 2026 enforcement deadline for USCDI v3 is no longer a future planning item. It is a hard regulatory line. Provider organizations, health information networks, and certified Health IT developers that fail to meet the bar face civil monetary penalties of up to $1 million per violation under the 21st Century Cures Act's information blocking provisions. With ONC HTI-1 already finalized, CMS Patient Access API enforcement active, and TEFCA QHINs going live, the compliance window has effectively closed for organizations that have not yet started.

This is an engineering checklist, not a policy summary. If you run Mirth Connect as your integration engine and you need to ship USCDI v3 + TEFCA-aligned data exchange before the enforcement clock runs out, this guide gives you the regulatory anchor, the resource-level mapping from HL7v2 to US Core 6.1.0, working transformer code, the audit trail spec auditors will ask for, and a 60-day countdown plan that has been used to bring real provider organizations across the line.

Why January 2026 Is Different From Every Prior Deadline

Healthcare interoperability has had deadlines before. Meaningful Use Stage 2. ONC 2015 Edition. The original USCDI v1 transition. Most slid. Some quietly expired. The reason January 2026 is structurally different is that three independent enforcement mechanisms now converge on the same date.

1. The 21st Century Cures Act Information Blocking Final Rule

The 21st Century Cures Act, signed in 2016, gave HHS the authority to define and penalize "information blocking" — any practice by a healthcare actor that is likely to interfere with the access, exchange, or use of electronic health information (EHI). The penalty structure was finalized in 2023 and went live in 2024 for HINs/HIEs and Health IT developers. For provider organizations, "appropriate disincentives" under CMS programs became enforceable in 2025, with full information-blocking enforcement effective January 2026.

2. ONC HTI-1 — The USCDI v3 Mandate

ONC's Health Data, Technology, and Interoperability rule (HTI-1) finalized in January 2024 made USCDI v3 the mandatory data baseline for certified Health IT by January 1, 2026. This is the version that adds Sexual Orientation, Gender Identity, Sex Parameter for Clinical Use (SPCU), Race and Ethnicity categories expanded, Encounter Information, Patient Demographics expansion, and several other data classes beyond USCDI v1/v2. Every certified product must support read and exchange of all USCDI v3 data classes through standard FHIR R4 / US Core 6.1.0 interfaces.

3. CMS Interoperability and Prior Authorization Rule

CMS-0057-F requires Medicare Advantage, Medicaid, CHIP, and QHP issuers on the Federal Exchanges to implement Patient Access, Provider Access, and Payer-to-Payer FHIR APIs aligned to US Core. The Patient Access API enforcement is live; Provider Access and Payer-to-Payer APIs go live in 2027 but require USCDI v3 conformance from day one of build.

4. TEFCA Goes From "Voluntary Framework" to "Operational Backbone"

The Trusted Exchange Framework and Common Agreement (TEFCA) flipped from designation to operational in late 2023. The first QHINs are now live, including eHealth Exchange, Epic Nexus, Health Gorilla, MedAllies, CommonWell, Kno2, and KONZA. By January 2026, treatment, individual access services, public health, and government benefits determination exchange purposes are all expected to be fully operational across QHINs — and ONC has signaled that TEFCA participation will become a de facto requirement for showing "non-blocking" conduct.

The convergence is the point. You can no longer satisfy one rule and hope the others slide. The same engineering output — a USCDI v3-conformant FHIR Bundle with audit trail evidence and TEFCA-compatible exchange capability — has to satisfy all four simultaneously.

The Penalty Math: Why "We'll Deal With It Later" Is Not an Option

The information blocking penalty structure under 45 CFR Part 171 is severe and category-specific.

• Health IT Developers of certified Health IT: Up to $1 million per violation, imposed by HHS OIG
• Health Information Networks and Health Information Exchanges: Up to $1 million per violation
• Healthcare Providers: Subject to "appropriate disincentives" under CMS programs — including loss of Promoting Interoperability eligibility, removal from CMS public reporting as a "promoting interoperability" eligible clinician, and Medicare reimbursement adjustment

"Per violation" is the dangerous phrase. A single non-compliant interface that fails to deliver a patient record on request can be counted per encounter, per request, or per data class withheld. A provider organization with even modest volume can rack up violations into seven figures within a single audit cycle. We have seen organizations underestimate this and treat it as a single-event risk — that is the wrong mental model. Treat each unfulfilled FHIR API request, each HL7v2 message dropped without forwarding, each consent denial that does not meet the documented exceptions as a countable violation.

And the reputational mechanics matter. ONC and HHS OIG publish enforcement actions. Being named in an information blocking finding affects RFP eligibility, payer contracts, and merger/acquisition due diligence for years afterward.

USCDI v3 Data Classes — What Has to Move

USCDI v3 expands USCDI v2 with new data classes and refines existing ones. The full mandatory scope your Mirth Connect integration must support by January 2026 covers the following 15 categories. Each maps to specific FHIR R4 resources under the US Core 6.1.0 Implementation Guide, which is the conformance target.

The 15 USCDI v3 Data Classes and Their FHIR Resource Anchors

This is the engineering scope. If your current FHIR API supports five of these and partially supports four more, you are not USCDI v3 compliant — partial conformance is not conformance under HTI-1.

Reference Architecture: Mirth Connect as the USCDI v3 Compliance Layer

The architectural pattern that works in production places Mirth Connect as the deterministic transformation layer between legacy HL7v2 sources and the US Core 6.1.0 FHIR endpoint that satisfies both ONC certification and TEFCA exchange. Mirth is not the FHIR server itself — it is the transformer, the audit point, and the routing brain.

The architecture decomposes into four layers:

• Inbound HL7v2 sources: ADT for demographics and encounters, ORM for orders, ORU for results, MDM for documents, VXU for immunizations, RDE for medication orders. These flow from your EHR, LIS, RIS, pharmacy, and ancillary systems via MLLP.
• Mirth channels, one per resource family: Each channel has a single responsibility — receive a message type, normalize codes (SNOMED CT, LOINC, RxNorm, CVX), build the corresponding FHIR resource(s), and forward to the FHIR repository or HL7 FHIR bundle endpoint. Splitting channels by resource family (not by source system) keeps your audit story clean.
• US Core 6.1.0 FHIR repository: The conformant FHIR server (HAPI, Aidbox, Smile CDR, or your custom implementation) that holds resources and serves the Patient Access, Provider Access, and Bulk Data APIs.
• Audit + TEFCA layer: Every transformation writes a structured audit record. The TEFCA QHIN connector subscribes to FHIR Subscription events or pulls from the repository to participate in trusted exchange.

The reason this works is separation of concerns. Mirth handles the messy HL7v2 reality. The FHIR server handles standards-conformant query and storage. The audit layer handles compliance evidence. Each layer can be tested and certified independently.

Sample HL7v2 to US Core 6.1.0 Transformer (JavaScript)

This is a working Mirth Connect transformer that takes an inbound ADT^A04 patient registration HL7v2 message and produces a US Core 6.1.0-conformant Patient resource. It includes the meta.profile assertion, required extensions for race, ethnicity, and birth sex, identifier slicing for MRN, and US Core mandatory cardinality.

// Mirth Connect Source Transformer
// Channel: USCDI-Patient-Sync
// Input: HL7v2 ADT^A04 (or A28, A31)
// Output: US Core 6.1.0 Patient resource (JSON)

var pid = msg['PID'];
var pd1 = msg['PD1'];
var evn = msg['EVN'];

// Build US Core Patient
var patient = {
  resourceType: 'Patient',
  meta: {
    profile: ['http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient'],
    versionId: '1',
    lastUpdated: new Date().toISOString()
  },
  // US Core requires at least one identifier with system + value
  identifier: [{
    use: 'usual',
    type: {
      coding: [{
        system: 'http://terminology.hl7.org/CodeSystem/v2-0203',
        code: 'MR',
        display: 'Medical Record Number'
      }]
    },
    system: 'urn:oid:' + globalMap.get('FACILITY_MRN_OID'),
    value: pid['PID.3']['PID.3.1'].toString()
  }],
  active: true,
  // US Core requires name with family OR given populated
  name: [{
    use: 'official',
    family: pid['PID.5']['PID.5.1'].toString(),
    given: [
      pid['PID.5']['PID.5.2'].toString(),
      pid['PID.5']['PID.5.3'].toString()
    ].filter(function(n) { return n && n.length > 0; })
  }],
  // US Core requires gender
  gender: mapGender(pid['PID.8'].toString()),
  birthDate: formatBirthDate(pid['PID.7']['PID.7.1'].toString()),
  // US Core 6.1.0 mandatory extensions
  extension: []
};

// Add Race extension (us-core-race)
var raceCode = pid['PID.10']['PID.10.1'].toString();
if (raceCode) {
  patient.extension.push({
    url: 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-race',
    extension: [{
      url: 'ombCategory',
      valueCoding: mapRaceToOMB(raceCode)
    }, {
      url: 'text',
      valueString: pid['PID.10']['PID.10.2'].toString() || raceCode
    }]
  });
}

// Add Ethnicity extension (us-core-ethnicity)
var ethCode = pid['PID.22']['PID.22.1'].toString();
if (ethCode) {
  patient.extension.push({
    url: 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-ethnicity',
    extension: [{
      url: 'ombCategory',
      valueCoding: mapEthnicityToOMB(ethCode)
    }, {
      url: 'text',
      valueString: pid['PID.22']['PID.22.2'].toString() || ethCode
    }]
  });
}

// Add Birth Sex extension (us-core-birthsex)
patient.extension.push({
  url: 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex',
  valueCode: pid['PID.8'].toString()
});

// Address (US Core requires line, city, state OR district)
if (pid['PID.11']['PID.11.1'].toString()) {
  patient.address = [{
    use: 'home',
    line: [pid['PID.11']['PID.11.1'].toString()],
    city: pid['PID.11']['PID.11.3'].toString(),
    state: pid['PID.11']['PID.11.4'].toString(),
    postalCode: pid['PID.11']['PID.11.5'].toString(),
    country: pid['PID.11']['PID.11.6'].toString() || 'US'
  }];
}

// Telecom
var phone = pid['PID.13']['PID.13.1'].toString();
if (phone) {
  patient.telecom = [{ system: 'phone', value: phone, use: 'home' }];
}

// Write audit trail BEFORE forwarding
writeAuditEvent({
  eventType: 'C',  // Create
  resourceType: 'Patient',
  resourceId: patient.identifier[0].value,
  sourceMessage: msg['MSH']['MSH.10'].toString(),
  user: evn['EVN.5']['EVN.5.1'].toString(),
  facility: msg['MSH']['MSH.4']['MSH.4.1'].toString(),
  timestamp: new Date().toISOString(),
  channelId: channelMap.get('CHANNEL_ID')
});

// Forward to FHIR server
channelMap.put('FHIR_PAYLOAD', JSON.stringify(patient));

return patient;

The pattern repeats for every resource. The non-negotiable elements in every transformer are: meta.profile assertion (claims US Core 6.1.0 conformance to the validator), all required cardinality populated (the validator will reject otherwise), terminology bindings to SNOMED/LOINC/RxNorm/CVX (USCDI v3 is explicit about value sets), and audit event written before forward (the compliance evidence requirement).

The Audit Trail Spec Auditors Will Ask For

Every audit we have walked clients through asks the same five questions, in the same order. Design your audit trail to answer all five from a single record, and you will spend the audit talking about strategy rather than digging through logs.

The 5 Audit Questions

1. What data moved? Resource type, resource ID, FHIR version, USCDI v3 data class.
2. Who initiated it? Authenticated user identity, OAuth/SMART app context, system user for automated flows.
3. When did it happen? Timestamp at every hop — source receipt, transformation start, transformation end, FHIR write confirm, downstream notification.
4. Where did it go? Destination FHIR server URL, QHIN identifier if TEFCA, downstream subscriber endpoints.
5. Why was it allowed? Consent record reference, purpose-of-use code (TREATMENT, PAYMENT, OPERATIONS, INDIVIDUAL_ACCESS), policy version evaluated.

Recommended Audit Record Schema

{
  "auditEventId": "aud-2026-05-28-7afe3219",
  "timestamp": "2026-05-28T14:22:18.421Z",
  "eventType": "RESOURCE_TRANSFORMED",
  "outcome": "SUCCESS",
  "resourceType": "Patient",
  "resourceId": "MRN-882341",
  "fhirVersion": "4.0.1",
  "profileAsserted": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient",
  "usCdiV3DataClass": "PatientDemographics",
  "sourceSystem": {
    "name": "EpicProd",
    "messageType": "ADT^A04",
    "messageControlId": "1234567",
    "sendingFacility": "REGIONAL_HOSPITAL"
  },
  "actor": {
    "userId": "system:adt-ingest",
    "appContext": "mirth-channel:patient-sync",
    "patientContext": "MRN-882341"
  },
  "destination": {
    "fhirServer": "https://fhir.example.org/r4",
    "qhinIdentifier": null,
    "tefcaPurposeOfUse": null
  },
  "policy": {
    "consentReferenced": null,
    "purposeOfUse": "TREATMENT",
    "policyVersion": "v3.2-2026-01"
  },
  "mirthChannelId": "patient-sync-channel",
  "transformDurationMs": 47,
  "validationResult": "PASS",
  "hashOfPayload": "sha256:5c8a3b..."
}

Persist this to an append-only store. We use a separate PostgreSQL audit schema with row-level immutability triggers, fronted by a write-only API key in Mirth's global map. Some organizations stream to an S3 / object store with object lock for tamper evidence. The principle is the same: auditors must be able to verify the record was not modified after creation.

A common mistake is logging only successful transformations. The penalty risk lives in failures. Failed validations, denied access requests, and dropped messages are exactly what an information blocking complaint will allege. Log them with the same fidelity as successes, including the specific reason and the consent or policy decision that produced the outcome.

TEFCA QHIN Participation: What "Connecting to the Common Agreement" Actually Means

Many engineering teams hear "TEFCA participation" and assume it means joining the RCE directly. That is not how it works. The Sequoia Project, as the Recognized Coordinating Entity (RCE), designates QHINs. Organizations participate through QHINs as Participants or Sub-participants, not directly with the RCE.

Choosing Your QHIN

Your QHIN choice depends on your existing relationships and exchange purposes. eHealth Exchange has the largest historical base from the NwHIN/Carequality era. Epic Nexus is the natural choice if your Epic footprint is significant. Health Gorilla, MedAllies, and Kno2 have strong specialty/payer focus. CommonWell and KONZA offer broad geographic and use case coverage. You can be a Sub-participant of more than one QHIN, but the operational and contractual overhead is real.

Technical Requirements From a QHIN

• FHIR R4 endpoint conformant to US Core 6.1.0 and the TEFCA FHIR Roadmap (the IHE-derived QHIN Technical Framework for query/response patterns)
• Compliance with the QHIN-to-Participant exchange specifications including IUA (Internet User Authorization) for user/system identity
• Audit logging conformant to the TEFCA QHIN Technical Framework
• Patient Discovery, Document Query, Document Retrieve workflow support
• Public Health Reporting and Government Benefits Determination support for those exchange purposes (becoming mandatory through 2026-2027)

Mirth Connect channels typically sit behind the QHIN connector, transforming inbound TEFCA requests into your local FHIR server queries and outbound responses back into TEFCA-compliant bundles. The QHIN handles the trust framework, certificates, and routing; your job is producing valid, complete, profile-conformant FHIR.

The Decision Tree: Are You Actually USCDI v3 Compliant?

This is the diagnostic flow we walk every client through in the first scoping call. It is not a marketing tool — it is the same decision tree we use internally to set the project plan.

Be honest at each branch. The economics of fixing a gap discovered in May 2026 versus discovered during an OIG audit are not comparable. Self-disclosed gaps that are being remediated are categorically different from gaps surfaced by an enforcement action.

The 60-Day Countdown Checklist

This is the eight-week plan we run when an organization comes to us with an enforcement clock already ticking. Each week has specific deliverables, owners, and an exit criterion.

Week 1 — Interface Inventory and Risk Surface Mapping

• List every inbound and outbound interface — MLLP, REST, SFTP, direct DB
• Catalog HL7v2 message types in actual use (don't trust the spec — read the logs)
• Identify which interfaces touch which USCDI v3 data class
• Document current FHIR API surface: which resources, which profiles, which operations
• Exit criterion: Single spreadsheet listing all interfaces, message types, and USCDI v3 coverage status (Green/Yellow/Red per data class)

Week 2 — Gap Analysis Against US Core 6.1.0

• For each USCDI v3 data class, validate current production output against the US Core 6.1.0 validator
• Run the Inferno US Core test suite against your existing FHIR endpoints
• List every failed validation rule with profile reference
• Identify terminology binding gaps (SNOMED, LOINC, RxNorm, CVX)
• Exit criterion: Gap report with effort estimate per gap (S/M/L) and ownership

Week 3 — Build the Highest-Risk Profiles First

• Build Patient, Encounter, and Condition transformers (these gate every other workflow)
• Implement required US Core extensions (race, ethnicity, birth sex, SPCU)
• Wire up terminology lookups for common code system mappings
• Validate every output against the Inferno tool before integrating
• Exit criterion: Patient, Encounter, Condition pass Inferno US Core tests

Week 4 — Medications, Allergies, Observations

• Build MedicationRequest from RDE^O11 with RxNorm mapping
• Build AllergyIntolerance from AL1 with SNOMED CT substance codes
• Build Observation (vitals + labs) with LOINC mapping
• Build DiagnosticReport with PresentedForm where applicable
• Exit criterion: Medication, Allergy, Observation, DiagnosticReport pass Inferno

Week 5 — Remaining Resources and Audit Trail

• Build Immunization, Procedure, ServiceRequest, DocumentReference, CarePlan, Goal
• Implement the full audit record schema with append-only storage
• Add audit hooks to every transformer (write-before-forward pattern)
• Implement the Provenance resource for resource provenance tracking
• Exit criterion: All 15 USCDI v3 data classes pass Inferno; audit trail captures every transformation

Week 6 — TEFCA QHIN Connection

• Sign Participant or Sub-participant agreement with chosen QHIN
• Stand up QHIN test endpoint with test certificates
• Execute QHIN onboarding test plan (Patient Discovery, Document Query, Document Retrieve)
• Validate TEFCA-compliant audit logging
• Exit criterion: QHIN sandbox/test environment passes onboarding test plan

Week 7 — End-to-End Compliance Testing

• Run scenario-based tests: patient access request, provider-to-provider exchange, TEFCA-mediated query
• Stress test the audit pipeline — can you produce an audit report for any data class in under 5 minutes?
• Run the ONC HTI-1 certification test scripts if applicable
• Document every test, expected result, actual result, and remediation if needed
• Exit criterion: All scenario tests pass; audit reports generate within SLA

Week 8 — Pre-Audit Readiness and Cutover

• Run the full self-assessment checklist (the same one an auditor would use)
• Document all policy decisions: consent model, purpose-of-use defaults, exception handling per 45 CFR Part 171
• Train help desk and clinical informatics on patient access request handling
• Cutover production with monitoring and rollback plan
• Exit criterion: Production is live, monitored, and you have an audit-ready evidence package

This plan compresses what most organizations should have started 12 months earlier. It works — we have run it — but it requires dedicated capacity. If your team is part-time on this, double the timeline and start tomorrow.

Pre-Audit Readiness Assessment — The 25-Point Self-Check

Before you say "we are USCDI v3 compliant," walk this checklist. If you cannot answer Yes to every item with evidence, you have remaining work.

USCDI v3 Data Coverage

1. All 15 USCDI v3 data classes can be exchanged via FHIR API conformant to US Core 6.1.0
2. Patient, Encounter, Condition, MedicationRequest, AllergyIntolerance, Observation, DiagnosticReport, Immunization, Procedure, ServiceRequest, DocumentReference, CarePlan, Goal, CareTeam, Provenance pass the Inferno US Core 6.1.0 test suite
3. All required US Core extensions are populated (race, ethnicity, birth sex, sex parameter for clinical use)
4. Terminology bindings to SNOMED CT, LOINC, RxNorm, and CVX are operational and version-controlled
5. Provenance resources are created for every USCDI v3 data class

API and Access

6. SMART on FHIR launch (standalone and EHR launch) is operational
7. Patient Access API is live and meets CMS-0057-F requirements
8. Bulk Data Access API (FHIR Bulk Data IG) is operational for population-level requests
9. Provider Access API path is defined (live in 2027 but USCDI v3 conformance required from build start)
10. FHIR Subscription R4 backport or R5 is supported for event-driven exchange

Audit and Evidence

11. Every transformation writes an audit record before forward
12. Audit records are in an append-only or tamper-evident store
13. Audit records contain all 5 required dimensions (what/who/when/where/why)
14. Failed validations, denied requests, and dropped messages are logged with reason
15. You can produce an audit report for any USCDI v3 data class in under 5 minutes

Information Blocking Policy

16. Information blocking exceptions per 45 CFR Part 171 are documented (Preventing Harm, Privacy, Security, Infeasibility, Health IT Performance, Content and Manner, Fees, Licensing)
17. Every denial of access is logged with the specific exception invoked and the policy version
18. Help desk and clinical informatics have written runbooks for patient access requests
19. Consent management is integrated with FHIR Consent resource where applicable
20. Purpose-of-use codes are evaluated at every access point

TEFCA Readiness

21. QHIN Participant or Sub-participant agreement is signed
22. QHIN test environment passes onboarding test plan
23. Patient Discovery, Document Query, Document Retrieve workflows are operational
24. TEFCA-required exchange purposes (Treatment, Individual Access Services, Public Health, Government Benefits) are supported per your obligations
25. QHIN production cutover plan is signed off

Each "No" is a remediation item. Track them with named owners, weekly status, and a hard date for closure.

Common Failure Modes We See in the Field

Across the engagements we have run for USCDI v3, the failures cluster into a few patterns. Knowing them upfront saves weeks.

Failure 1: Treating USCDI v3 as a Spec, Not a Profile

USCDI v3 specifies WHAT data classes must be supported. US Core 6.1.0 specifies HOW each resource must be structured. Many teams build to USCDI v3 and assume any valid FHIR resource will pass. It will not. US Core 6.1.0 has profile slicing, required extensions, terminology binding strength of "required", and cardinality constraints beyond base FHIR. Always validate against the US Core 6.1.0 IG, not just FHIR R4.

Failure 2: Skipping Provenance

Provenance is the resource every team forgets and every auditor checks. It is how a downstream consumer knows which system originated the data, who authored it, and when it was recorded versus when the event happened. Build the Provenance creation hook into every transformer from day one.

Failure 3: Conflating Logging With Audit Trail

Application logs are not audit trails. Audit trails are tamper-evident, retained per policy (often 6+ years), and queryable by data class and time range under audit pressure. If you are pointing auditors at /var/log/mirth/mirth.log, you have a problem.

Failure 4: Forgetting the Reverse Direction

Most teams build USCDI v3 outbound. Information blocking is about inbound too — can you receive and process a FHIR resource from another provider, or do you reject it because your system "only speaks HL7v2"? The patient access and provider access flows are bidirectional. Mirth Connect is excellent at the reverse FHIR-to-HL7v2 transformation that legacy downstream systems still require.

Failure 5: Underestimating Terminology Operations

SNOMED CT licensing, LOINC top 2000 lab orderables, RxNorm normalization, and CVX immunization codes are not static lookups. They version. They require an active terminology server (FHIR ValueSet/CodeSystem expansion) or at minimum a tightly version-controlled local cache. Build the terminology service into your reference architecture; don't bolt it on later.

Building This With Nirmitee

If you are reading this in May 2026 with the January 2026 USCDI v3 enforcement clock already past zero and your gap analysis showing red across multiple data classes, the conversation we have is different from the one in March 2025. We have helped provider organizations, payer-facing platforms, and certified Health IT developers ship USCDI v3 + TEFCA-aligned FHIR exchange against compressed timelines, with Mirth Connect as the deterministic transformation backbone.

Our typical engagement starts with a one-week scoping that produces the interface inventory, the gap report, and a defended remediation plan. The build phases follow the 60-day countdown above — adapted to your starting position, your existing FHIR server, and your QHIN of choice.

Explore our healthcare interoperability solutions for the full picture of how we build USCDI v3 + TEFCA-conformant exchange architectures. For deeper engineering on the underlying integration platform, our healthcare product engineering team has been hardening Mirth Connect deployments for production-scale compliance for over a decade. Talk to our team to schedule a USCDI v3 compliance discovery call.

Related Reading

• Build a Robust HL7 Interface Engine Using Mirth Connect
• Mirth Connect Performance Tuning at 10,000 Messages/Hour
• How to Set Up Mirth Connect for High Availability
• Mirth Connect Security Hardening for HIPAA Compliance
• What Reliable Mirth Connect Monitoring Looks Like in Production

Download: USCDI v3 Readiness Audit Checklist (PDF)

We have packaged the 25-point self-assessment, the data class mapping matrix, the audit record schema, and the 60-day countdown plan into a single PDF you can take into a steering committee meeting. Request the USCDI v3 Readiness Audit Checklist and we will also offer to book a 30-minute compliance discovery call to walk through your specific position against the January 2026 baseline.