Health platforms, built where a software defect becomes a clinical one.
Consultation, prescription and pharmacy flows engineered around patient data and clinical safety from week one, because in this sector the failure modes are not inconvenient, they are harmful. Five health platforms already in production, and a custom engineering team for everything beyond them.
Custom build - 2 to 8 weeks, scoped
Ready-made platform - 6 working days
Six working days is the launch timeline for a ready-made platform as it ships - branded, deployed and live on infrastructure you own. Sector work beyond that, and the custom track above, is scoped and quoted in writing before anything starts. Both tracks are the same engineering team. Every figure on this page is defined on our facts page.
What a health platform build actually contains
The sequence below is where health platforms are won or lost. Every phase names what it requires and, where one exists, the shipped platform that removes it.
We build regulated healthcare platforms end to end, and we take responsibility for the platform meeting the standard your regime sets. That means the controls built in rather than bolted on, the documentation your assessment needs delivered with the build, and an architecture a clinician or a regulator can inspect without us in the room. Where clinical protocols need writing, we work alongside your clinicians to encode them properly rather than handing you a blank configuration screen.
Three of the seven phases have no shortcut. What a shipped platform removes is the middle: records and consent, the consultation workflow, and the pharmacy stack.
Regulatory scope and data classification
Which regime applies to you, in which markets, and what counts as patient data under each. The answers differ more than teams expect: a wellness application collecting the same measurements as a medical one may sit outside clinical regulation entirely, and the boundary is drawn by claims and intended use rather than by technology.
Data classification follows immediately, because it decides architecture. Which fields are health data, which are identifiers, which combination becomes identifiable, and what must not leave a jurisdiction. Once that is settled, minimization becomes possible: the safest patient data is the data you never collected.
The output is a written scope naming the regime, the data classes, the residency constraints and the claims you intend to make, because that last one determines whether you are building a medical device.
Identity, consent and the patient record
Identity in health is harder than in most sectors because the person receiving care is not always the person holding the account. Parents book for children, adult children manage care for parents, and carers act with varying authority. A platform with one account equals one patient will meet this in its first month and handle it badly.
Consent is a record, not a checkbox. What was consented to, in what version of the wording, at what time, and whether it has since been withdrawn are all facts a regulator may ask about, which means consent needs versioning and an audit trail like any other clinical fact.
The record itself should be append-only. Clinical history is not something that gets edited; corrections are additions that reference what they correct, because knowing what a clinician saw at the time is what makes a decision reviewable.
Consultation and clinical workflow
A consultation is a scheduled encounter that produces a clinical record, and the software around it has requirements a generic video call does not meet. The clinician needs history before the call, notes during it and a structured outcome afterwards, all attached to the right patient and attributable to the right practitioner.
Practitioner credentials belong here. Registration numbers verified against the relevant register, scope of practice recorded, and the jurisdiction a clinician is permitted to practise in - which matters enormously in remote care, where the patient and the clinician may be in different regulatory territories.
Escalation paths need designing rather than assuming. A platform handling a patient describing chest pain needs a defined route to urgent care, not a support ticket.
Pharmacy, prescription validity and controlled items
Dispensing turns a software platform into part of a supply chain with legal weight. A prescription has an issuer, a validity period, a refill count and a jurisdiction, and every one of those is a gate before fulfilment rather than a field to display.
Controlled substances carry stricter rules again: additional verification, quantity limits, and in many markets a register that must be reported to. These cannot be handled by the same path as general medicines with a flag set, because the obligations differ in kind rather than degree.
Clinical safety checks belong at this point. Interaction and allergy checking against the patient's recorded history is the control that catches the error a busy prescriber makes, and it needs a clinician-maintained data source rather than a list somebody assembled once.
Security, access control and the audit trail
Health data attracts attackers and regulators in equal measure, and both ask the same question: who could see this, and who did. Access must be role-based and relationship-based together, so that being a clinician is not sufficient - being this patient's clinician is.
The audit trail is a clinical artefact rather than an operational log. Every read of a patient record, not only every write, needs recording, because inappropriate access is the most common breach in health systems and it leaves no trace unless reads are logged.
We build to the framework your regime names, and the evidence trail comes with the platform: access logs, retention enforcement, control documentation and a VAPT report. Clients have taken our deployments through external assessment, and we support that process directly rather than leaving you to assemble the evidence afterwards.
Integrations with the systems that already exist
Health platforms rarely operate alone. Laboratories return results, hospital record systems hold history, insurers adjudicate claims and pharmacies confirm dispensing. Each integration has its own format, and the interoperability standards in this sector are genuinely standard in name more than in practice.
Result delivery deserves particular care. An abnormal laboratory result arriving into a platform where nobody is responsible for seeing it is a clinical risk created by software design, so results need an owner, an acknowledgement and an escalation clock.
Launch and day two
A supervised launch with a small patient cohort and clinicians who know they are first. Health platforms should not discover their edge cases at volume, and a clinical safety review of what actually happened in the first weeks is worth more than any amount of pre-launch testing.
Day two includes incident handling with a clinical dimension: something that would be a bug elsewhere may require notifying a regulator here, and knowing that in advance is part of the build. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.
Want any of these phases costed against your regime and clinical model?
Book a technical callWhere a prescription actually goes
Every health platform that dispenses is this sequence with different names on the boxes. The hops are easy. What separates a platform a regulator will accept from one that will not is the gates between them, and whether each one can be evidenced afterwards.
The out-of-jurisdiction clinician is the failure remote care creates and traditional care does not. A practitioner registered in one territory consulting a patient in another may be practising unlawfully, and the platform that routed them there is part of how it happened.
Why reads have to be audited, not just writes
Most systems log changes. In health that is not enough, because the characteristic breach is not somebody altering a record - it is somebody looking at one they had no business seeing. A staff member checking a neighbour's history, or a curious employee opening a public figure's file, changes nothing and leaves no trace in a system that only records writes.
Logging reads is more expensive and it is the control that makes inappropriate access detectable at all. Combined with relationship-based permissions - being this patient's clinician rather than merely being a clinician - it turns access from something granted broadly into something that has to be justified. Both are far easier to build at the start than to introduce into a system whose access model already assumes otherwise.
Want your access model and audit trail reviewed against your regime?
Talk to an engineerEight operators, eight different builds
"Health platform" is not one buyer. The regulatory exposure, the clinical risk and the data burden change completely between them.
Teleconsultation
Remote encounters producing clinical records, with jurisdiction rules that traditional practice never faced. Credential verification and escalation paths carry more weight than the video itself.
2 shipped platforms
Online pharmacy
Dispensing at distance. Prescription validity, controlled items and cold chain are legal gates rather than features, and the platform becomes part of a regulated supply chain.
3 shipped platforms
Diagnostics and lab booking
Sample collection, chain of custody and result delivery. Abnormal results need an owner and an escalation clock, because a result nobody is responsible for reading is a risk you created.
2 shipped platforms
Clinic and practice management
Scheduling, records and billing for the practice rather than the patient. The buyer is a clinic, the workflows are administrative, and interoperability is most of the work.
2 shipped platforms
Mental health and therapy
Longer relationships, notes of particular sensitivity, and risk protocols that must be designed with clinicians. Session records here carry a higher confidentiality expectation than general care.
Custom build
Chronic care and monitoring
Device data arriving continuously, thresholds that trigger review, and alarm design that avoids fatigue. Who watches the stream and when is a clinical staffing question the software must respect.
Custom build
Fitness and wellness
Often outside clinical regulation entirely, and the boundary is set by the claims you make. Staying the right side of it deliberately is cheaper than crossing it accidentally.
2 shipped platforms
Health insurance technology
Claims, adjudication and provider networks. The data is health data, the workflow is financial, and both sets of obligations apply at once.
Custom build
Five of the eight can start from something already running. Three are custom builds because nothing off the shelf carries the domain properly, and in this sector particularly we would rather say that than sell you an adaptation that fights you for two years.
Not sure which of these you are, or you sit across two of them?
Book a scoping callHow the work actually runs
Six stages, the same on both tracks. What changes between a custom build and a platform adaptation is how long stage three takes, not whether the other five happen.
Scoping against your regime and your claims
We start from which regulation applies, in which markets, and what you intend to claim your product does, because that last one decides whether you are building a wellness application or a medical device. Those three set the architecture before any preference does, and discovering them late means rebuilding rather than remediating.
Architecture, minimization and access
Data classification drives the design: what is collected, what is derived, what is never stored, and who can reach each class. Access is modelled as relationship rather than role alone, and read auditing is built in rather than added, because both are close to a rebuild once the model assumes otherwise.
Build against clinically-shaped data
Health platforms fail on the cases clinicians see weekly and test data rarely contains: a patient with a proxy carer, a prescription that expired between issue and fulfilment, an allergy recorded years earlier in free text, an abnormal result arriving out of hours. Test environments carry these from the start, because meeting them first in production is how harm occurs.
Length varies by trackSecurity validation and clinical safety review
Internal review against the mapped controls, external penetration testing, and remediation - plus a clinical safety review with a practitioner, which is the part software teams skip. Our platforms arrive with a VAPT and compliance document mapping the OWASP Top 10, so external review starts from a documented baseline.
Integration and practitioner onboarding
Laboratory, pharmacy and record-system connections proven with real data shapes, and practitioners onboarded with credentials verified against the relevant register. This stage depends on third parties and on professional bodies, and is the most common cause of a date moving.
Supervised launch and day two
A small patient cohort with clinicians who know they are first, followed by a review of what actually happened rather than what was expected to. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.
Want this sequence mapped against your regime and clinical workflow?
Book a technical callFive health platforms already in production
Every one ships with full source-code ownership, deployed on your infrastructure under your brand. Adapt one, or use it as the reference architecture for a custom build.
They fall into two groups, and which group you start from matters more than which name you recognise. Consultation platforms carry the patient record, practitioner credentials and the encounter workflow, which is where clinical attribution and jurisdiction rules live. Pharmacy platforms carry prescription validity, controlled-item handling and dispensing records, which makes them part of a regulated supply chain rather than a retail catalogue with medicines in it.
This sector has fewer shipped platforms than most on this site, and three of the eight operator types listed above genuinely need custom work. We would rather tell you that here than discover it in month four.
What this sector requires
Data minimization
The safest patient data is the data you never collected. Classification decides what is stored, what is derived on demand and what never enters the system at all, and it is an architectural decision rather than a policy one.
Relationship-based access
Being a clinician is not sufficient; being this patient's clinician is. Combined with logging reads rather than only writes, it is what makes inappropriate access detectable at all.
Consent as a record
Versioned, timestamped, attributable and withdrawable, with the wording that was actually agreed retained. A checkbox with no version history answers none of the questions that get asked.
Prescription gates
Issuer, validity, refills and jurisdiction checked before fulfilment rather than displayed alongside it, with controlled items on a separate path carrying their own registers and limits.
Owned results
Every abnormal result has a named owner, an acknowledgement and an escalation clock. A result arriving where nobody is responsible for seeing it is a clinical risk created by software design.
Append-only history
Corrections that reference what they correct rather than overwriting it, so what a clinician saw at the time remains knowable. This is what makes a decision reviewable afterwards.
Want to open any of these platforms and look inside before deciding?
See the live demosWhat we deliver for a regulated deployment
Compliance work in this sector is mostly evidence, and evidence is mostly engineering. This is what arrives with the platform rather than as a separate project afterwards.
The difference this makes is timing. A platform where evidence is generated continuously turns an assessment into an export; one where it is reconstructed afterwards turns it into a quarter of work. We build the first kind, and we stay with you through the assessment itself.
Want the compliance deliverables listed before you compare quotes?
Talk to an engineerBuilt custom when nothing off the shelf fits
The same team, working from zero. These are the capabilities we build into health platforms that no shipped product carries, because they are specific to how you operate.
Remote monitoring pipelines
Device data arriving continuously, with threshold rules, alarm design that avoids fatigue, and an explicit answer to who is watching the stream and when.
Data engineeringInteroperability layers
Connections to laboratory, record and claims systems whose standards are standard in name more than in practice, built as an integration layer rather than direct coupling.
API developmentTherapy and mental health workflows
Longer-term relationships, notes with heightened confidentiality, and risk protocols designed alongside clinicians rather than inferred from a generic case model.
Custom software developmentClaims and adjudication
Where health data meets financial workflow and both sets of obligations apply, with provider networks, coding and the audit trail an insurer will require.
Backend engineeringClinical decision support
Interaction, allergy and dosing checks against a clinician-maintained source, built so the software supports a decision rather than appearing to make one.
AI engineeringEvidence and audit automation
Access reviews, retention enforcement and control evidence generated continuously, so your own assessment becomes an export rather than a quarter of preparation.
Compliance engineeringNeed something this list does not cover?
Ask about custom workWhat we built, and what it delivered
Three deployments in this sector, described by what was actually built rather than by a metric we cannot show you the working for.
Teleconsultation
Remote consultation with jurisdiction rules
Practitioner registrations verified against the relevant register, consultations restricted by territory, and structured notes attributable to a named clinician.
Pharmacy
E-pharmacy with prescription gates
Validity, refill and jurisdiction checks before fulfilment, controlled items routed to a separate path with its own register, and interaction checking against recorded history.
Diagnostics
Lab booking with owned results
Sample chain of custody, abnormal results assigned to a named owner with an acknowledgement clock, and escalation when acknowledgement did not happen.
We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else's.
Want to speak to a reference operating in your model?
Request a referenceWritten on this sector
Longer pieces on the problems above, written by the engineers who build these platforms.
Why health platforms must audit reads, not just writes
PrescribingPrescription validity as a gate, not a field
ResultsEvery abnormal result needs an owner and a clock
ScopeWellness or medical device: the claims decide
If a question here is not covered, the fastest route to an answer is a call with the engineer who would run your build.
Want these as a briefing pack for your board or clinical governance group?
Request the packThree vendors told us their platform was compliant. None of them could explain what that meant for our registration, because it did not mean anything for it.
The failure pattern this page is built around
That gap is the whole reason this page exists. Forty client testimonials sit on the site with names, titles and companies attached, and none of them are invented.
Questions health buyers actually ask
The ones that come up in the first call, answered as we would answer them there.
Will your platform make us compliant?
Yes - we build to the regime you operate under and deliver the platform side of compliance with it: access control scoped by relationship, read and write auditing, encryption and key handling, consent capture, retention enforcement, prescription gating and a VAPT and compliance document. We support you through external assessment rather than handing over a build and leaving.
Do you build HIPAA and GDPR compliant platforms?
Yes. We build to the regime that applies to you, with the controls those frameworks require and the documentation an assessor asks for. Clients have taken our deployments through external assessment, and we support that process directly.
Can we really launch in six working days?
Yes, for a shipped consultation or pharmacy platform as it comes. It does not cover your own registration, practitioner recruitment or a clinical safety review, none of which a faster build compresses.
Do we own the source code?
Yes, in full, deployed on your infrastructure. That matters more here than elsewhere, because patient data on someone else's platform is a dependency you may not be permitted to hold.
How is patient data protected?
Through minimization first, then relationship-based access, encryption with described key handling, and audit logging that covers reads as well as writes. The last of those is what makes inappropriate access detectable.
Can a carer or parent manage someone else's care?
Yes, through proxy access with recorded authority and its own audit trail. A platform assuming one account equals one patient meets this problem in its first month.
How are prescriptions validated?
As gates before fulfilment: issuer, validity period, refill count and jurisdiction. Controlled items follow a separate path with additional verification, quantity limits and register reporting where required.
What about clinicians consulting across borders?
Handled as a rule rather than a hope. Practitioner registrations carry the territories they may practise in, and the platform will not route a consultation outside them.
Who is responsible when an abnormal result arrives?
A named owner, with acknowledgement tracked and escalation when it does not happen. A result delivered into a system where nobody is accountable for reading it is a risk the software created.
Do you integrate with existing hospital systems?
Yes, through an integration layer. The interoperability standards in this sector vary in practice, so we build to the systems you actually run rather than to the specification they claim to follow.
What does support look like after launch?
Sixty days of dedicated support, six months of priority bug resolution and twelve months of updates. In this sector we also agree in advance which incidents carry notification duties, because that is not a decision to make during one.
What if our clinical protocols are not written yet?
We write them with you. Encoding escalation paths, review criteria and disposition rules is part of the build rather than a prerequisite for it, and we work alongside your clinicians to get them right rather than waiting for a finished document.
Question not answered here?
Ask us directlyTell us what you are building.
Bring the regime and the clinical model. We will tell you honestly which track is right - including when the answer is that you do not need us yet.
A first call takes about thirty minutes and covers four things
Regime and markets
Which regulation applies to you, and where you intend to operate.
What you will claim
The claims decide whether this is wellness or a medical device.
Clinical model
Who consults, who prescribes, and who is accountable for a result.
Existing systems
The record, laboratory and pharmacy stack a platform must fit into.
Those four answers are usually enough for us to tell you which track fits, roughly what it costs, and what the compliance deliverables look like. Whatever the clinical model - consultation, pharmacy, diagnostics, monitoring or something none of those describe - we will build it, and we will build the compliance side with it.
