Software engineering for health systems.
Patient-facing platforms, clinical workflow tools and health-data systems — engineered around what the domain demands.
- Discovery on site
- Architecture and data protection design
- Build in slices
- Parallel run and validation
- Operate and extend
Obligations most industries never face.
Health software carries obligations most industries never face: patient safety, clinical accuracy, and data whose breach is a life event, not a news cycle. A dropped message in retail is a lost basket. A dropped message between a laboratory system and a ward is a result nobody acts on. We build in this domain with the seriousness it demands — privacy by architecture, auditability throughout, and clinicians in the design loop rather than in a review meeting at the end.
The technical shape of the problem is an estate, not an application. There is a hospital information system of record that predates the standards, an HL7 v2 feed that a contractor configured a decade ago, imaging on DICOM, a laboratory system with its own codes, a pharmacy module, a scheduling module, national reporting obligations, and — under all of it — a patient identity that four systems each believe they own. Nothing can be switched off, everything must reconcile, and the clinical day does not pause for a deployment window. The work is to put governed contracts over that estate and build the new surfaces against the contracts, not against the legacy schema.
How we work here: privacy and minimisation are architecture decisions taken before the first feature; every access to identifiable data is logged; consent, retention and purpose limitation are implemented as code and tested like code. We treat GDPR / KVKK as design inputs, we are headquartered in Türkiye, and the engineers who design a system can also operate it. Where a change touches a clinical pathway, it goes through a written clinical-safety review with your people before it ships.
Four places we do the work.
Each of these is a programme we staff end to end — discovery with clinicians and administrators, build in slices, and operation after go-live.
Patient platforms
Appointment, telehealth and engagement journeys built to reduce no-shows and administrative load. Booking that respects real clinic rules — slot types, resource constraints, preparation instructions, interpreter needs — rather than a generic calendar. Reminders, rescheduling and pre-visit questionnaires close the loop, and every message is written so a patient under stress can act on it. Delivered as web and mobile surfaces over the same governed API.
Clinical workflow
Tools for the people doing the caring — rostering, handover, referral and documentation flows built to give time back. We design these on the ward, timing the current steps before proposing new ones, because a workflow tool that adds extra clicks per patient is rejected regardless of its feature list. Offline tolerance, fast search, keyboard-first entry and safe defaults are requirements, not enhancements.
Health-data platforms
HL7 v2 and FHIR-based integration and governed analytics — research-ready data with privacy built in. Ingestion, terminology mapping (ICD-10, SNOMED CT, LOINC), identity resolution across source systems, and a modelled layer that operations, finance and research can each query without three versions of the truth. Built with our Data Engineering practice and streamed on Kafka where the feed has to be live.
Compliance engineering
KVKK / GDPR health-data regimes implemented as architecture: consent, minimisation, audit, retention. Special-category data is separated, pseudonymised where the use case allows it, and access is bound to a purpose and a role. The evidence an auditor asks for — who accessed what, under which basis, and when it was deleted — is a query against the system, not a reconstruction exercise. Reviewed alongside our Cybersecurity practice.
What we build, in detail.
The pathway is the product.
Patients do not experience features; they experience a pathway — referral, triage, appointment, visit, follow-up — and the software fails at the joins. A referral that arrives as a fax equivalent, a triage decision recorded in a mailbox, an appointment booked without the preparation instructions, a follow-up nobody owns. We model the pathway explicitly: each state has an owner, a service-level expectation and a visible queue, so an item that stalls is a fact on a dashboard rather than a complaint weeks later. The same model drives the patient-facing view, so the person waiting sees the same state the clinic sees.
- Every state has a named owner and a target time; breaches surface in the queue before the patient calls
- Patient-visible status derived from the same record the clinic works from — one truth, two audiences
- Cancellations, reschedules and did-not-attends fed back into slot planning instead of being logged and forgotten
- 01Referral
- 02Triage
- 03Appointment
- 04Visit
- 05Follow-up
Outpatient pathway state
One patient, many systems of record.
The hardest question in a hospital estate is not where the data lives but which system is allowed to be right. We answer it per domain and write it down: demographics from the HIS, results from the laboratory system, images from PACS, dispensing from pharmacy, and an identity service that resolves the same person across all of them. New products then read from an integration layer with versioned contracts, so a change in a legacy schema is absorbed in one place. Feeds are validated against the source before anything downstream depends on them, and every message is replayable — an outage becomes a backlog, not a gap in a record.
- HL7 v2 where the estate speaks it, FHIR R4 where it can, adapters where it predates both — the choice is per interface, not per programme
- Terminology mapping maintained as data with a review trail, so a coding change is a configuration release
- Dead-letter handling, replay and reconciliation reports on every feed, built the way our integration practice builds them
Consent and access as rules, not policy PDFs.
A data-protection policy that exists only as a document is a promise. We implement it as evaluated rules in the request path: who is asking, for which patient, under what basis, and for what purpose. Break-glass access is allowed — clinical reality demands it — but it is announced, recorded and reviewed rather than silently permitted. Retention is a scheduled job with evidence, consent withdrawal propagates to the analytics layer, and every rule change is versioned with an author. When the auditor asks what happened, the answer is a report over the access log.
- Purpose-bound access: the same clinician gets a different view in a care context and in a research context
- Break-glass with mandatory reason, immediate flag and a review queue with a deadline
- Consent state and retention schedules applied to the warehouse as well as the application — deletion that only reaches the front end is not deletion
Example rules. Yours are configured with you.
The same platform, read three ways.
An estate you can change without holding your breath.
The CIO’s problem is risk concentration: a small number of systems that cannot be touched, a vendor roadmap that does not match the clinical one, and an integration layer held together by individuals. We reduce that by putting contracts in front of the legacy, moving new capability onto a stack your team can hire for, and defining infrastructure as code with runbooks. Modernisation is done in slices behind a parallel run, not as a big-bang cutover.
- Contracts over the systems of record, so product teams stop coupling to legacy schemas
- Infrastructure as code, region-pinned, with rehearsed restore and failover
- Handover that assumes your team takes it: documentation, tests, and a joint on-call period
Queues that show where the day is going wrong.
Operations leads do not want a dashboard of averages; they want to know which referrals are about to breach and who owns them. Every workflow we build exposes its work as a queue with an owner, an age and an action — the same list the team already keeps in a spreadsheet, except it updates itself and cannot be forked. Escalation rules are configuration, so a policy change does not wait for a release.
- Ageing and breach-risk visible per item, not only in a weekly report
- Reassignment, escalation and cover arrangements handled in the tool, with the reason recorded
- Designed on the ward with the people who will use it, then piloted on one real service before it spreads
Research velocity without privacy debt.
The research office needs cohorts, and the data protection office needs certainty that a cohort cannot become a person. We build the governed middle: de-identified extracts produced by pipeline, access bound to an approved protocol with an expiry date, small-cell suppression applied before anything leaves, and lineage from every published figure back to the source event. The sanctioned path is built to be faster than the unsanctioned one, so there is less reason to copy anything to a laptop.
- Purpose-bound, time-limited access approved through a workflow with an audit record
- De-identification and small-cell suppression in the pipeline, not in a reviewer’s head
- Lineage from a published number back to the source message, walkable by an auditor
The systems a health estate actually runs.
HIS / EHR
Patient administration, encounters and documents over HL7 v2 messaging or FHIR R4 resources, with an anti-corruption layer so new products do not bind to the vendor schema.
Laboratory (LIS)
Orders out, results in, with LOINC mapping, unit normalisation and explicit handling of amended and cancelled results — a corrected result must overtake the original, never sit beside it.
Imaging (PACS / DICOM)
Study metadata and worklists through DICOM services, with viewers embedded by context launch rather than pixel data crossing application boundaries.
Pharmacy & e-prescription
Dispensing and medication lists reconciled against the clinical record, with allergy and interaction checks left in the clinical system that owns them.
National reporting & payer interfaces
Statutory submissions and reimbursement files generated from the modelled data layer, with reconciliation reports proving what was sent matched the source.
Identity & access
Role mapping that follows the clinical org structure rather than an IT convenience.
Telehealth & communications
Video, SMS and e-mail providers integrated behind our own journey layer, so the vendor is replaceable and the pathway record stays in your platform.
Analytics & BI
Modelled marts served to Power BI and notebooks from one governed warehouse, with the same definitions used by operations, finance and research.
What we hold ourselves to in this sector.
- Privacy by architecture — minimisation and pseudonymisation before features. We decide what identifiable data the system is allowed to hold before we design a screen, and the answer is usually less than the first draft assumed. Fields nobody can name a use for do not get stored.
- HL7 / FHIR interoperability with hospital estates. FHIR R4 resources where the estate supports them, HL7 v2 where it speaks that, and written adapters where it predates both — with conformance tested against the real feed, not the specification.
- Clinical-safety review in the design loop. Changes that touch a pathway are reviewed with clinical staff against a hazard log, and the mitigations become tests. A safety concern stops a release the way a failing build does.
- Retention and consent implemented as code, not policy PDFs. Consent state, purpose limitation and retention schedules are evaluated at request time and enforced in the warehouse as well as the application, with the evidence produced automatically.
- Every access to identifiable data is logged and reviewable. Who, what, when, under which basis — immutable, queryable and exported to your GRC tooling, including break-glass events with their stated reason.
- Degraded mode is designed, not improvised. Clinics run when the network does not. Read-only caches, printable fallbacks and a documented downtime procedure are part of the delivery, and they are rehearsed before go-live.
- Parallel run before cutover. A new system runs alongside the old one on real data until the differences are explained, and go-live is a decision made on evidence — the same approach we use on any legacy re-engineering programme.
- AI is assistive and traceable. Where models help — summarising, triaging, drafting — the output is reviewed by a clinician, the prompt and version are recorded, and the evaluation evidence exists before deployment.
How a health programme runs with us.
Discovery on site
We sit with clinicians, schedulers and the IT team, time the current pathway, and map the estate — which system owns which fact, which feeds exist, which are fiction. Output is a written problem statement, a hazard log and a slice plan, not a proposal deck.
Architecture and data protection design
Integration contracts, identity resolution, the data model, and the privacy design: what is stored, where, for how long, under which basis. Reviewed with your DPO and security team before code, so their requirements are inputs rather than late objections.
Build in slices
One pathway or one integration at a time, each shipped to a real environment and used by a pilot service. Feeds are validated against source, and every slice arrives with tests, monitoring and documentation. Clinical review runs alongside, not afterwards.
Parallel run and validation
The new system runs against the old on live data. Differences are investigated until each is explained, reconciliation reports are signed by the people accountable for them, and cutover happens when the evidence supports it.
Operate and extend
We can run what we build: on-call, monitoring, incident review, and a roadmap updated regularly, at a rhythm agreed with you. Handover to your team is planned from the start — joint on-call, documentation and pairing — because the goal is a system your team can run.
Frequently asked questions
Neighbouring sectors we work in.
Bring us a problem from your industry.
Describe what is going wrong today. An engineer reads it and replies in writing with a concrete path.