ATRIUM, in full detail.

Platform overview

ATRIUM is a clinical workflow intelligence platform purpose-built for chiropractic and neurology specialty practice. It does not replace the EHR. It sits alongside the EHR and absorbs the inbound document load: faxes, lab results, referral letters, attorney correspondence, imaging reports, and uploaded scans.

The platform performs three jobs:

• Ingest and structure. Documents are received from any of four channels, parsed, and matched to a patient record.
• Extract clinically meaningful fields. The documentation-assistance layer summarizes and pulls structured fields (test values, diagnoses, dates, ICD/CPT codes, attorney parties, dates of injury).
• Draft a clinician response. Where appropriate, ATRIUM produces a first-pass reply, addendum, or form completion. The physician reviews and signs.

The product is deliberately conservative: nothing leaves the practice unsigned, nothing is auto-filed, and every clinical action is attributable to a named user.

Architecture & data residency

ATRIUM is built around a HIPAA-architected, local-first data model. Three application tiers share one backend:

• Web application. Served over HTTPS, optimized for desk and laptop use during clinic hours.
• iOS application. A native iPhone client intended for end-of-day signing and on-call review.
• API. A secure backend service paired with a hardened relational data layer and a private retrieval index.

Where PHI lives

All clinical PHI — patients, encounters, documents, drafts, audit rows — is stored in a single-tenant database controlled by the practice. The identity provider only ever sees a user identifier and email; it does not receive patient data.

Encryption at rest

Sensitive fields (MFA secrets, encrypted message bodies) are protected with strong symmetric encryption using a tenant-specific key held outside the database row. Backups inherit the same encryption.

Authentication & access

ATRIUM supports two authentication paths, transparent to the end user:

• Local credential path. Email plus a salted, memory-hard password hash, with bound server-side sessions and short-lived access tokens.
• Identity provider path. Tokens issued by a managed identity provider, verified against published signing keys on each request.

Multi-factor authentication

TOTP (six-digit, time-based) is supported and recommended for all clinician accounts. Enrollment is performed in Settings → Security. Recovery codes are issued at enrollment and should be stored offline.

Session policy

Idle timeout defaults to 15 minutes; absolute timeout to 12 hours. The iOS app additionally requires a Face ID prompt to unlock a dormant session and to silently restore a refresh token from the device Keychain.

Roles & permissions

ATRIUM defines three primary roles. Each PHI access — read, write, or signature — is scoped by role and audited.

• Physician. Full clinical authority. Can review, edit, approve, and sign drafts; complete forms; access full audit trail.
• Medical Assistant (MA). Can triage intake, attach documents to patients, queue drafts for physician review, and respond to administrative correspondence. Cannot sign clinical content.
• Admin. Manages users, roles, integrations, and system configuration. Has no clinical authority by default.

Every signed clinical action remains attributable to the physician's user identity, regardless of who triaged the document upstream.

Intake pipeline

Documents enter ATRIUM through four channels:

1. Inbound fax. A managed fax number routes received pages directly to ATRIUM.
2. Lab interface. Reference labs deliver structured results.
3. Email intake. A dedicated, restricted address that accepts attachments from approved senders.
4. Manual upload. Drag-and-drop or file picker, available to all authenticated staff.

Pipeline stages

1. Receive. The raw artifact (PDF, TIFF, image, structured payload) is stored on encrypted document storage.
2. Parse. Text and structure are extracted. For images and faxes, OCR is applied. The extraction pass is performed by ATRIUM's documentation-assistance layer.
3. Patient match. Identifying fields are matched against the patient roster. Ambiguous matches are routed to the Intake queue for manual confirmation.
4. Embed. The document is chunked and indexed into the practice's private retrieval store.
5. Classify. The document type (lab, ortho referral, attorney letter, IME, etc.) is identified to choose the correct downstream draft template.
6. Draft. Where applicable, an initial draft response is composed.
7. Queue. The package — original, extracted fields, and draft — is placed on the physician's review queue.

Document review

The review screen presents three panes side-by-side:

• Source. The original document, page-faithful.
• Extracted fields. Structured key-value output of the parse pass — patient identifiers, dates, results, codes, parties.
• Suggested action. The drafted reply, addendum, or recommended file path.

Document states

Each document moves through a small, explicit state machine: received → parsed → matched → drafted → in_review → approved → signed → filed. Any state can be reverted by a privileged user; the audit log records the reversal.

Editing extractions

Extracted fields are editable inline. Edits are recorded as a diff against the original extraction and are signed by the editing user. This produces a permanent record of human correction, which is also the dataset used to evaluate extraction quality over time.

Computer-assisted drafting & revision

The drafting layer composes the first-pass response using the extracted structure plus a retrieval pass over the patient's prior documents. The draft is intentionally conservative in tone, avoids speculation, and cites the source document for each clinical claim.

Revision loop

Physicians can:

• Edit the draft directly. Saved as a new revision under your name.
• Send back with notes. A short instruction (e.g., "shorter," "remove paragraph 2," "address the right knee specifically") triggers a regeneration that incorporates the feedback.
• Reject and start over. Discards the draft entirely and produces a fresh attempt.

Signing

Signing finalizes the document. Once signed, the draft becomes immutable; subsequent corrections are appended as a new addendum, never an in-place edit. The signature event captures the user, timestamp, IP, and device fingerprint, and is hashed into the audit chain.

Sign Today queue

