HL7 segments on the wire.
The capture shows message headers, patient identifiers and order segments: MSH, PID, ORC and OBR.
Hospital continuity / Sentinel on Continuum
The EMR goes dark.
The next patient arrives.
Sentinel is a clinical workspace designed to keep patient context and supported workflows available through an EMR outage. Continuum provides the distributed record foundation beneath it.
Walk through an outage Demonstrated with synthetic data · Pre-pilot
The continuity workflow
Before. During. After.
ILLUSTRATIVE SYSTEM VIEW01 / Connected
Primary system
Hospital EMR
Feed connected
Clinical events
Continuity workspace
Sentinel
Patient context available
Supported work
Patient census
Downtime orders
Review inbox
Outbound path connected
Signed records to the continuity layer
Record foundation
Continuum
Separate archives. Authorized reconstruction.
AShareBShareCShare
Capture context before an incident.
Sentinel ingests configured clinical feeds and maintains its own patient census. Signed records are published to Continuum as part of the continuity path.
This is an explanatory animation, not a live demo. It assumes Sentinel, its identity service and the required network paths remain available. A stopped feed cannot supply new clinical information.
HL7 v2 / From workflow to wire
Real messages.
A visible delivery path.
Sentinel ingests HL7 v2 feeds over MLLP, the transport used by hospital interfaces. Supported outbound messages queue while the receiving EMR is unavailable and replay when it returns.
Queued is a distinct state.
A message waiting locally has not yet been accepted by the destination. Delivery status needs to distinguish pending work, acknowledgments and failures.
Inspect the actual payload.
This capture shows what reached the mock receiver. The outage recordings separately demonstrate queueing and replay after a receiver restart.
See the earlier Sentinel message-status pane Historical interface capture
Two parts of the same problem
A place to keep working.
Records to work from.
Sentinel gives staff a patient census, a place to enter supported downtime orders and an inbox for exceptions. It keeps local state so the primary EMR can be unavailable while that workspace remains accessible.
Continuum gives hospitals a record foundation designed to span cloud providers and their own premises at the same time. Independent archive placement supports recovery through failures and opens a path to moving infrastructure gradually as vendor costs or requirements change. Applications build on the same records.
When the EMR returns, supported queued messages can be replayed. Failed mappings and rejected messages need review. The workflow and the recovery boundary are defined with each hospital.
The record foundation / Continuum
Keep records within reach.
Even as infrastructure changes.
Continuum is designed to span multiple clouds and on-premises systems at the same time. Records remain recoverable while enough independent archives are reachable and the access services are available. You choose the reconstruction threshold.
Plan for a provider to disappear.
Place archives across separate failure domains. With a k-of-n threshold, any k intact shares can reconstruct an already distributed record, so the loss of up to n minus k archives need not mean losing the record.
Move at your own pace.
The mesh is designed to accommodate new nodes and changing storage placement. That opens a path to gradual migration between providers and your own premises as costs and requirements change.
Build on the records you keep.
Sentinel, Prism and Pulse bring clinical workflows to this foundation. Folio applies it to documents and publishing, with a planned role as True North's archive.
One share cannot rebuild the record.
In this example, taking a single archive's stored share does not give an attacker enough material to reconstruct the record.
Reconstruction has its own gate.
The normal read path checks authorization before returning a record. Plaintext exists at reconstruction and in authorized applications.
Placement matters.
Separate providers and credentials reduce shared failure paths. The configured threshold determines how many archives can be lost.
Illustration of an already distributed record, not live infrastructure or a cryptographic simulation. The access gate shown is the service's read path: an attacker who obtains enough raw shares is a different threat. Availability also depends on the network, identity and reconstruction services.
Independent access / Artilect ID
Give staff a way
back to work.
When the hospital directory is unavailable or no longer trusted, the continuity workspace needs its own sign-in path. Artilect ID supports native credentials and multi-factor authentication for separately operated applications.
Prepare that access before an incident: enroll staff, verify their roles and rehearse sign-in without hospital federation or email. The aim is to get people working in Sentinel while the primary identity systems are recovered.
Built-in controls include tamper-evident audit records, encrypted signing keys and session policies. Configuration and the site's readiness drill determine which controls are active and which dependencies remain.
Explore the identity service ↗Operator visibility / The mirror console
Watch your records arrive.
Test the way back.
Authorize a machine you control to watch your hospital's record stream. The mirror console shows arrivals and periodically retrieves a sampled record through Continuum, making both activity and retrieval failures visible.
It gives the team responsible for recovery something concrete to inspect during normal operation. A quiet stream and a failed retrieval are different conditions; the console exposes the evidence behind its status.
The existing console observes the stream and tests sampled retrieval. A separate design extends this into a complete, locally encrypted copy that can be read without the network. That offline-read capability needs its own demonstration before it becomes a deployment promise.
The hospital stack
Continuity first.
A shared clinical record.
Sentinel supplies the event model that Prism and Pulse also use. Each application has a distinct job.
Sentinel / Clinical workspaceKeep the patient list
Keep the patient list
and the work in view.
Ingest clinical feeds, retain a census and queue supported orders while the receiving EMR is unavailable. Review what could not be mapped or accepted.
Read the engineering case study ↗
PrismDemo mesh
See hospital activity
across the event stream.
Census, length of stay and patient journeys, with the basis of each metric made visible.
Explore Prism ↗PulseDemo mesh
Bring screening into
a reviewed workflow.
Configurable screening protocols and care pathways, with human approval before an order is sent.
Explore Pulse ↗Prism and Pulse are demonstrated applications. Their screenshots use synthetic data and do not establish clinical outcomes. Artilect ID supplies shared sign-in; its availability is part of the continuity plan.
Proof of concept / Sentinel HL7 MCP
Ask in plain language.
Inspect the clinical event.
Experimental · Synthetic patients
Could an LLM operate a clinical workspace through a defined set of tools? This proof of concept explores admissions, transfers and discharges through the Model Context Protocol (MCP).
The chat client requests an action. The server checks the census and bed state, assigns identifiers, and renders the HL7 message into an append-only outbox. Ordinary requests that violate the placement rules are refused. A separate override requires the configured role and a recorded reason.
The client calls a defined tool.
Admission, transfer and discharge tools accept structured inputs. The demo supports a Claude engine and a fixed-grammar parser using the same MCP tools.
The server owns the state change.
Checks run against the current census and bed roster. The server assigns patient IDs, timestamps and message control IDs, then renders the HL7 segments.
Read what the next system receives.
The outbox exposes A01, A02 and A03 messages. A replay cursor rebuilds a downstream census from the message history for comparison with the live demo state.
A refused transfer leaves the census unchanged
Replay the messages and compare the census
Current scope. The screenshots show the public reference backend: its census is in memory and its configured outbox persists to disk. They demonstrate tool behavior and HL7 generation. The public demo does not forward messages to a hospital interface engine, and these captures do not establish an LLM's clinical reliability or a live Sentinel integration.
Explore the MCP repository ↗Project directory:sentinel-hl7-mcpEvidence & deployment
Built and demonstrated.
A hospital pilot comes next.
An outage, a queue, a replay.
Recorded Sentinel demos stop mock EMR receivers, show supported work queueing and verify message replay after restart. These runs use synthetic data and documented demo configurations.
A read needs enough shares.
The substrate demo exercises denied reads, insufficient archive availability and successful reconstruction. The interactive diagram above explains that mechanism.
Prove the hospital's actual downtime path.
Confirm feed coverage and freshness, independent access, supported clinical actions, recovery mapping and the drill's acceptance criteria before a pilot. Earlier recordings include configuration concessions that need to be reconciled with the current build.
For hospital IT & clinical operations
Bring your
downtime scenario.
Start with the systems that become unavailable, the information staff need and the workflows that must continue. We can discuss a scoped evaluation against that scenario.
Discuss the hospital stack ↗About the builder & the wider portfolio →