Exporting a Bladder Diary to Epic, Cerner, and Other EMRs

Bladder Diaries exports the patient diary as two standard files: a FHIR R4 Bundle (.fhir.json) for modern EMRs that ingest FHIR, and an HL7 C-CDA R2.1 CCD (.ccd.xml) for legacy systems and Direct Secure Messaging. Both files are built in the browser, downloaded locally, then attached to the chart through the receiver EMR's standard inbound. No patient data transits the bladderdiaries.com servers; the synthetic Patient placeholder is replaced by the receiver chart-matching tooling on ingest.

You just finished a 3-day diary with a patient. The calculator returned MVV (maximum voided volume) 320 mL, AVV (average voided volume) 145 mL, NPi (nocturnal polyuria index) 32%, 24hVV (24-hour voided volume) 2.1 L, and FVC (frequency-volume chart) frequency 9 voids per 24 hours. The remaining question is mechanical: how do these numbers land in the chart in a form your coder, your nurse, and the next visit can read? This walkthrough covers the two file formats, where each lands in Epic, Cerner / Oracle Health, Athena Health, Prompt Health (via Kno2), and the legacy EMR, and what the chart-matching contract looks like on the receiver side.

The two file formats: FHIR R4 Bundle vs HL7 C-CDA R2.1 CCD

The two standards in the chart-import catalog are FHIR (Fast Healthcare Interoperability Resources) and C-CDA (Consolidated Clinical Document Architecture). Both are HL7 standards; both carry the same diary data in different wire shapes. Bladder Diaries emits both because the EMR ecosystem is bilingual: modern installations ingest FHIR natively, legacy ambulatory installations ingest C-CDA, and federal mandates (21st Century Cures Act, ONC Cures Act Final Rule) require certified EHR technology to support FHIR R4 since 2023, with C-CDA R2.1 as the legacy on-ramp.

FHIR R4 Bundle: the modern path

FHIR R4 (released October 2019) is the resource-oriented JSON standard the modern EMR cohort ingests. The export ships as a Bundle of type: "collection" containing:

• 1 placeholder Patient resource carrying the REPLACE_WITH_MRN sentinel on Patient.identifier. The receiver fills in the real MRN at ingest.
• N event-level Observation resources: one per void, one per fluid intake, one per urgency rating (where present), one per leakage event. The receiver sees the raw timeline.
• 5 calculated-metric Observation resources for MVV, AVV, NPi, 24hVV, FVC, each carrying a hybrid LOINC plus custom Bladder Diaries CodeSystem coding (per Phase 8 D-12). The receiver gets a standard coding and a precise coding.
• 1 DiagnosticReport summarizing the metrics, with the PDF base64-encoded into presentedForm[0].data. A human-readable artifact is always available alongside the structured data.

The Bundle validates against the HL7 R4 schema and the US Core 6.1.0 Implementation Guide profile. Receivers that profile against US Core (Epic, Cerner / Oracle Health, Athena, Allscripts / Veradigm) see the expected fields: Patient.identifier, Observation.code, Observation.value[x], Observation.effectiveDateTime, DiagnosticReport. Receivers that do not profile against US Core still get the base R4 shape, which is sufficient for ingest.

HL7 C-CDA R2.1 CCD: the legacy on-ramp

C-CDA R2.1 (released July 2015) is the XML-based document standard the legacy ambulatory EMR cohort and the Direct Secure Messaging transport ingest. The export ships as a ClinicalDocument with:

• The US Realm Header (CONF:1198-*) covering Patient placeholder, custodian organization, document author, and the standard CDA scaffolding.
• A body containing the six required CCD sections (Allergies, Medications, Problems, Procedures, Results, Social History), with nullFlavor="NI" on the sections the diary does not populate.
• A Results organizer carrying the same five calculated metrics, each <observation> double-declared with the Result Observation V3 templateId (2.16.840.1.113883.10.20.22.4.2, extension 2015-08-01).
• An observationMedia element carrying the PDF report base64-encoded inline, no separate attachment needed.