Sign Today is a clinician-facing inbox that surfaces every approved document awaiting a physician signature. It exists so that the daily signing pass is one screen, not many.

• Items are ordered by clinical urgency (critical labs first), then by age.
• Each item shows the source document, the drafted output, and a single Sign control.
• Skipping an item leaves it on the queue. Signing removes it.
• An empty queue is the day's terminal state.

PI case management

Personal-injury workflows have unique demands: the same patient may produce dozens of visit notes, multiple imaging reports, attorney requests, IME orders, and itemized billing requests over a long horizon.

ATRIUM groups all of these by case rather than by patient. A single PI case view aggregates:

• The patient's encounters tied to the date of injury.
• Inbound and outbound correspondence with attorneys and adjusters.
• Imaging and consultant reports.
• Itemized billing and payment ledger.
• Forms generated for the case (DWC-73, narrative reports, visit logs).

From the case view, a physician can request a narrative summary, generate a visit tracker, or compose a status response to opposing counsel — each one starting as a draft, each one signed before transmission.

Spreadsheet generation

ATRIUM ships with form-generation templates that populate from the patient and case context. Current templates include:

• DWC-73. Workers' compensation status form.
• PI Visit Tracker. A chronological visit log with codes and balances.
• Narrative summary. A long-form clinical narrative tied to a date of injury.
• Itemized billing export. Encounter-by-encounter billing for legal demand packages.

Best-effort field policy

For most fields, if extraction cannot confidently determine a value, the field is returned null and a warning is surfaced to the physician. The physician fills the field; the form proceeds.

Two exceptions exist where the system declines rather than guesses:

• Multi-patient ambiguity on the DWC-73 and PI Visit Tracker. Regulatory forms must not silently select a patient.

Clinical chat (retrieval-augmented)

The chat interface offers natural-language search over the practice's documents. It is grounded: every answer cites the document(s) it was drawn from, and a single click opens the source.

What the chat is good for

• "Pull every imaging study for [patient] in the last twelve months."
• "What was the conclusion of the IME on [date] for case [number]?"
• "Which PI patients have an open balance over $5,000?"
• "Has Dr. [referrer] sent us a follow-up since the last consult letter?"

What the chat is not

The chat is not a substitute for clinical judgment, and it does not produce signed clinical content. It is a search and synthesis tool. Anything the chat suggests as a clinical action returns to the standard draft-and-sign pipeline before it leaves the practice.

Audit log & compliance

Every PHI access — read, write, signature, export — produces a row in the audit log. The audit table is hash-chained: each row references the hash of the previous row, and the chain begins from a known genesis hash. Tampering with a historical row breaks the chain and is detectable on demand.

• UPDATE and DELETE are rejected at the database layer on the audit table. The chain can only grow.
• Periodic integrity verification is available to the practice administrator and is recommended monthly.
• Exports of PHI are themselves audited events: who, what, where, when.

For a HIPAA security review, the audit log is the single most important artifact ATRIUM produces. It is designed to satisfy a forensic question, not just a compliance checkbox.

iOS application parity

The iOS application is a first-class client, not a remote viewer. Capability parity:

• Full document review and signing. Sign Today, draft revision, and approve flows are identical.
• PI case browsing. Read-only on iPhone for now; full case actions remain on the web client.
• Chat. Full read parity; same source-citing behavior.
• Face ID gate. A dormant session unlocks via biometrics before any PHI is rendered.
• No PHI persisted to device beyond the active session. Refresh credentials live in the Keychain; document content is fetched fresh.

The visible tab bar holds Dashboard, Intake, Documents, and Chat. PI Cases, Sign Today, and Settings are reachable from More.

Operations & support

Backups

The PostgreSQL database is backed up nightly. Restore-to-point-in-time is supported within the retention window agreed with the practice.

Incident response

Suspected security incidents (lost device, suspicious access, possible PHI exposure) should be reported to the practice administrator immediately. ATRIUM provides session-revocation tooling so any clinician account can be force-logged-out within seconds.

Routine support

Day-to-day issues — a misclassified document, a draft that came back wrong, a missing patient — are best routed to the practice administrator first. They have the tooling to inspect, correct, and re-queue. Platform-level issues escalate from there.

Scheduled maintenance

Maintenance windows are coordinated with the practice and announced in advance. Reads remain available where possible; signing is briefly paused during database upgrades.

Glossary

Audit chain

Hash-linked log of every PHI access. Designed so that any tampering is detectable by recomputing the chain.

DWC-73

A workers' compensation status form. ATRIUM populates it from case context and surfaces unfilled fields for physician completion.

Extraction

The structured key-value output produced from a parsed document. Editable; edits are themselves audited.

IME

Independent medical examination. A common artifact in PI cases.

Intake

The triage queue for documents that have arrived but not yet been routed to a patient or assigned a downstream action.

Patient match

The step that associates a received document with an existing patient record. Ambiguity routes to manual review.

PHI

Protected health information. All PHI in ATRIUM lives in self-hosted PostgreSQL controlled by the practice.

PI case

Personal-injury case. A case-level grouping that aggregates encounters, correspondence, imaging, and billing tied to a single date of injury.

RAG

Retrieval-augmented generation. The technique used by the chat: retrieve the relevant documents, then ground the answer in them.

Sign Today

The end-of-day signing queue. Surfaces every approved-but-unsigned item in one list.

TOTP

Time-based one-time password. The six-digit codes used for multi-factor authentication.