Skip to content
← BLUEHEALTHCARE
Infrastructure

The record beneath the overlay

Thirteen clinical modules compose a shared platform record — the foundation every overlay product runs on top of. This page describes the modules as they exist today.

What it is

A 13-module clinical platform that records care team interactions, observations, medications, orders, results, and service requests — with role-based access control, cryptographic audit logs, and a FHIR R4 API. The modules are:

  • core.record — the base record types (Patient, Observation, MedicationRequest, etc.) with FHIR mapping
  • core.terminology — coding system resolution (ICD, SNOMED, LOINC) plugged into the jurisdiction pack
  • build — the compiler that validates and assembles records at test time and at startup
  • bridge.ops — operational connectivity to external LIMS and records systems
  • admit — patient check-in and registration workflows
  • schedule — appointment and slot management
  • note — clinical note authoring and annotation
  • flow — order routing and task dispatch
  • result — lab and imaging result ingestion and display
  • order — lab and diagnostic order creation and tracking
  • meds — medication preparation, administration, and verification
  • accession — specimen accessioning and chain-of-custody
  • image — imaging order and report workflow (no image storage, no DICOM parsing, no viewer)
What it is not

A record system, not a decision system: it records what was done and by whom, and clinicians decide. It has not been through any certification programme, has never held real patient data, and refuses to start in a production posture until a clinic records its own go-live sign-off. It stores no images (imaging orders and reports only), does not yet connect to an e-prescribing network, and has no patient sign-in yet.

Follow a patient through the record

Six screens, one synthetic patient, one visit — registration through a critical lab result. Every screen below is a real capture of the running platform, not a mockup. From the second screen on, the same patient banner sits at the top: name, age, MRN, care team, bed, allergies — and, where something is not recorded or not visible to the signed-in role, the banner says so instead of showing a blank.

0

Library

Choose a reason for access before any record opens.

blueHealthcare launcher Library screen: a top banner stating that a signed receipt proves what the software ran and recorded and that a named human remains the only decision authority; an UNBOUND · DEMO badge; a Reason for access selector set to Treatment with the note Recorded with every record you open; the signed-in user; and one product card, Platform (Tier 1), marked Healthy with an Open button.
Synthetic demo data
Before any record opens, the user picks a reason for access, and it is recorded with every record they open in the session. Leave it unset and every panel refuses until it is chosen.
1

Registration & ADT

Search or register the patient, then admit, transfer, or discharge and assign a bed.

blueHealthcare platform Registration and ADT screen: a three-step strip — Find or register patient, Verify candidate, Choose encounter action and bed — above a Patient search panel (family name, given name, date of birth, MRN, Search and Register new patient), an ADT actions panel asking the user to search for, select or register a patient to admit, and a Bed board panel listing two medical-surgical beds.
Synthetic demo data
Three steps in order: find or register, verify the candidate match, choose the encounter action and bed. A patient is already in view for this session, and the screen still asks for a search or selection before any admission.
2

Schedule

Generate and fill appointment slots against the same patient record.

blueHealthcare platform Schedule screen: the patient banner for a synthetic 47-year-old — MRN, bed 301A, care team of a nurse and a physician, isolation Not documented in this view, coverage Restricted for your role, two allergy chips, and a read-only chip naming an external system of record — above a provider and resource grid for 15 September with four columns (an operating room, two family-medicine physicians and a nurse-visit resource), 20-minute rows with busy chips in one column, a Generate this week's slots button, and an empty Appointment panel inviting the user to select a slot.
Synthetic demo data
Four schedules for the day on one grid. A free slot books; a booked slot opens. The banner above is the same on every clinical screen from here on.
3

Chart review

The problem list, encounter history, and a signed progress note for the visit.

blueHealthcare platform Chart Review screen: problem list showing Acute kidney injury and Hyperkalemia, an encounter list, and a SOAP-format progress note, with the banner reading Not documented in this view for isolation and Restricted for your role for coverage.
Synthetic demo data
Problem list with onset dates, encounters by date and author, and the selected progress note in its Subjective, Objective and Assessment sections. What is not recorded reads Not documented in this view; what the signed-in role may not see reads Restricted for your role.
4