The CDA validates against the HL7 SDWG C-CDA R2.1 schematron (closed during Phase 11 Plan 11-01). The C-CDA path is the right pick when the receiver EMR predates the 21st Century Cures Act compliance cycle, when the workflow is mediated by Direct Secure Messaging, or when the receiver IT team has disabled the FHIR inbound.

Which one do I pick?

| Receiver EMR | Format | Inbound surface | | ------------------------ | ---------- | -------------------------------------------------------------------------- | | Epic | FHIR R4 | SMART on FHIR app, FHIR Inbox, chart attachment on routine encounter | | Cerner / Oracle Health | FHIR R4 | FHIR R4 inbound, Bridges, Code App Gallery | | Athena Health | FHIR R4 | More Disruption Please (MDP) inbound; falls back to CCD where MDP disabled | | Prompt Health | Either | Kno2 partnership: receiver-side normalizer accepts both | | Allscripts / Veradigm | FHIR R4 | dbMotion / TouchWorks ingest | | NextGen | C-CDA | CCD inbound; FHIR roadmap not yet shipped on all editions | | eClinicalWorks | C-CDA | CCD inbound | | Greenway / Intergy | C-CDA | CCD inbound | | Long-tail legacy | C-CDA | Direct Secure Messaging (DSM), HIE delivery to inbox |

The decision rule: send FHIR R4 if you know the receiver supports FHIR. Send C-CDA if you do not know, or if the receiver is explicitly on the legacy on-ramp. Bladder Diaries emits both files from the same calculator output, so you can keep both files on hand and use the one the receiver actually accepts.

Step-by-step: from /entry to the chart

The end-to-end workflow has four steps. The first three live in your browser, on bladderdiaries.com. The fourth lives in the receiver EMR.

Step 1: Enter the diary at /entry

Open the Calculator on bladderdiaries.com. Enter the patient diary as voids, fluid intakes, bedtime markers, and (when documented) leakage events and urgency ratings. The single-screen entry form takes about 90 seconds for a typical 3-day diary. Patient age and enuresis flag drive the NPi age-band threshold and the continence classification.

Step 2: Read the metrics at /results

The calculator routes to /results after submit. The page renders MVV, AVV, NPi, 24hVV, FVC, and the IPC (Integrated Pelvic Care) 4Is classification (Fluid Imbalance, Storage Impairment, Voiding Impairment, Incontinence). The four-bucket framework feeds back into the chart language for the encounter note; see the bladder diary interpretation pillar for the clinical-framework discipline that pairs the numbers with the differential.

Step 3: Press the export button

The export bar at the top of /results carries three buttons: PDF, FHIR Bundle, and C-CDA CCD. Press the format the receiver EMR accepts. The file builds in the browser (FHIR Bundle in JSON, CCD in XML) and lands in your local download folder with a deterministic filename: bladder-diary-YYYY-MM-DD.fhir.json or bladder-diary-YYYY-MM-DD.ccd.xml. No HTTPS upload to bladderdiaries.com occurs; the toast confirms "downloaded. Note: the file is stored on your device outside this calculator."

Step 4: Attach to the chart in the receiver EMR

Epic via SMART on FHIR: if your organization has built a SMART on FHIR patient-facing app, the patient uploads the FHIR Bundle through MyChart. If your IT team has enabled the FHIR Inbox, drop the file there. If neither path is available, attach the FHIR Bundle as a chart attachment on a routine encounter; the file lives in the chart as a binary and the structured data can be re-parsed later.

Cerner / Oracle Health: the FHIR R4 inbound accepts the file via the R4/$import operation when IT has enabled it. Many institutions route through Bridges (the Oracle Health interoperability layer). The Code App Gallery is a third path: a SMART on FHIR surface where the file uploads as a patient-attached resource.

Athena Health: the More Disruption Please (MDP) inbound is the FHIR R4 path. Drop the FHIR Bundle through the MDP endpoint. If your Athena instance ships only the legacy CCD inbound, send the C-CDA CCD instead.

