Technical discovery field primer
Prepared for Precept Health / Aixelink · ICU Care + CLARA

Before an AI reads the chart, it must know what is true, for whom, and when.

Use this on the discovery call to move past “we have HL7.” The practical goal is a read-only, evidence-backed view where every fact resolves to a patient, encounter, source artifact, status, timestamp, and provenance trail.

Leave with these five answers.

Do not approve a production write path until this evidence chain has been demonstrated end to end.

01Who owns each clinical fact?
02Which patient + encounter IDs are stable?
03What states and timestamps are actually sent?
04Can original forms and reports be retrieved?
05How will every record be reconciled?

The system landscape is a chain of clinical ownership.

Hospital labels vary, and systems often overlap. What matters in discovery is which system is authoritative for each identity, order, result, document, and state transition.

Operational systems → integration boundary → AI retrieval view

Care & operations

HIS / EHR / EMRLongitudinal record, workflow, documentation, results
ADTRegistration, merge, movement, bed/ward, discharge
ICU / PDMSFlowsheets, assessments, I/O, device values

Departmental sources

LISOrders, specimens, analytes, verification and corrections
RIS / PACSImaging orders, studies, reports and images
PharmacyPrescribing, verification, dispensing, administration
Devices / gatewaysWaveforms, numerics, alarms, calibration identity

Controlled exchange

Interface engineRoutes, transforms, queues, retries and audits
Canonical clinical storeRaw payloads, parsed events, mappings and revisions
CLARA / ICU CareScoped retrieval with citation, audit and policy checks
Established fact

FHIR’s Encounter represents the care interaction and can cover an inpatient stay, movement, and discharge; local policy defines what counts as a distinct encounter.

Practical rule

Every AI retrieval should resolve to a stable hospital patient identifier and active encounter/visit identifier—not a name, MRN alone, a bed, or a vendor-generated patient key.

Standards are necessary. A local profile makes them real.

JSON does not establish clinical meaning, and an “HL7 feed” does not identify the fields, events, statuses, correction behavior, or acknowledgements a deployment actually supplies.

Delimited event messaging

HL7 v2

Still common for ADT, orders, results and departmental integration. Exact behavior comes from a versioned local interface profile, not the message name.

  • ADT^A01/A02/A03/A08: admit, transfer, discharge, demographic/update events
  • ORM / OML / OMG: general, laboratory and clinical orders
  • ORU^R01: results with PID, optional PV1, OBR, repeating OBX, optional NTE
  • ACK: commit/application acknowledgement; MSA-2 echoes MSH-10, ERR explains rejection
Resources + APIs

FHIR

A resource-based framework with REST APIs and messaging. JSON serialization does not guarantee completeness or semantics.

  • Patient, Encounter, Location, Practitioner, Organization
  • ServiceRequest: order; identifiers may distinguish placer/filler roles
  • Observation: atomic vital, lab, device measurement or score component
  • DiagnosticReport: report plus observations, order, specimen, images and narrative
  • Questionnaire / QuestionnaireResponse, Provenance, AuditEvent
Imaging + workflow profiles

DICOM & IHE

DICOM is for image objects, metadata and image exchange; DICOMweb adds web services. It is not merely a PDF or HL7 result. IHE profiles specify how standards work together.

  • Patient Care Device / IHE DEV: device-to-enterprise integration
  • ATNA: audit trail and node authentication
  • Laboratory workflow and XDS-style document sharing where deployed
Shared clinical meaning

Terminology

Use concepts and units explicitly.

  • LOINC: questions/observations, including labs, vitals, documents and instruments
  • SNOMED CT: findings, disorders, procedures and qualitative answers
  • ICD: reporting, statistics and reimbursement—not bedside semantics
  • UCUM: machine-interpretable units; preserve the received unit and normalize only with tested conversions
Discovery rule

Request actual de-identified messages and vendor conformance/profile documents. A feed called “ORU” may omit encounter, order, status, specimen, comments, or corrected-result behavior. Useful references: ORU structure, v2 acknowledgements, FHIR subscriptions, IHE Devices, LOINC, SNOMED CT, and WHO ICD.

