Digital health software that respects patients and clinicians.
Healthcare teams want technology that gives clinicians time back, and patients expect their data to be handled with care. We help digital health companies and providers build, integrate and review software, and apply AI first to the administrative load where the benefit is clear and the risk is manageable. Our AI-native engineers move quickly without cutting corners on privacy or clinical safety.
Not all healthcare AI carries the same risk
Where an AI feature sits on this spectrum shapes the regulation, evidence and oversight it needs. Classification depends on intended use and jurisdiction, so treat this as orientation, not a legal determination.
| Administrative AI | Clinician support | Diagnostic or treatment AI | |
|---|---|---|---|
| Examples | Scheduling, referral letters, billing codes | Note drafts, record summaries | Detecting disease, recommending treatment |
| Typical regulatory exposure | Privacy law, not device rules | Depends on claims and intended use | Often regulated as a medical device |
| Human oversight | Spot checks and escalation | Clinician reviews every output | Formal clinical validation |
| Evidence needed before launch | Accuracy and time saved | Clinical safety assessment | Clinical studies and a quality system |
| Where to start | Usually here | After admin wins are proven | With regulatory specialists involved |
Why healthtech software is harder than it looks
The first version of a digital health product is rarely the difficult part. The difficulty arrives when it has to work inside real care delivery: exchanging data with electronic health records that implement standards differently, fitting clinical workflows that have no spare minutes, and satisfying privacy rules that differ between countries and sometimes between types of health data.
Integration is where many timelines slip. HL7 FHIR has made modern interoperability far more achievable, but many systems still rely on older HL7 v2 messages, vendor-specific APIs or flat-file exports, and access often requires a formal partner programme with the EHR vendor. Planning for that early saves months.
Privacy obligations shape architecture from day one. Depending on where you operate, that may mean HIPAA and business associate agreements in the US, GDPR special category data rules in Europe, or PDPA and sector-specific guidance in Singapore. The practical result is the same: strict access controls, audit logs of who viewed what, careful choice of hosting regions and a clear view of every third party, including AI providers, that touches patient data.
AI that gives clinicians time back, done carefully
Administrative and documentation work consumes a large share of clinical time. These are the AI applications we would typically evaluate first, each with a human firmly in the loop.
Documentation drafts
Draft consultation notes from transcripts for the clinician to check and sign, never filed automatically.
Referral and letter writing
Assemble referral letters and discharge summaries from structured record data, with sources shown for verification.
Inbox and request triage
Sort patient messages and incoming documents by type and urgency, flagging anything clinical for prompt human attention.
Scheduling and no-shows
Predict likely no-shows and automate reminders and rebooking, reducing wasted appointment slots.
Coding and claims support
Suggest billing codes and catch missing information before claims are submitted, with coders confirming each one.
Patient question assistants
Answer logistical questions from approved content, with firm boundaries that route symptoms or clinical questions to staff.
A privacy checklist before any AI touches patient data
These questions come before model choice. Your privacy officer and legal advisers should confirm the obligations that apply to you.
Is there a signed data processing or business associate agreement with every AI provider?
Consumer AI tools and default API terms are rarely sufficient for health data.
Does the model need identifiable data at all?
Minimise what is sent. Note that removing names alone is not de-identification; rare conditions and dates can re-identify people.
Are prompts, transcripts and outputs stored, and for how long?
These records are health data too, with the same retention and access rules.
Can you show who accessed each record and why?
Audit logs should cover AI system access as well as human access.
Do patients know AI is involved?
Transparency in consent flows and privacy notices builds trust and is often required.
Has a clinician reviewed the failure modes?
Consider what happens when the AI is confidently wrong, and design the workflow so it is caught.
From idea to a safe first release
Write the intended use statement
One clear paragraph on what the software does and does not do. It drives regulatory classification, claims and design.
Map data flows and obligations
Every system, vendor and region patient data passes through, checked against the privacy rules where you operate.
Build with synthetic data
AI-native development runs on synthetic or de-identified datasets, so real patient data never enters coding tools.
Pilot in shadow mode
Clinicians compare AI output against their own work before it influences anything, and their feedback shapes the release.
Questions we often hear
Is AI software in healthcare regulated as a medical device?
It can be. Whether software counts as a medical device depends mainly on its intended use: software that diagnoses, predicts disease or recommends treatment is often regulated, while purely administrative tools usually are not. Rules differ between regulators, so get specialist regulatory advice before making clinical claims.
Is it safe to use large language models with patient data?
It can be, with the right contracts, architecture and oversight. That means providers who sign appropriate data processing agreements, minimising identifiable data in prompts, choosing suitable hosting regions or private deployments, and keeping clinicians accountable for outputs. Using consumer chatbots with patient records is not appropriate.
What is FHIR and does my healthtech product need it?
FHIR (Fast Healthcare Interoperability Resources) is a modern HL7 standard for exchanging health data through web APIs. If your product needs to read from or write to electronic health records, FHIR support is increasingly expected, although you may still need older HL7 v2 interfaces or vendor APIs for some systems.
How do AI-native development teams handle health data?
Responsibly run teams keep real patient data out of AI coding tools entirely, developing and testing against synthetic or properly de-identified data. AI agents speed up integration code, tests and documentation, while senior engineers review everything touching access control, encryption and data flows.
Can you make our product HIPAA or GDPR compliant?
We design and build software with the technical safeguards those regimes expect, such as access controls, encryption, audit logging and data minimisation, and help you document them. Compliance also depends on your policies, contracts and operations, so we work alongside your privacy and legal advisers rather than certifying compliance ourselves.
Related reading and tools
Tell us about your digital health product.
Share what you are building, who uses it and where patient data flows. We will reply within 24 hours with an honest view of the technical, privacy and AI considerations.
Working with companies globally · Response within 24 hours