Prompt Health: the Kno2 partnership accepts both file formats. Kno2 acts as a receiver-side normalizer that converts FHIR or CCD into the format the downstream EMR expects. The same path works for any EMR in the Kno2 network.

Legacy EMR via Direct Secure Messaging (DSM): the C-CDA CCD travels via DSM as an XML attachment. The receiver Health Information Service Provider (HISP) delivers it to the receiver inbox. The DSM path is the right pick for ambulatory practices that have not yet adopted FHIR.

Plain-email fallback is not recommended. Prefer the receiver EMR's standard inbound; the email path is a last-resort manual workflow.

The privacy contract: pure-client, no PHI transit

The single most important property of the export pipeline is that it never transmits patient data. Both files are built entirely in your browser from diary data the clinician entered at /entry. The diary lives in browser localStorage only: no server-side database, no HTTPS upload to bladderdiaries.com, no third-party analytics on the diary payload.

The receiver EMR is the chart-matching authority. The Patient placeholder carries REPLACE_WITH_MRN on Patient.identifier precisely so the receiver can run its own matching against the local MRN namespace. The receiver IT policy determines whether the matching is automatic (system-side R4/$import with a chart-link rule) or manual (front-desk staff matches the inbound file to the chart). Bladder Diaries does not see, store, or transmit any matching information.

The HIPAA / GDPR posture follows from this design. Bladder Diaries stays outside the HIPAA Covered Entity perimeter and outside the GDPR data-controller perimeter because it never holds patient data on its servers. The clinician's local browser holds the diary; the clinician's file system holds the export; the receiver EMR holds the chart. Each link is a known compliance surface for the local IT team and the local Business Associate Agreement (where applicable); the bladderdiaries.com link is empty by design.

This is documented in the Privacy Policy. The pure-client invariant is the architectural lock that keeps Bladder Diaries out of the regulatory perimeter; the file-format catalog is the operational on-ramp that delivers structured data to the chart anyway.

What is the 2.25.* CodeSystem OID in my audit log?

Receivers that audit the inbound document by CodeSystem will see a Bladder Diaries-specific Object Identifier (OID) in the audit log, in the form 2.25.<uuid-decimal>. This is intentional and worth a brief explanation, because clinical IT teams sometimes flag unknown OIDs as a security concern.

An OID is a hierarchical identifier registered against a global tree (the ISO/IEC 9834 OID arc). HL7 standards use OIDs to identify code systems unambiguously: LOINC is 2.16.840.1.113883.6.1, SNOMED CT is 2.16.840.1.113883.6.96. Each OID corresponds to a registered authority that maintains the codes.

The five Bladder Diaries calculated metrics (MVV, AVV, NPi, 24hVV, FVC) are not yet fully covered by canonical LOINC. LOINC has codes for the underlying volumes (e.g. 28604-5 Voided volume, 28649-0 Urine output 24 hour) but not for the bladder-diary-specific calculated metrics in the precise form the IPC framework needs. The hybrid coding emits both a LOINC code (where one exists) and a custom Bladder Diaries code (always), so the receiver gets a standard coding to anchor a search and a precise coding to anchor a calculation.

The custom CodeSystem needs an OID. Rather than apply for a registered arc through HL7 (a multi-month process), Bladder Diaries uses the 2.25.* arc per RFC 4122 §4.5, which permits any party to derive a globally unique OID from a UUID by treating the UUID as a decimal integer. The resulting OID is unique without registration, traceable, and conformant with the HL7 standard for CodeSystem identifiers. The clinical IT team can document the OID as Bladder Diaries-issued (a one-time approval in the OID allow-list) and the audit log continues to flow normally.

What to ask your IT department before the first export

Five questions align expectations before the first patient export. The answers determine which file format and which inbound surface to use:

