01
Interoperability plane
Convert, validate, merge, and compare C-CDA, HL7 v2, FHIR R4, and DICOM with loss-checked boundaries.
Clinical interoperability, ready to try
Convert clinical data into usable FHIR.
FHIR66 converts and validates C-CDA, HL7 v2, FHIR R4, and DICOM so teams can connect systems without losing clinical context.
Auto-detects C-CDA XML, FHIR Bundle JSON/XML, Bulk Data NDJSON, or DICOM.
Multiple files run the C-CDA batch workflow; FHIR, NDJSON, and DICOM imports are one file at a time. Synchronous C-CDA responses include up to 500 resources; larger longitudinal documents are automatically sent to the durable worker path.
Without an API key, saved clinical data stays private to this browser and is auto-deleted after 1 day.
Drop a clinical file here
C-CDA XML, FHIR Bundle JSON/XML, Bulk Data NDJSON, or DICOM Part 10. Press Enter or Space to choose files. PNG/JPEG images are not clinical inputs.
Browse filesUploaded patients / files
All uploads in this browser tab stay here. Click a card to reopen it; open the Batch tab for full validation details.
Coverage at a glance
View profile matrix
Standards & protocols supported
C-CDA R2.1 / CCD
parse · emit
R2.1 CCD only: mapped sections, named synthetic vendor coverage, and an explicitly loss-checked local round-trip.
FHIR R4
build · validate · push
Base R4 Bundle JSON, FHIR Bundle XML, and fixture-backed Bulk Data NDJSON are accepted for the admitted Base R4 resource subset: Patient, Practitioner, Organization, Observation, Condition, DiagnosticReport, Encounter, MedicationStatement, MedicationRequest, AllergyIntolerance, Immunization, Procedure, PractitionerRole, CareTeam, Device, DeviceUseStatement, CarePlan, Goal, FamilyMemberHistory, Appointment, DocumentReference, ServiceRequest, ImagingStudy, Coverage, Consent, and Provenance. Unsupported profiles are rejected.
DICOM Part 10
review · FHIR
Strict single-instance metadata parsing to ImagingStudy, with an ephemeral first-frame preview when pixels are decodable.
HL7 v2.x
22 triggers · ACK
ADT (A01/A02/A03/A04/A08/A11/A13/A28/A31/A40) · ORU^R01 · VXU^V04 · SIU (S12/S13/S14/S15/S17/S26) · MDM^T02 · ORM^O01 · OMP^O09 · OMG^O19.
MLLP transport
TCP listener
v2 over MLLP on configurable port (default 2575). Auto-ACK; webhook on receipt.
SMART on FHIR
App Launch
Outbound authorization-code client for connecting to an external FHIR server; launch & exchange helpers are not hosted SMART endpoints.
FHIR Bulk Data
$export
Outbound async kickoff + polling against an external FHIR Bulk Data server; this app does not host a local $export endpoint.
FHIR R4 Subscriptions
rest-hook
Register criteria (e.g. Observation?code=…); HMAC-signed callbacks fire on every match.
CDS Hooks
2 services
patient-view summary cards + medication-prescribe allergy/duplicate-therapy check.
IHE PDQm · Patient $match
MPI
Weighted name + DOB + identifier scoring with FHIR match-grade extension.
Terminology
5 systems
LOINC · SNOMED CT · RxNorm · CVX · ICD-10-CM. Pluggable external TX server.
Webhooks
HMAC · retries
SHA-256 signed deliveries with exponential back-off (5 attempts).
Ops & metering
Prometheus
JSON logs, Sentry hook, Stripe meter events, and anonymous uptime at /metrics; authenticated operators can inspect p50/p95/p99 latency there.
Intentionally out of scope: HL7 v3 messaging (PRPA/PIX/PDQ — almost no production usage; replaced by FHIR), FHIR → DICOM reverse emission, DICOM network services/PACS, IHE XDS.b SOAP, X12 270/271/837 payer EDI.
How FHIR66 fits
One clinical data plane, four clear jobs.
Deterministic conversion and connectivity with AI assistance layered on top, keeping clinical truth visible from input to review.
02
FHIR connectivity
Connect through hosted R4 discovery, Subscriptions, CDS Hooks, Patient $match, SMART helpers, Bulk Data clients, and FHIR push.
03
Agentic intelligence
Run durable inspect → parse → validate → terminology-review workflows with grounded explanations and human approval gates.
04
Production control plane
Protect operations with tenant-scoped encryption, operators, API keys, audit trails, bounded queues, signed webhooks, metrics, and metering.
Converting…
AI approval queue
Loading…Review this tenant’s controlled agent runs and evidence-backed suggestions before they are accepted. This is persistent tenant history; current uploaded patients appear in the upload list above. Deterministic conversion remains authoritative.
Submit a new controlled review
Upload one C-CDA, HL7 v2 message, or FHIR R4 Bundle to create a review run. The source is sent securely to your tenant and is never shown in queue status or submission errors.
Choose one source file to begin.
Loading agent runs…
Operator access
Sign in to manage API keys and open the interactive API documentation.
Operator sign-in required
Sign in with your Clerk operator account. The legacy deployment token is never requested here.
Owner setup guide
Admin sign-in uses a verified Clerk session (email and password, managed by Clerk — this app never sees passwords). Setup:
- Replit manages
CLERK_SECRET_KEYandVITE_CLERK_PUBLISHABLE_KEYautomatically — do not edit them. - Copy your Clerk user ID from the Auth pane into
CLERK_ADMIN_USER_IDSin Replit Secrets and restart. - In production, set
CLERK_AUTHORIZED_PARTIESto the exact public app origin (e.g.https://www.fhir66.com), then republish. - Reload this page to manage keys and open the Swagger API docs.
For emergency or CLI recovery only, ADMIN_TOKEN enables direct non-browser calls. Never paste it into this page or send it as a browser credential.
Mint new key
Choose one or more scopes
Save this now — it will not be shown again: