By Content Team 

Building Compact AI for Emergency Department Triage: Architecture and Delivery Considerations

Compact AI for emergency department triage is a model and workflow small enough to run inside the hospital’s limits on latency, privacy, and downtime, while a clinician remains the person who decides. The delivery question is not which model is largest. It is where the model runs, which data it may see, what it is allowed to write back, and what staff do when it is unavailable. This is an architecture and delivery guide for IT and clinical informatics. It is not a clinical protocol, and it does not rank products.

Hexagon IT Solutions approaches this as a governed software system: identity, integration, audit, and a named owner. Nothing in this article tells a clinician how to assign acuity or how to treat a patient.

What should the system be allowed to output?

Answer: Limit the output to a stated assistive task that a clinician can accept, edit, or ignore. Examples that stay inside an IT scope are a draft summary of already captured fields, a prompt that a required field is empty, or a sorting suggestion that does not change the official acuity until a person confirms it. An unattended disposition, a hidden change to the legal record, or an instruction to give a medication is out of scope for a compact assistive build.

Write that boundary in the requirements before you pick a model. If the sentence you want on screen cannot be reviewed in the time a triage nurse actually has, the feature is too wide. Compact means a bounded context and a short, predictable response, not a chat window over the full chart.

Where should it run?

Place the model where the hospital can still function when the vendor or the network fails. Many emergency departments need an answer on the local clinical network, or they need the existing triage process to continue with no model at all. An external API can be appropriate for a non-urgent summarization task. It is a poor default for a step that sits on the arrival path unless downtime behavior is already designed.

Decide these items in the architecture review:

• The runtime: hospital-controlled environment, a locked-down appliance, or a named external service, and who administers it.
• The data that may leave the department, if any, and the agreement that covers it.
• The latency budget in ordinary language, such as “the suggestion appears before the nurse finishes the current screen,” not a slogan about speed.
• The fallback: if the model times out, the record stays as the clinician entered it and the visit is not held.

Smaller or quantized models are a means to hit that budget. They are not a clinical claim. Measure latency and failure behavior in the hospital’s own environment. Do not publish a number you have not measured there.

What must the integration carry?

The model is not the system of record. The electronic health record, or the triage module in front of it, is. The integration should pass a defined set of fields, not an unbounded export, and it should write back only what a person confirmed. Log the model version, the inputs it was allowed to see, the suggestion, and whether the clinician accepted, edited, or discarded it. That log is how the department later explains a record. It is also how you notice the tool drifting into busywork.

Identity has to be the clinician’s identity, tied to the same access rules as the chart. A service account that can see every patient is not an acceptable shortcut. Treat the interface like any other clinical integration: authentication, least privilege, validation, retries that do not duplicate a note, and an owner for failed messages. Those are the same controls you would expect from API integration work, reviewed under your software security practice.

How should you deliver it?

Do not change the live triage path on the first release. A practical sequence is:

• A written task, a clinical owner, and an IT owner. If either owner is missing, stop.
• Security and privacy review of the data elements, retention, and vendor access before any patient data is used.
• Shadow mode: the model runs, staff can look, and nothing is written into the official record.
• A limited pilot on one site, with confirmation required, and a way to turn the feature off without a code change.
• An operating review of overrides, timeouts, and extra clicks. Use what you observe. Do not set a fake target rate in the project plan.

Regulatory status, validation evidence, and what the vendor will support after go-live belong in the contract. “AI-enabled triage” on a slide is not evidence. The hospital should be able to name the intended use, the human step, and the fallback in one page.

How Hexagon applies this

Hexagon IT Solutions designs and builds the software around a model: interfaces to clinical systems, role-based access, audit history, and a release path that can run in shadow mode first. We do not replace clinical judgment, and we do not select an acuity score for a patient. If you are deciding whether a compact assistive workflow fits the department you have, map the current arrival steps in a digital transformation review before you fund a model. The useful outcome is a bounded system with a named owner and a downtime path.

Key takeaways

• Compact triage AI is a bounded assistive task with a clinician confirming the result, not an unattended disposition.
• Choose placement, inputs, write-back, audit, and fallback before you debate model size.
• Ship shadow mode first, and keep the existing triage process working when the model is down.