Orders

A catalogue and order-set composer with typed decision-support warnings.

blueHealthcare platform Orders screen: a Catalogue panel with a category filter and order search, an Order sets panel with green Viewing: safe and Actions: safe chips, and a Composer panel whose first line states it is decision support only, not a validated or regulated medical device, that never blocks, prescribes or acts on its own; the composer shows the patient identifier, no linked encounter, zero draft orders, a Signed orders section, and a cancellation-reason selector set to Ordered in error.
Synthetic demo data
Catalogue left, composer right. The composer states its own limit in its first line: decision support only; a clinician reviews every finding and decides. The Viewing: safe / Actions: safe chips report whether the panel is safe to read from and to act on — when it is not, they say Viewing: not safe or Actions: blocked. Cancelling a signed order requires a stated reason.
5

Flowsheets & vitals

Time-column vitals charting with a batch receipt per entry set.

blueHealthcare platform Flowsheets screen: a time-column grid of vitals (heart rate, respiratory rate, SpO2, temperature, blood pressure, pain) charted across an 8-hour shift, with only the latest column filled, six values each marked SAVED, and shift, 8h and 24h range buttons.
Synthetic demo data
Vitals on a time-column grid across the shift; one column saved so far. Each entry set commits with one batch receipt. Intake and output, GCS, Morse fall risk and Braden skin are further sheets in the same selector.
6

Critical result

A critical lab value surfaces with a closed-loop acknowledgement record.

blueHealthcare platform Results screen: an Unacknowledged critical results table with one row — Creatinine 10.4 mg/dL, flagged high, age just now, escalation deadline reading not determined — ack window not configured, assigned recipient Not assigned — above a results tree showing two final basic metabolic panels with Potassium 6.8 mmol/L and Creatinine 10.4 mg/dL both marked CRITICAL, and a detail panel giving the critical range, result time and the start of a five-result trend.
Synthetic demo data
A critical creatinine sits in the unacknowledged list until a named person acknowledges it, which records a closed-loop receipt. The deadline column reads not determined — ack window not configured: the platform will not invent a deadline the facility has not set.
Patient access — in development

What exists: A patient-facing module that verifies a signed patient identity before serving anything — signature checking, tamper detection and expiry are implemented and tested. This is the machinery that proves a request belongs to the patient it claims; it is not yet a way for a patient to sign in, which is the piece below. A patient can read only their own record. Two endpoints work today: a record summary and the patient's allergy list.

What v1 will add: Read-only access to results, problems, allergies, immunisations, procedures, and encounters. Patients will reach this through a patient portal sign-in (identity proofing and enrollment not yet built).

What is not built: Appointment requests, bill payment, and patient sign-in. These remain planned and are not available in the demo.

Current state

Synthetic data only. No live PHI has been processed. The platform runs in local demo mode with seeded, fixture-based records.

Care-team-scoped access control: Role-based authorization is enforced across all record types. Care-team-scoped access — restricting a user to records for patients on their own team — is enforced for all 15 record types the role matrix marks as care-team-scoped: Encounter, Observation, ServiceRequest, DiagnosticReport, MedicationRequest, Specimen, Patient, MedicationAdministration, DocumentReference, Condition, AllergyIntolerance, Procedure, Immunization, Communication, RelatedPerson.

Startup safety gate: Care-team access rules are enforced for all 15 record types. The platform still refuses to run on real patient data until the clinic records an explicit go-live sign-off — a named person and a time — and a clinic should not do that before the rest of the go-live checklist is done: e-prescribing and lab interfaces where needed, verified backups, a support contact, and a security review.

No production deployment exists yet. Everything described above is the local demo state.

The platform records care team decisions, not outcomes. A named human remains the only authority for every clinical assertion.