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 (A01 admission, A02 transfer, A03 discharge, A08 update, A11 cancel) or to the FHIR Encounter resource. From those events it maintains a real-time per-location patient-bed map: which patient is in which bed at any given moment. When imaging arrives, the engine queries the map for the imaging location and returns candidate match(es). Match windows are configurable by location, time of imaging, and clinician on shift. The verification UI shows the candidate(s) with enough context for the clinician to confirm or override.

Audit trail captures every verification decision with the verifying clinician's identity, the chosen match, and any reason text. If a downstream review (radiologist, QA, RIS reconciliation) flags a mis-attribution, a re-verification workflow lifts the study back into the verification queue with the original decision visible. The corrected match generates a cancellation HL7 ORM for the wrong order and a new ORM for the right one. Both events are audit-trailed end-to-end. Mis-attributions happen rarely in practice but the workflow has to handle them cleanly when they do.

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. Charge-capture tag emission is configurable to match institutional revenue-cycle integration. We've done this against both EMRs; other EMRs with HL7 v2 / FHIR support work 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 mechanism as the Router, VNA family, SR Engine, Migration Engine, and Pathology Engine. Encounter Engine uses keyed-hash pseudonymization on the way out (de-identifies the verified study before forwarding to AI vendor), retains the source ↔ anon-ID mapping, re-identifies AI-returned findings on the way back, and forwards findings linked to the correct patient. Available in the Enterprise license 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. No FDA Device Listing required. 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. HA pairs can mix OS platforms.