Epic ClinDoc

What is Epic ClinDoc?

Epic ClinDoc, short for clinical documentation, is the part of Epic's inpatient record where nurses and other clinicians document care during a hospital stay. Its building blocks are flowsheets for vital signs and assessments, records of lines, drains and airways, care plans and patient education, all filed on the same record physicians use for orders and notes.

Health systems assign Epic analysts to build and maintain ClinDoc content, such as flowsheet rows and templates, for their units. That build is local, so the flowsheet row for a given measurement at one hospital is not the same row at another.

What does a nurse chart in ClinDoc during a stay?

A nurse charts the whole arc of the stay, from admission to discharge. NYC Health + Hospitals' ClinDoc inpatient nurse course gives a clear outline of the work.

• Start of shift: Reviewing assigned patients and what is due.
• Flowsheets: Documenting vital signs, assessments and other measurements in rows and columns over time.
• Lines, drains and airways: Recording insertion and removal, with site and status in between.
• Care plans and education: Starting the care plan and documenting patient education.
• Movement: Admitting a patient from the emergency department, arriving a transfer patient and discharging a patient.

The same course is listed for adult and pediatric inpatient nurses, LPNs, nurse managers and ICU, oncology, wound care and IV nurses. Each group charts in ClinDoc, but on flowsheets built for its own unit and specialty.

Medication administration sits next to this work on the medication administration record. Outside apps can read administrations through Epic on FHIR, which lists MedicationAdministration read and search, not create.

How does bedside device data reach the flowsheet?

Bedside device data reaches the flowsheet through HL7 v2 device interfaces, often by way of a device integration system that collects readings from monitors and other equipment. open.epic documents the interfaces on the Epic side.

• Incoming Device Data: Receives discrete measurements from patient monitoring and documentation devices.
• Incoming Clinical Documentation Flowsheet Data: Receives discrete patient data from an external system, where a user has already validated the data.
• Outgoing Clinical Documentation Flowsheet Data: Sends discrete flowsheet data to another system, such as a registry or analytics platform.
• Device alerts: A separate interface stores technical and physiological alert data from patient care devices such as monitors and infusion pumps.

The device side needs as much design as the Epic side. Each device must be associated with the right patient and bed, readings need units and timestamps that match the flowsheet rows, and the integration has to cope with a device moved from one patient to the next without the association being updated.

Keep alarms and readings on separate paths. A monitor alarm is an event for a nurse to respond to, often through the hospital's alarm or communication system, while a reading is data for the chart. Mixing them fills flowsheets with noise and buries alarms in documentation.

Which ClinDoc data can a FHIR app read or file?

A FHIR app can read most of what nurses chart and can file some measurements. Epic on FHIR lists these R4 resources for inpatient documentation data.

• Observation (Flowsheets): Read, search and create, for flowsheet data beyond vital signs.
• Observation (Vital Signs): Read, search and create, for vital sign readings.
• Device (Lines, Drains, Airways): Read and search, for the lines and drains documented on the patient.
• CarePlan (Inpatient): Read and search, along with an inpatient pathway variant.
• DocumentReference (Clinical Notes): Create, for apps that file a note into the chart.
• MedicationAdministration: Read and search, for administrations on the record.

Filing a flowsheet value depends on the customer's build. The app has to send the value against the flowsheet row the customer uses for that measurement, in the units that row expects, so every new customer means a new mapping exercise with their ClinDoc analysts.

Reads have their own design question: what counts as current. Flowsheet values can be edited or marked in error after filing, so an app that copies them should re-read the values rather than trust the first value it saw.

Access scope differs by launch type. A SMART on FHIR app launched from the nurse's workflow acts for that user and patient, while a back-end service that reads flowsheets for a whole unit needs separate approval from the customer for that wider access.

Validated versus unvalidated data

A device reading is not documentation until a clinician accepts it. Epic's incoming flowsheet interface is described for data a user has already validated, and the hospital decides how device readings are reviewed before they count as charted.

• Validated at the source: The nurse reviews readings in the outside system and sends only accepted values, which then file as documentation.
• Validated in Epic: Readings arrive as device data and the nurse accepts or rejects them in the flowsheet before they count.
• Never validated: Continuous waveform or high-frequency data stays in the device system, and only summary values reach the chart.

