.svg)
.svg)
.svg)
.svg)
The technology that reads every chart, so no diagnosis is missed.
Ingestion, ontology, diagnosis, authoring. Four systems turn a hospital's raw EHR data into clinical assessments a physician can check line by line.
Fetch
Pull patient data from Epic, Cerner, and any FHIR server.
Normalize
Resolve codes and clinical text to one canonical vocabulary.
Diagnose
Reason across the whole stay, deterministically and traceably.
Author
Clinicians build the diagnostic logic in a visual builder.
The pipeline that loads clinical data reliably & securely, at scale.
Intaker is Regard's ingestion layer: a continuously-running service that pulls a patient's clinical history from any major EMR and turns unstructured notes, PDFs, and reports into structured, standardized data our platform can reason over.
- 01
Broad EMR coverage
Native support for Epic and Cerner, the two dominant vendors covering the large majority of U.S. hospital systems, plus generic FHIR servers. Each integration absorbs that vendor's own authentication, pagination, and API behaviour, so the rest of the platform never has to know which EMR it is reading.
- 02
Clinical NLP built for scale
Document parsing runs in-process, not as a separate service. HTML, PDF, and free-text notes become structured concept mentions carrying sentiment, subject, and temporality, so "no history of CHF" and "admitted with CHF" are never confused.
- 03
EMR-aware, not generic
Fetch plans are written per vendor and reflect years of integration experience, from Epic's multi-year lookback windows to Cerner's grouping of documents by clinical category. Codes and free-text mentions all resolve to the same canonical concepts regardless.
- 04
Repeatable onboarding
Each hospital is described in per-customer YAML, synced into the running environment by a dedicated tool. Adding a health system is a configuration change on a paved path, not a custom build.
- Queued
- Planned
- Fetching
- Merged
- Mapped
- Stored
One language. Every hospital, every code system, every note.
The Clinical Concept Library (CCL) is Regard's ontology: a graph of hundreds of thousands of medical concepts, each with one canonical entry linked to every code and synonym the outside world uses for it. Mapping resolves raw EHR data into that vocabulary - so a LOINC code from one hospital, a proprietary code from another, and a phrase in a note all land on the same concept.
Hover or tab through a concept to see the codes that resolve to it and how it connects.
- 01
Built on standards, extended by design
SNOMED, LOINC, RxNorm, ICD-10/11, plus each hospital's proprietary code systems. Roughly 30 in all, every one of them pointing back to a single canonical entry.
- 02
A graph, not a flat list
Typed relationships join a drug to its class, a lab to what it measures, a condition to its complications. So a rule can reason across the ontology instead of looking up one code at a time.
- 03
Maintained without a release
Regard's clinical team adds concepts, codes, and synonyms through a management UI. New codes reach production as data, not as a deployment.
- 04
Every source, one destination
Coded values resolve by code system and code. Free-text mentions match on synonyms. Because the per-hospital knowledge lives in the library, onboarding a site is mostly a matter of extending it.
A diagnostic engine that reasons over time, and can always show its work.
DXL (Diagnostic Expression Language) is the core of Regard's product. Each condition is a tree of composable blocks. Sources, checks, aggregations, decision tables, and formulas assemble into a dependency graph, evaluated over a patient's timeline. Results are deterministic and traceable back to the exact labs and note excerpts that produced them.
| 100 – 149 | Mild | |
| 50 – 99 | Moderate | |
| < 50 | Severe | 38 ✓ |
Each result stays valid until the next one supersedes it, so the rule evaluates a continuous series of segments rather than four isolated points. Before the first result there is nothing to evaluate, so the rule returns unknown across that interval, not false.
- 01
Composable, not black-box
Every condition is a tree of typed blocks a clinician can read and audit. Sources, checks, aggregations, decision tables, formulas.
- 02
Reasons over time, not snapshots
Patient data is a series of segments, each valid over an interval. A rule can ask for the lowest glucose in 24 hours, or whether a finding held true across the whole stay.
- 03
True, false, or unknown
Results distinguish a ruled-out condition from one the data can't judge, a distinction that most rule engines collapse and clinicians can't afford to lose.
- 04
Deterministic & explainable
Every segment carries the concept IDs and source records behind it, so any assessment traces back to specific labs and note excerpts. The same inputs always produce the same output. No sampling, no drift between runs.
Where clinicians build the diagnostic logic.
Nexus is Regard's authoring environment for DXL. Clinicians assemble rules from typed blocks, review each version, and publish. An AI assistant drafts rules from a plain-language description, constrained to CCL concepts so it cannot invent a code that does not exist.
- 01
Visual, block-based authoring
Clinicians build DXL rules by dragging typed blocks. No code required, no engineering involvement.
- 02
Versioned & auditable
Each rule is a versioned definition: drafted, reviewed, published. Only published versions reach users; every prior version is archived.
- 03
AI assistant, constrained to reality
Drafts DXL from a plain-language description, but is constrained to CCL concepts, so it cannot invent a code that doesn't exist.
- 04
Medicine as data
Because the medical knowledge lives in the CCL and DXL rules, a new hospital is supported mostly through data changes, not new code.
Thrombocytopenia · Adult inpatient
Built to the audit standard healthcare demands.
Regard's technology stack is designed for the reliability, traceability, and compliance expectations of hospital customers and their regulators. Every fetch, every mapping, every diagnosis is accounted for.
- 01
Full auditability
Every FHIR API call and every patient load is logged with outcome, timing, and request identifiers, for both debugging and regulatory traceability.
- 02
Resilience by design
Failed fetches are automatically retried on the next load cycle. Graceful shutdown ensures in-flight patient loads finish cleanly. No partial data left behind.
- 03
Change-aware persistence
Data is hashed and compared on write, so only records that have actually changed are updated. Storage and processing costs scale with real clinical activity.
- 04
Off-peak scheduling
Background refresh work is deliberately staggered into a low-traffic overnight window, smoothing load on our infrastructure and on hospitals' FHIR servers.
See how Regard reads a chart.
Bring a de-identified case. We will run it end to end and show you every step the assessment came from.
