XyDromatics™ Encounter Engine — no more orphan studies.

POCUS = point-of-care ultrasound -- bedside ultrasound performed by a clinician (hospitalist, intensivist, ED physician) without a pre-existing order in the EMR. The traditional radiology workflow assumes the order exists first, then the imaging happens. POCUS reverses that: imaging first, no order. The study lands in PACS as an "orphan" -- no order to attach to, no patient ID match, no billing capture, EMR doesn't know the imaging happened. Multiply that across an ED, ICU, OR, and clinic and you have meaningful revenue leakage and incomplete patient records. Encounter Engine catches the orphan, verifies the patient via human-confirmed ADT match, back-fills the EMR order retroactively, and forwards the cleaned-up study to the archive.

Two reasons. Regulatory: the human gate is what keeps this product on the Non-device software side of the line. Auto-attribution of imaging to a patient without human verification crosses into clinical-decision territory that would push the regulatory classification up. Clinical: ADT matching gives candidates, but wrong-patient errors at the verification stage are clinically significant. A clinician confirming "yes, this is patient X" is the right safeguard. Engine never auto-attributes; the gate is mandatory and audit-trailed.

Encounter Engine subscribes to the EMR's HL7 v2 ADT feed over MLLP and caches the identity-bearing events: A01 admit, A04 register, A05 pre-admit, A08 update, A28 and A31 person add and update, and A40 patient merge. That cache is an encounter-identity index, not a bed map — it answers who this patient is, not which room they are in. When an unidentified study arrives, the engine looks up candidate encounters and presents them in the verification UI with enough context for a person to accept one or reject the study. A merge event re-points the affected identities rather than leaving a stale match behind.

The hash-chained audit trail records every verification with the verifying user's identity, the timestamp, and the committed identity fields (patient ID, name, date of birth, sex, accession) — enough to answer who stamped what onto which study. Verification is a one-way commit: once a study is accepted it is stamped and forwarded, and Encounter Engine does not re-open it. A mis-attribution found downstream is corrected in the receiving systems — the PACS / VNA and the EMR — through their own correction workflows; Encounter Engine emits new orders only (ORC-1 = NW), never cancellations. A study caught before acceptance can be rejected or quarantined, both of which require reason text.

Standard HL7 v2 / FHIR interfaces -- ADT subscription inbound, ORM^O01 / ServiceRequest outbound. Both Epic and Cerner expose these natively; the integration is straightforward HL7 / FHIR work, not vendor-specific custom development. Encounter Engine creates the order and accession in the EMR, so the encounter becomes billable through the EMR's own revenue cycle rather than through a charge tag emitted here. Any EMR exposing HL7 v2 or FHIR R4 works the same way.

No. Encounter Engine is a DICOM-receive front door. Modalities that emit non-DICOM formats (proprietary US streaming, raw image files, etc.) need a converter upstream. For ultrasound specifically, modern POCUS scanners emit DICOM by default; older scanners or research-grade devices may need a DICOMization layer first.

Same family-wide keying as the Router, the archive family, SR Engine, Migration Engine and Pathology Engine — one per-customer site key, so a patient resolves to the same pseudonym across every product you run. Encounter Engine performs the OUTBOUND leg: it pseudonymizes the verified study per destination on the way out, and seals the re-identification map, customer ID and key version inside the study itself. Restoring identity on the return leg is done by the product that receives the findings — the Router or an archive host — not by Encounter Engine. It is included with the product, not a licence tier.

Non-device software under FD&C Act §520(o)(1)(D), the 21st Century Cures Act §3060 carve-out for software that transfers, stores, converts, or displays device data without interpreting or analyzing it. Same framework as the rest of the engines family. The mandatory human-verification gate is what keeps the product within the non-device carve-out -- auto-attribution of imaging to a patient without human confirmation would push the regulatory posture to a device classification; the gate preserves the storage-and-forwarding-without-clinical-interpretation framing of §520(o)(1)(D).

Yes -- Windows and Linux, same as the rest of the router-pattern family except for Pathology Engine. MSI installer for Windows, self-contained Linux tarball for Linux. Encounter Engine runs as a single instance; redundancy is delegated to the host OS cluster manager (WSFC on Windows, Pacemaker on Linux), so a standby pair is single-platform by construction.