Developer / user guide
The new formats, with examples
Last updated: — · companion to Why now. Open any example; every format links to its spec.
What this is
The 2026-27 mandates are, underneath, a set of data formats. This page is the developer's map: each new format, what it carries, a minimal example you can open, and a link to the official spec. REV is built native to all of them. The full list of government rules sits at the bottom.
Clinical data & APIs
The record itself, and how apps read it. Required by USCDI v3 / HTI-1.
FHIR R4 + US Core 6.1.0 HTI-1
The base wire format for clinical data. Every resource (Patient, Condition, Observation, MedicationRequest) is JSON tagged with a US Core profile that pins required fields and code systems.
Show example — US Core Patient (JSON)
{
"resourceType": "Patient",
"id": "rev-12345",
"meta": { "profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
]},
"identifier": [
{ "system": "http://hospital.example.org/mrn", "value": "MRN-00482" }
],
"name": [ { "family": "Nguyen", "given": ["Linh"] } ],
"gender": "female",
"birthDate": "1987-03-14"
}USCDI v3 Jan 2026
The required data set (not a wire format): the classes and elements a certified EHR must capture. v3 adds SDOH, sexual orientation / gender identity, and more. Carried on the wire as US Core FHIR.
Show example — a USCDI element as FHIR (smoking status)
{
"resourceType": "Observation",
"status": "final",
"category": [ { "coding": [ {
"system": "http://terminology.hl7.org/CodeSystem/observation-category",
"code": "social-history" } ] } ],
"code": { "coding": [ {
"system": "http://loinc.org", "code": "72166-2",
"display": "Tobacco smoking status" } ] },
"subject": { "reference": "Patient/rev-12345" },
"valueCodeableConcept": { "coding": [ {
"system": "http://snomed.info/sct", "code": "266919005",
"display": "Never smoked tobacco" } ] }
}C-CDA R2.1 HTI-1
The XML document format for summaries (the CCD), used for document-based exchange and TEFCA's IHE path. FHIR is the API; C-CDA is the document.
Show example — CCD header (XML)
<ClinicalDocument xmlns="urn:hl7-org:v3">
<templateId root="2.16.840.1.113883.10.20.22.1.1"
extension="2015-08-01"/>
<code code="34133-9" codeSystem="2.16.840.1.113883.6.1"
displayName="Summarization of Episode Note"/>
<recordTarget><patientRole>
<id root="2.16.840.1.113883.19.5" extension="MRN-00482"/>
<patient><name><given>Linh</given>
<family>Nguyen</family></name></patient>
</patientRole></recordTarget>
<!-- Problems, Medications, Allergies, Results sections -->
</ClinicalDocument>SMART App Launch v2 §170.315(g)(10)
OAuth2 / OpenID Connect so patients and third-party apps connect securely. v2 adds granular scopes (read vs search per resource) and PKCE.
Show example — scopes + authorization request
# SMART v2 granular scopes
launch/patient patient/Patient.rs patient/Observation.rs
openid fhirUser offline_access
# Authorization request (PKCE)
GET /authorize?response_type=code&client_id=rev-app
&redirect_uri=https://app.rev.health/cb
&scope=launch/patient patient/*.rs openid fhirUser
&aud=https://fhir.rev.health/r4
&code_challenge=...&code_challenge_method=S256Bulk Data (Flat FHIR) §170.315(g)(10)
Population-level export via $export. The server returns newline-delimited JSON (ndjson), one resource per line, for analytics and payer Provider-Access feeds.
Show example — $export request + ndjson output
# Kick off a group export (async)
GET /Group/practice-77/$export?_type=Patient,Observation,Condition
Accept: application/fhir+json
Prefer: respond-async
# -> 202 Accepted, Content-Location: /bulk-status/abc
# Output: ndjson, one FHIR resource per line
{"resourceType":"Patient","id":"rev-12345", ... }
{"resourceType":"Patient","id":"rev-12346", ... }Prior authorization & prescribing
Where denials are prevented and scripts are sent. Required by HTI-4 and CMS-0057-F.
Da Vinci CRD (CDS Hooks) CMS-0057-F
At order entry, REV fires a CDS Hook to the payer to ask "is this covered, and does it need prior auth?" The payer returns a card. Coverage rules surface in the room.
Show example — order-sign hook request (JSON)
{
"hook": "order-sign",
"fhirServer": "https://fhir.rev.health/r4",
"context": {
"userId": "Practitioner/dr-okafor",
"patientId": "rev-12345",
"draftOrders": { "resourceType": "Bundle", "entry": [
{ "resource": { "resourceType": "ServiceRequest",
"status": "draft",
"code": { "coding": [ {
"system": "http://www.ama-assn.org/go/cpt",
"code": "72148",
"display": "MRI lumbar spine w/o contrast" } ] } } }
] }
}
}Da Vinci DTR HTI-4
If the payer needs documentation, it sends a FHIR Questionnaire. DTR runs CQL against the chart to auto-answer what it can, so the provider only fills the gaps.
Show example — DTR Questionnaire (JSON)
{
"resourceType": "Questionnaire",
"status": "active",
"item": [
{ "linkId": "1", "type": "boolean",
"text": "Conservative therapy tried >= 6 weeks?" },
{ "linkId": "2", "type": "date",
"text": "Most recent lumbar imaging date" }
]
}Da Vinci PAS CMS-0057-F
Submit the prior-auth request as a FHIR Claim (use = preauthorization) and track status. PAS bridges FHIR to the legacy X12 278 the payer runs internally.
Show example — PAS preauth Claim (JSON)
{
"resourceType": "Claim",
"use": "preauthorization",
"status": "active",
"patient": { "reference": "Patient/rev-12345" },
"provider": { "reference": "Organization/rev-practice-77" },
"item": [ { "sequence": 1, "productOrService": {
"coding": [ { "system": "http://www.ama-assn.org/go/cpt",
"code": "72148",
"display": "MRI lumbar spine w/o contrast" } ] } } ]
}NCPDP SCRIPT (eRx + EPCS) HTI-4
The pharmacy messaging standard. A NewRx sends a prescription; EPCS adds the controlled-substance signing flow.
Show example — NewRx (XML)
<Message version="2017071">
<Body><NewRx>
<MedicationPrescribed>
<DrugDescription>Amoxicillin 500 MG Oral Capsule</DrugDescription>
<DrugCoded><ProductCode qualifier="ND">00093310905</ProductCode>
</DrugCoded>
<Quantity><Value>21</Value></Quantity>
<Directions>1 capsule by mouth three times daily for 7 days</Directions>
</MedicationPrescribed>
</NewRx></Body>
</Message>NCPDP RTPB v13 HTI-4
Real-Time Prescription Benefit: at the point of prescribing, show the patient's actual cost, formulary status, and whether prior auth is required, plus cheaper alternatives.
Show example — RTPB response (sketch)
{
"drug": "Amoxicillin 500 MG Oral Capsule",
"coverageStatus": "covered",
"patientPayAmount": 4.00,
"priorAuthorizationRequired": false,
"alternatives": [
{ "drug": "Amoxicillin 500 MG (generic, 90ct)",
"patientPayAmount": 0.00 }
]
}X12 278 legacy
The HIPAA EDI transaction for prior auth that payers run today. REV speaks FHIR PAS; the FHIR-to-278 bridge keeps existing payers working, and ASTP enforcement discretion lets the FHIR path stand on its own.
Show example — 278 segments (EDI)
ST*278*0001*005010X217~
BHT*0078*13*REF12345*20260615*1015~
HL*1**20*1~ (payer / UMO)
HL*2*1*21*1~ (requesting provider)
UM*HS*I*3*...~ (health services review)
HI*BF:M5450~ (diagnosis: lumbar region)
SE*12*0001~National exchange
Getting records in and out across the country. TEFCA, live now.
TEFCA — facilitated FHIR + IHE live
Through a QHIN, REV queries the national network: facilitated FHIR for API exchange, plus IHE (XCPD patient discovery, XCA document query) for the C-CDA path. A one-doctor practice gets nationwide records with no point-to-point feeds.
Show example — cross-network patient query (FHIR)
# Facilitated-FHIR query across the network
GET /Patient?identifier=MRN-00482&family=Nguyen
&birthdate=1987-03-14
# IHE path: XCPD (patient discovery) -> XCA (document query)
# returns C-CDA documents for the matched patientAll the regulatory docs
Government rules
- ONC/ASTP — HTI-1 Final Rule
- ONC/ASTP — HTI-4 Final Rule
- CMS — CMS-0057-F
- Federal Register — HTI-1 rule text
FHIR & clinical data
- HL7 — FHIR R4
- HL7 — US Core 6.1.0
- ONC — USCDI v3
- HL7 — C-CDA
- HL7 — SMART App Launch
- HL7 — Bulk Data Access
Prior auth (Da Vinci)
- HL7 — CRD (coverage requirements)
- HL7 — DTR (documentation)
- HL7 — PAS (prior-auth submit)
- HL7 — PDex (payer data)
- HL7 — CDS Hooks
Prescribing & exchange
- NCPDP — SCRIPT + RTPB
- X12 — 278 prior auth
- Sequoia — TEFCA RCE
- ONC — TEFCA
Examples are minimal and illustrative, trimmed to show the shape of each format. The linked specs are authoritative. REV implements all of these natively; an incumbent retrofits each one onto a legacy core.