Freshness needs a recovery path, not just a notification.

PatternStrengthMain risk / control
HL7 v2 event feedMature, low-latency operational eventsLocal optionality; duplicates/out-of-order messages. Use a durable queue and replay.
FHIR REST / APIQueryable, resource-oriented, selective retrievalPagination, rate limits, incomplete history and snapshots that miss changes.
FHIR subscription / webhookEvent notification over APIsA webhook alone does not guarantee delivery; retain cursor/history backfill.
Database extract / reporting replicaBroad historical accessStale or undocumented schemas; clinical workflow states can be bypassed.
CDC from database logNear-real-time replicationNeeds source approval plus schema/change governance; it is not a clinical contract.
Scheduled polling / exportSimple initial extractionFreshness gaps and missed corrections; use watermark, overlap and reconciliation.
HybridOften best: event feed + periodic backfill/auditMore moving parts; define one canonical identity and deduplication rule.
Recommendation

For CLARA, use a hybrid path: ADT plus results/forms/device events for freshness; a read-only FHIR/API or approved reporting extract for historical backfill and reconciliation; and a durable integration store retaining raw source payloads. This is a context-specific implementation inference, not a universal standard mandate.

A transport acknowledgement is not a clinical outcome.

For every flow, agree a contract that makes processing outcomes, revisions, and safe retries explicit.

The minimum data contract

Specify these fields before an interface is accepted.

AUTHORITYSource and destination system of record
PROFILEMessage/resource version and local profile
IDENTIFIERSPatient, encounter, orders, accession, form, device/channel
VERSIONImmutable event ID and source revision
TIMEEvent, observation, availability, validation, correction, receipt and ingestion timestamps
ORDERINGOut-of-order policy plus retry, duplicate and replay behavior
DISPOSITIONAccepted, rejected, deferred or clinically validated
RETENTIONAudit and data retention requirements
OWNERSHIPEscalation owner and reconciliation responsibility

Acknowledgements & idempotency

  • Deduplicate v2 by sender/facility + MSH-10, plus a durable business/event key—never solely patient/time/value.
  • Persist before acknowledging receipt where the receiver’s contract requires durable acceptance.
  • Monitor transport acceptance and application processing separately.
  • For FHIR writes, use conditional create/update or a business identifier and version-aware concurrency when supported.
  • Make writes safely repeatable: a timeout retry must not create a duplicate order, note, or medication administration.

Result lifecycle: do not collapse status into “available.”

At minimum, preserve these distinct states and their revisions.

01OrderedIntent exists
02Collected / performedClinical action happened
03PreliminaryProvisional visibility
04Verified / finalPolicy-defined clinical release
05Corrected / amendedRevision must remain visible
06Cancelled / errorNot a usable result
1 · CollectionSpecimen collection / performance
2 · ProductionAnalyzer or result production
3 · ValidationHuman review / technical validation
4 · FinalizationLaboratory release
5 · HISClinical availability in HIS
6 · CLARAIngestion / index availability
Lab-delay example

A result analytically available Monday but validated Thursday is not a “real-time HIS result” before Thursday. But storing only Thursday as the event time also creates a misleading disease timeline. Preserve both clinical and availability times.

Forms are clinical objects, not merely fields to flatten.

Rows such as GCS_total = 9 or SBAR_summary = “…” lose the assessment instance, instrument version, hierarchy, author, signature state, encounter, narrative and whether a score was machine-derived or clinician-confirmed.

Keep two linked layers

The durable clinical artifact and the computable representation serve different jobs.

Layer 1 · faithful clinical artifact

What the clinician completed

  • Questionnaire or local form definition: name, version, question IDs, options and grouping logic
  • QuestionnaireResponse: instance ID, subject, encounter, author/source, authored/completed/signed times, status, hierarchy, values, narrative and attachments
  • Rendered/original form or document reference when display/legal fidelity matters
Layer 2 · computable facts

What software can calculate

  • One Observation per measurement or a grouped panel
  • Codes, values, UCUM units, effective time/period, performer/device, method and status
  • Derived GCS total explicitly linked to components and source form—not an unexplained overwrite

