AI that supports clinicians,
and infrastructure that never
gets in their way
Healthcare has the least tolerance for a system that is confidently wrong and the most to gain from removing administrative load. Both facts shape every design decision we make in this sector.
Where healthcare technology teams are stuck
Administrative load nobody can hire their way out of
Referral intake, prior authorisation, coding and correspondence consume clinical and administrative hours at a rate that headcount cannot keep up with.
Data that exists but cannot be reached
Clinical information is spread across a PAS, an EMR, a pathology system and twenty years of scanned correspondence, with no safe path to a governed analytical copy.
Interoperability projects that never finish
HL7 v2 feeds held together by a decade of custom mappings, and a FHIR program that keeps being deprioritised because nothing visibly breaks without it.
What we build for healthcare organisations
Clinical safety and privacy are design inputs here, not a review gate at the end.
Clinical document intelligence
Referral triage, correspondence classification and coding support built on Amazon Bedrock — with citation enforcement, confidence thresholds and a human review queue for anything uncertain.
- Textract pre-processing for scanned material
- Groundedness and citation gates before release
- Clinician-in-the-loop by design
Clinical data platforms
A governed lakehouse with de-identification, consent-aware access and lineage — the foundation that makes analytics and AI possible without a new privacy review every time.
- De-identification and re-identification controls
- Consent and purpose-of-use enforcement
- Audit trail on every access
FHIR interoperability
Incremental migration from HL7 v2 point-to-point feeds to a FHIR facade, so integration work stops compounding and new systems connect in weeks instead of quarters.
- FHIR R4 resource modelling
- Terminology and code-system mapping
- Event-driven integration on EventBridge
Privacy and security uplift
Australian Privacy Principles applied to architecture, plus the security posture work needed before any patient data reaches a new platform.
- Data minimisation by design
- Breach-notification readiness
- Segmentation for clinical vs corporate workloads
The obligations that shape healthcare architecture
Clinical governance and privacy obligations are the reason healthcare designs look different from every other sector's.
Privacy Act & APPs
Health information is sensitive information. Collection, use, disclosure and cross-border rules drive the data architecture, not the other way round.
My Health Records Act
Strict controls on access, use and disclosure where the national record system is in scope.
Clinical safety
Risk assessment for any system that influences a clinical decision, with the human review boundary defined before build.
What healthcare clients ask first
No. We build on Amazon Bedrock, where your inputs and outputs are not used to train the underlying foundation models and are not shared with model providers. We document the full data flow for your privacy officer to review.
With an evaluation harness built alongside the system: a clinically reviewed golden dataset, groundedness and citation scoring, adversarial cases, and release gates that block deployment when any metric regresses.
Usually. We design around read-only integration and event feeds where write access is not available, and we will tell you early if a vendor limitation makes an outcome unachievable.
It is routed to a human, explicitly. Silent guessing on clinical content is not an acceptable failure mode, so low-confidence inputs are surfaced rather than processed.
Start where the administrative load is heaviest
Referral intake, correspondence, coding support. Those are the areas where a narrow, well-governed system pays for itself fastest — and where the risk is manageable.