Live NEDOCS scores from your Epic, Cerner, or Meditech ADT feed

Overview

A documented feed in, a live score out

NEDOCS consumes documented HL7 data sources and mines the variables that drive the National Emergency Department Overcrowding Scale. Like the NYU Langone deployment, a single consolidated feed carrying ADT, ORU, and ORM messages is the simplest path: one connection covers registrations, transfers, flowsheet acuity, and admit orders.

Each message updates a live ED-encounter model. NEDOCS re-derives the seven calculator inputs and, whenever they change, writes a score — firing the same timeline events, realtime updates, agency webhooks, and notifications as a manual charge-desk entry.

Architecture

Two ways to deliver messages

Message specifications

Event types and required elements

ADT — Admit / Discharge / Transfer

Required elements: PV1-2 class, PV1-3 assigned location, PV1-6 prior location, PV1-19 visit number, PV1-44 admit time, EVN-2/EVN-6 event time, PV2-2 accommodation.

ORU^R01 — Flowsheet results

OBX segments carry acuity (ESI) and airway data. Observation IDs are configured per site — for example the NYU Langone Epic FDC records 1600000010 (airway type) and 1600000009 (airway size). Required: PV1-19, OBX-3 (observation ID), OBX-5 (value).

ORM^O01 — Order messages (admit)

Admit orders flag a patient as a boarder before the ADT class flips. Required: PV1-19, ORC-1 (order control), ORC-9 (transaction time), OBR-4 (service ID), NTE-3 (comment).

Mapping

How HL7 becomes the seven NEDOCS inputs

Bed capacity cannot be inferred from a message feed, so ED and inpatient bed counts are read from your hospital configuration.

Filtering & transfer logic

The NYU “EMERG” transfer fix

Interface-engine filters often exclude certain patient classes (e.g. Outpatient “O”) by default, which can silently drop the transfer that moves a boarder out of the ED when the class is flipped prematurely (E → O) mid-transfer.

NEDOCS applies the NYU refinement: an ED departure is inferred whenever the prior location field PV1-6 contains EMERG, regardless of patient class. The ED-location pattern is configurable per site.

Endpoints

Post messages over HTTPS

Routes by MSH-9. Typed variants: /api/hl7/adt, /api/hl7/oru, /api/hl7/orm. Pipeline status: GET /api/hl7/status.

Send raw HL7 (curl)

Or wrap in JSON

JSON response

Add ?ack=hl7 (or Accept: application/hl7-v2) to receive a raw HL7 MSA|AA|… acknowledgement instead of JSON.

Authentication

Per-hospital API key

Send your hospital key any of these ways:

• Authorization: Bearer {key}  (preferred)
• X-API-Key: {key}
• id={key} in the query string or body (legacy compatibility)

Keys are provisioned during enterprise onboarding and mapped to your hospital. Never publish production keys in source control.

MLLP

Optional socket listener

When an engine can only speak raw MLLP, NEDOCS runs a TCP listener that accepts <VT>message<FS><CR> frames and returns a framed HL7 ACK. Debug connectivity by verifying a TCP connection to the listener port; a “Connection refused” error means the listener is not reachable.

Security

2048-bit TLS, no PHI at rest

All API traffic is transmitted over a 2048-bit (or higher) TLS connection. NEDOCS does not store PHI — it extracts synthesized numbers and metrics. Only a visit-number correlation key and the derived flow variables are persisted; names, dates of birth, and full MRNs are never retained. See our HIPAA & SOC compliance details.

Onboarding

What we need from your team

• A consolidated ADT + ORU + ORM feed (or separate feeds) from your interface engine.
• Your ED location naming so we can tune the EMERG / ED-location pattern.
• Flowsheet observation IDs for acuity (ESI) and airway, if you send ORU results.
• ED and inpatient bed counts entered under Settings.
• A test message set — we validate parsing and scoring before go-live.

Machine-readable capability manifest: /.well-known/nedocs-integration.json. Prefer REST/JSON? See the REST API reference.