FHIR explicitly separates capture through Questionnaire / QuestionnaireResponse from standardized observations, and requires preserving questionnaire hierarchy/order. For TPN, the signed order/document and its lifecycle remain authoritative; component facts can support calculations but are not an active order without their status and identifiers.

JSON is syntax. AI needs a semantic layer with evidence.

JSON can preserve fields, but it does not supply a stable concept, unit, encounter, source, validation state, time semantics, or a decision about authority.

Raw source payload (immutable, access controlled)
  → parsed canonical event (source IDs, delivery facts)
  → clinical model (Patient / Encounter / Order / Result / Form / Device)
  → terminology mapping (local code + standard code + mapping version)
  → AI retrieval views and derived features

Every AI-visible fact should point to source system + source object/message ID + source version + original timestamp(s) + transformation/mapping version + validation state.

Example retrieval contract
“Latest final potassium during this ICU encounter, as known at the clinical-time cutoff.”
Patient + encounterScope cannot drift to another stay.
Code + unitConcept and conversion are explicit.
Status + timeFinal, revision and cutoff rule are enforced.
Artifact contextReport, specimen, order and narrative remain reachable.
ProvenanceSource and transformation can be cited and audited.
  • Timeline retrieval: use patient/encounter scope, code/status/time filters and a clinical-time cutoff.
  • Artifact retrieval: return the full versioned SBAR, assessment or report—not only extracted fields.
  • Relationship traversal: Observation → DiagnosticReport → ServiceRequest → Specimen; QuestionnaireResponse → Encounter → author.
  • Tool calls: named, read-only functions with scope, filters, pagination and audit records.
  • Derived features: store as versioned derivatives; never overwrite source facts.

FHIR Provenance records the entities, agents and processes that created, revised or influenced a resource—useful for assessing authenticity and lifecycle state.

Start read-only, de-identified, and auditable.

  • Start with de-identified or synthetic data; use read-only service accounts for production discovery.
  • Apply least privilege by system, resource, patient/encounter scope, purpose, environment and time-bound credential.
  • Segment integration infrastructure from bedside/device networks; use authenticated encrypted transport, secret rotation, allow-lists and monitored identities.
  • Keep PHI out of application logs, prompts, support tickets, vector-store metadata and unbounded analytics exports.
  • Encrypt in transit and at rest; define retention, deletion, backup and incident procedures.
  • Audit reads, searches, exports, transformations, AI tool calls, writes and privilege changes. AuditEvent aligns with IHE ATNA/DICOM audit concepts.
  • Confirm Kuwait law, Ministry/hospital policy, data residency and cross-border processing with the hospital’s legal/privacy owner; do not assume a U.S. HIPAA model.

Reconcile records and their clinical context.

Build a test pack across ICU states: admission, transfer, discharge, duplicate/replay, merge, cancelled order, preliminary/final/corrected result, delayed validation, a complete SBAR, GCS components + total, a TPN order, and imaging result/image link.

CompletenessRequired fields present; source records represented; missing-context rate.
Clinical fidelityExact value, unit, code, status and timestamp match; form hierarchy and narrative preservation.
Freshnessp50/p95/p99 clinical availability → AI availability; separately collection, verification and ingestion latency.
Identity & contextUnique patient + encounter resolution; unmatched, ambiguous and late-ADT rate.
ReliabilityDuplicate suppression, replay recovery, error queue age, ACK/application-success mismatch.
TerminologyLocal-code coverage, mapping accuracy, unmapped/ambiguous rate and conversion exceptions.
ReconciliationCount and hash/source-ID comparisons: source → interface → canonical store → AI result; review every discrepancy.
AI safetyCutoff adherence, returned citations/provenance, and policy-correct handling of preliminary, corrected and other-encounter data.
Acceptance criterion

Sample every clinically important data type end to end, then reconcile both the record and its context—not merely row counts.