Pick one model per data type with the nursing informatics team, and write it into the interface specification. Mixing models on one unit leads to duplicate rows and confusion over which value is the charted one.

Artifacts make the choice concrete. A blood pressure taken while the cuff was moving, or a saturation reading from a probe that slipped, should never become the charted value without a nurse seeing it first.

How should a vendor plan its first ClinDoc customer?

Plan the first customer as a template for the next ten. Every decision made only for that hospital becomes rework later, so separate what is product from what is configuration from the start.

• 1. Name the data: List every measurement, its unit, its frequency and whether it needs validation.
• 2. Choose the path: HL7 v2 device interface for streams of readings, FHIR Observation create for occasional app-entered values.
• 3. Map with the analysts: Get the customer's flowsheet row for each measurement and record it in configuration, not code.
• 4. Agree association: Decide how a device, a bed and a patient are linked, and who updates the link when a patient moves.
• 5. Test on the unit: Run the feed in the test environment with nurses from the target unit charting real scenarios.
• 6. Plan downtime: Decide what the device system holds during an Epic downtime and how it replays without duplicates.
• 7. Hand over monitoring: Name who watches rejected messages after go-live and how they are corrected.

Write down what changed for the second customer. The list of differences, such as row IDs, units and validation models, becomes the configuration screen your product needs.

Federal rules behind inpatient documentation

Hospital documentation follows Medicare's Conditions of Participation as well as HIPAA. These are the rules a ClinDoc integration has to respect.

• Nursing care plan: 42 CFR 482.23(b)(4) requires the nursing staff to develop and keep current a nursing care plan for each patient, which may be part of an interdisciplinary care plan.
• Record entries: 42 CFR 482.24(c)(1) requires every medical record entry to be legible, complete, dated, timed and authenticated by the person responsible for the service.
• Audit controls: 45 CFR 164.312(b) requires mechanisms that record and examine activity in systems that contain ePHI.
• Integrity: 45 CFR 164.312(c) requires policies to protect ePHI from improper alteration or destruction, with an addressable mechanism to confirm data has not been changed.

The authentication rule is why validation matters. An unreviewed device value filed as if a nurse charted it raises the question of who is responsible for that entry.

Where do ClinDoc integrations go wrong?

They go wrong at the joins between device, patient, flowsheet row and nurse. The failure points below are the ones to design out first.

• Hard-coded rows: Flowsheet row IDs from the first hospital are baked into the code and fail at the second.
• Unit mismatch: Temperatures or weights arrive in a unit the row does not expect, and values are rejected or wrong.
• Stale device association: A monitor moved to a new patient keeps sending readings to the previous patient's chart.
• Time drift: Device clocks differ from Epic's, so readings file at the wrong time on the flowsheet.
• Duplicate filing: The same value arrives through a device feed and a FHIR write.
• Alerts as documentation: Device alarms are pushed into the chart as if they were assessments.
• No downtime plan: Readings collected during an Epic downtime are lost or filed twice when the interface catches up.

Test each of these in the customer's environment with nurses from the target unit. They will find workflow gaps that a message validator never shows.

How Agnotic can help

Inpatient data integrations succeed or fail on mapping and validation. Agnotic Technologies builds the device feeds, flowsheet mappings and FHIR integrations that carry bedside data into ClinDoc, with configurable row and unit mappings per customer, patient and device association checks, and downtime replay that does not double-file.

Agnotic works with the hospital's ClinDoc analysts and nursing informatics team on the validation model, and builds to HIPAA Security Rule safeguards and the audit trail the Conditions of Participation expect.

Sources

• NYC Health + Hospitals: Epic course listing, ClinDoc Inpatient Nurse
• open.epic: HL7 v2 clinical interfaces, including device and flowsheet data
• open.epic: Clinical interfaces, including patient care device alerts
• open.epic: FHIR interfaces, including Observation (Flowsheets) and Device (Lines, Drains, Airways)
• 42 CFR 482.23: Condition of participation, nursing services
• 42 CFR 482.24: Condition of participation, medical record services
• 45 CFR 164.312: Technical safeguards