1. Do we support FHIR R4 ingest? Most EMR installations as of 2026 support FHIR R4 to some degree; the variance is on the inbound surface (SMART on FHIR app, FHIR Inbox, R4/$import, vendor-specific path).
2. Do we support C-CDA R2.1 ingest? C-CDA R2.0 receivers can usually parse R2.1 documents (the schema is backward-compatible), but the schematron warnings may differ.
3. What is our SMART on FHIR app surface? Epic and Cerner / Oracle Health: this answers whether the FHIR Bundle uploads via a patient-facing app (MyChart) or only via the back-office FHIR Inbox.
4. Is our Direct Secure Messaging address discoverable? Legacy ambulatory EMRs: the DSM address is the destination for the C-CDA CCD. Your HISP can confirm the address is published in the DirectTrust registry.
5. Do we have a Kno2 partnership? Prompt Health and other Kno2-connected EMRs: the Kno2 inbound is a single endpoint that routes to multiple downstream EMRs.

Bonus: what are the chart-matching rules for an inbound file with a placeholder MRN? Some receivers auto-match on demographics (name plus DOB plus sex plus address); others require a fully populated Patient.identifier. Knowing the receiver policy tells you whether the file routes automatically or whether the receiver staff will manually match.

FAQ

Which file format should I send to Epic? FHIR R4 Bundle (.fhir.json). Epic ingests FHIR R4 via its SMART on FHIR app surface, the FHIR Inbox if your IT team has enabled it, or as a chart attachment on a routine encounter. Validates against US Core 6.1.0.

Which file format should I send to Cerner or Oracle Health? FHIR R4 Bundle (.fhir.json). Cerner / Oracle Health ingests FHIR R4 via the same standard. Some institutions route through Bridges or the Code App Gallery; the back-office FHIR inbound is the standard path.

Which file format should I send to Athena Health? FHIR R4 Bundle (.fhir.json) via the More Disruption Please (MDP) inbound. If your Athena instance is on the legacy CCD inbound only, send the C-CDA CCD (.ccd.xml) instead.

Which file format should I send to Prompt Health? Either. Prompt Health accepts both formats via its Kno2 partnership; Kno2's receiver-side normalizer converts to the format the downstream EMR expects.

Does Bladder Diaries upload my patient data anywhere? No. Both file formats are generated entirely in your browser. The file lands in your local download folder; no HTTPS upload to bladderdiaries.com or any third party. The Privacy Policy describes this in full.

What is the REPLACE_WITH_MRN placeholder? A deliberate sentinel value on the synthetic Patient resource. Your EMR chart-matching tooling replaces it with the real medical record number on ingest. This pattern lets the file ship without any patient-identifying data and lets the receiver enforce its own chart-matching policy.

Why does my EMR audit log show a 2.25. CodeSystem OID I do not recognize?* That is the Bladder Diaries custom CodeSystem, self-allocated under the RFC 4122 §4.5 OID arc. Used for the five calculated metrics (MVV, AVV, NPi, 24hVV, FVC) that canonical LOINC does not yet cover. Each metric also carries a hybrid LOINC code where one exists.

Can I send the same file to multiple EMRs? Yes. Both file formats are receiver-agnostic. The same FHIR Bundle or C-CDA CCD can be routed to multiple EMRs in parallel (e.g. primary care plus specialty referral). The receiver chart-matching at each destination is independent.

Closing: try it on the next diary

The next 3-day diary you finish with a patient on Bladder Diaries is the test case. Open the Calculator, enter the diary, read the metrics on /results, and press the export button matching the receiver EMR. The file lands in your download folder; attach it through the receiver EMR's standard inbound. The clinician now has the same structured numbers in the chart that the calculator returned on the screen, the bladderdiaries.com servers stay empty, and the standards-based file lands where it belongs: in the chart, alongside the rest of the patient record.

Author: Dr. Di Wu, MD, PT (IPC founding member). The v5.0 Bladder Diaries milestone ships standards-based EMR interoperability. Standards referenced: HL7 FHIR R4, HL7 C-CDA R2.1, US Core 6.1.0 Implementation Guide, LOINC, and RFC 4122 §4.5 (UUID-derived OID arc). Photo: Vitaly Gariev on Unsplash.