Common failures hide in the missing context.

  1. Patient matched by name/MRN but not encounter; values land in the wrong stay.
  2. ADT arrives late or moves/merges are ignored.
  3. Acknowledgement is treated as clinical persistence.
  4. Retries create duplicate orders or results.
  5. Values arrive but OBR, NTE, specimen, status, effective time, validation or correction is missing.
  6. “Latest” selects preliminary, corrected-old, or late-arriving data incorrectly.
  7. Unit, method, reference range or local test code changes silently.
  8. Device values are mistaken for clinician-validated assessments.
  9. Form values are extracted but question/version/author/signature/narrative is lost.
  10. Warehouse timestamps are treated as clinical event time.
  11. Free text is embedded without document identity, access control, retention or source citation.
  12. A production write is enabled before read-only reconciliation proves safety.

The 14-question discovery checklist.

These questions turn a vendor conversation into a concrete pilot contract.

What exactly is Saphire/Sapphire—legal vendor/product name, version, owner and hospital deployment—and can Del provide its official interface specification?

Which systems are authoritative for ADT, lab finalization, imaging reports/images, pharmacy/TPN, ICU charting, forms and device data?

Which transports exist today: HL7 v2/MLLP, FHIR version/endpoints, DICOM/DICOMweb, database/reporting replica, engine or APIs?

Can we receive de-identified examples and the local conformance/profile for every interface?

Which patient/encounter/order/accession/form/device identifiers are immutable, and how are aliases, merges and corrections handled?

For each data type, which timestamps mean observed, collected, performed, verified, released, received and modified?

What statuses are emitted, and how are preliminary, final, amended, cancelled and entered-in-error results represented?

Is human validation delayed? Which events are visible before versus after validation, and what should CLARA show?

How are SBAR, GCS and TPN stored: structured form, note, PDF, proprietary table, order or a mixture? Can the original artifact and signature state be retrieved?

Which device data are raw, sampled, alarmed, calculated, validated or manually charted? What is the sampling/aggregation policy?

What guarantees exist for ordering, delivery, ACKs, retries, replay, downtime backlog, message retention and error handling?

What writes are proposed, who owns reconciliation, and how will duplicate/correction safety be tested?

What security model, network boundary, data residency, retention, audit access and incident process are required?

What is the smallest safe read-only pilot cohort and objective acceptance threshold?

Vendor identity

No reliable primary-source evidence identifies a Kuwait HIS product named “Saphire” or “Sapphire” from the supplied information. Treat the name as ambiguous—perhaps a local spelling, hospital deployment name, reseller product, or non-HIS component—until Del provides a vendor contract, official interface document, or product/version screenshot. Do not design an integration around a guessed identity.

Glossary & a 60-minute learning path.

ADT
Admission, discharge and transfer events.
ACK
Technical acknowledgement of an HL7 message; not inherently proof of clinical processing.
CDC
Change-data capture from database transaction logs.
FHIR
HL7 standard organizing healthcare information into interoperable resources/APIs.
HIS / EHR / EMR
Hospital/enterprise clinical record platforms; usage varies by vendor and region.
Idempotency
Repeating the same request/event has the same outcome as processing it once.
LIS / RIS / PACS / PDMS
Laboratory / radiology / image archive / patient-data-management systems.
OBR / OBX
HL7 v2 report/order context / individual observation-result segment.
Provenance
Evidence of where data came from and how it was created or transformed.
UCUM
Standardized representation of units.
Watermark
Saved high-water mark used to resume polling/CDC safely.
0–10 min · Map the hospital
Draw data owners and the patient/encounter identity path from registration through ICU, lab, imaging, pharmacy and devices.
10–22 min · Read a real ORU
Identify MSH, PID, PV1, OBR, OBX, NTE, status, order IDs and every timestamp.
22–34 min · Compare FHIR
Inspect Observation, DiagnosticReport, Encounter, QuestionnaireResponse and Provenance.
34–43 min · Trace one delayed lab
Follow collection → analyzer → validation → HIS → CLARA; list each timestamp and state.
43–52 min · Trace one form
Preserve the SBAR/GCS form instance, then link extracted observations and any derived score back to it.
52–60 min · Agree the pilot contract
Set a read-only scope, data contract, representative test pack, reconciliation metrics, escalation owner and objective go/no-go criteria.