Industries / Healthcare & life sciences
We engineer clinical and patient-facing systems: HL7 v2 and FHIR R4 interoperability, EHR and EMR integration, patient portals, scheduling, e-prescribing, teleconsultation, consent management and immutable audit trails — across HIPAA, UK and EU GDPR, and India's DPDP Act 2023 with ABDM alignment. This is our deepest vertical because we operate our own healthcare products, not just deliver projects.
At a glance
Why this vertical is different for us
What first-hand healthcare experience gives you
Three of our own products run in healthcare. HealHub has been live clinic management software since 2023, handling appointments, records, billing and clinic operations. Vedant answers patient calls as an AI receptionist. HealHub Nexus operates a verified doctor network. Being on call for patient-facing software changed our defaults more than any client engagement did.
Interoperability
Interoperability is where healthcare projects consume their contingency. The standards are real, the conformance is negotiable, and the gap between them is your integration budget.
What to ask before accepting a FHIR claim
FHIR R4 conformance is only meaningful with profile specifics. The base specification makes nearly every element optional and permits extensions, so two conformant servers can be mutually unusable. What matters is the profile — US Core, UK Core, IPS, ABDM — plus the resources supported, the search parameters implemented, the terminology bindings enforced, and whether write operations exist at all. Always ask for a CapabilityStatement.
| Dimension | HL7 v2.x | FHIR R4 |
|---|---|---|
| Where it dominates | Internal hospital messaging: ADT, ORM, ORU, SIU, DFT, MDM. Still the backbone of most live estates | App-facing and partner-facing APIs, patient access, national exchange programmes |
| Transport | MLLP over TCP, commonly across a site VPN. File drops and secure FTP still exist in the wild | HTTPS REST with JSON or XML, plus Subscriptions and Bulk Data via NDJSON export |
| Conformance reality | Z-segments and locally redefined fields are near-universal. Every interface is effectively bespoke | Profiles, extensions and optionality mean "supports FHIR" is not a compatibility statement |
| Identity handling | MRN in PID with assigning authority often ambiguous across departments | Patient.identifier with system URIs, which only helps when the systems are actually registered |
| Terminology | Local code tables mapped by hand, frequently undocumented | SNOMED CT, LOINC, ICD-10 bindings, though enforcement varies by server |
| Error semantics | ACK and NAK with limited detail. Reprocessing a rejected message often requires human interpretation | OperationOutcome with structured issues, which is genuinely better when implemented properly |
| Typical mapping effort | Two to six weeks per interface once a test feed exists, dominated by segment discovery | One to four weeks per resource group, dominated by profile and terminology reconciliation |
| Our default position | Keep v2 for internal event flow. Do not rip it out to look modern | Expose FHIR at the boundary for apps, partners and national rails. Translate internally |
We use an interface engine pattern with an anti-corruption layer: inbound v2 and FHIR both normalise to one internal model, and every transformation is versioned and replayable. When a hospital changes a Z-segment, one mapping changes and no clinical logic moves.
These go out in writing during discovery. The answers determine the estimate more than any feature discussion.
Regulation
How the three regimes compare for a build
All three demand the same engineering primitives — lawful basis or consent recorded per purpose, minimum necessary access, encryption, complete audit, retention enforcement and breach response — but they differ on consent mechanics, data residency, subject rights and who counts as a processor. We build one control framework and configure it per jurisdiction rather than forking the product.
| Design question | HIPAA and HITECH (US) | DPDP Act 2023 (India) | UK and EU GDPR |
|---|---|---|---|
| What the data is called | Protected health information held by covered entities and business associates | Personal data processed by a data fiduciary, with health data treated as sensitive in practice and under sectoral rules | Special-category personal data under Article 9 |
| Basis for processing | Permitted uses for treatment, payment and operations; authorisation needed beyond those | Consent-centric, with limited legitimate uses. Notice must be itemised and available in scheduled languages | A lawful basis under Article 6 plus a separate Article 9 condition, commonly healthcare provision or explicit consent |
| Consent mechanics we must build | Authorisation records with scope and expiry; accounting of disclosures | Granular, purpose-bound, withdrawable consent with a record per purpose, and Consent Manager interaction under ABDM | Freely given, specific, informed, unbundled, withdrawable, with proof of what was shown at the time |
| Data residency | No general localisation mandate. Contractual and state-law constraints apply | Transfers permitted except to restricted countries as notified; sectoral localisation may bite. We default to Indian regions for Indian patients | Transfers outside the UK or EEA need adequacy, an approved transfer mechanism and a transfer risk assessment |
| Subject rights to implement | Access, amendment, accounting of disclosures, restriction requests | Access, correction, erasure, grievance redressal, nomination | Access, rectification, erasure, restriction, portability, objection, plus rules on automated decisions |
| Breach notification shape | Individuals and HHS, with thresholds and timing rules; media notice above 500 individuals in a state | Notify the Data Protection Board and affected data principals as prescribed | 72 hours to the supervisory authority where notifiable; individuals when high risk |
| Retention posture | Driven by state medical record retention laws rather than HIPAA itself | Erase when the purpose is served, subject to legal retention | Storage limitation; retention justified per purpose and enforced automatically |
This is engineering context, not legal advice. Applicability depends on your entity, your role in the data flow and your markets. We implement the controls your compliance function confirms and record the assumptions in the design document where confirmation is outstanding.
India
What ABDM integration actually requires
ABDM, the Ayushman Bharat Digital Mission, is a federated architecture rather than a central database. Patients hold an ABHA identity, providers register as Health Information Providers, applications act as Health Information Users, and data moves only against a consent artefact issued through a Consent Manager. Most of the build effort is identity, registry and consent plumbing — not the FHIR payloads.
| Area | What applies | Engineering consequence |
|---|---|---|
| Patient identity | ABHA number and ABHA address under ABDM | Identity service that stores ABHA alongside local MRN, with a merge workflow and audit of every link and unlink |
| Consent | DPDP Act 2023 notice and consent, plus ABDM consent artefacts for data exchange | Consent as a first-class versioned entity with purpose, scope, expiry, revocation and the exact notice text shown |
| Data exchange | ABDM FHIR profiles for prescriptions, diagnostic reports, OP consultation and discharge summary | Profile-specific bundle builders with validation before transmission, not generic FHIR serialisation |
| Teleconsultation | Telemedicine practice guidelines for registered practitioners | Practitioner verification, consultation records, prescription generation with mandated fields, and no clinical advice from automation |
| Residency and grievance redressal | DPDP transfer rules, sectoral expectations, plus the DPDP grievance mechanism and nominated contacts | Indian cloud regions for Indian patient data by default, asserted in infrastructure code, and a tracked grievance workflow with response timers rather than an inbox |
Delivery
Each of these carries clinical or financial consequence when it misbehaves, which is why the design notes below are as much about failure modes as about features.
Front of house
Booking, rescheduling, reminders, intake forms and results access. The hard parts are slot modelling across clinicians, rooms and equipment, double-booking prevention under concurrency, and identity proofing that does not lock out legitimate patients.
Prescribing
Prescription capture with structured medication, dose and frequency, interaction and allergy checks where a licensed knowledge base is available, and pharmacy transmission. Free-text prescribing is what we design out.
Remote care
Video consultation with waiting rooms, consent capture, note taking, prescription issue and follow-up scheduling. Media quality on poor networks and clean session recovery matter more than feature count.
Records
Registration, encounters, orders, results, billing and claims. This is HealHub territory, and the lesson we carry into client work is that duplicate patient identity and billing-to-clinical drift cause more support load than anything else.
Governance
A dedicated consent service and an append-only audit store, shared by every application. Built once, centrally, because per-application consent logic diverges within a year and cannot then be reported on.
Data
Warehouses and research extracts with documented de-identification, small-cell suppression before publication, purpose-bound access with an approval workflow, and lineage from a published figure back to the source encounter.
Safety
Our position on clinical safety and device software
For UK deployments we support DCB0129 (manufacturer) and DCB0160 (deploying organisation) clinical safety cases: hazard log, clinical risk analysis, mitigations traced to controls, and safety closure evidence, authored with your Clinical Safety Officer. We are aware of IEC 62304 software lifecycle requirements and can work inside a manufacturer's quality system. We do not act as the manufacturer.
Device data
Reading data from a regulated device and storing, displaying or forwarding it is common, useful, and different from making a device. The distinction turns on intended purpose: if your software interprets the data to inform diagnosis or treatment, classification questions arise. If it transports, stores and displays it faithfully, usually they do not. We design deliberately on the safe side of that line and put the reasoning in the architecture decision record.
Answers
Both, and the first matters more. We build and operate our own healthcare products: HealHub, clinic management software live since 2023; Vedant, an AI receptionist that handles patient calls and bookings; and HealHub Nexus, a verified doctor network. That means we carry live responsibility for patient data, clinic uptime and clinical workflow, not only delivery milestones.
On its own, very little. FHIR R4 defines resources and an API style, but almost every field is optional and extensible. Real interoperability depends on the profile: US Core, UK Core, IPS, or an ABDM profile. Ask any vendor which profiles, which resources, which search parameters and which terminology bindings. If the answer is just "we support FHIR", assume mapping work is still ahead of you.
No. HL7 v2 still carries the majority of real-world clinical messaging in hospitals: ADT admissions and transfers, ORM and ORU orders and results, SIU scheduling, DFT billing. Most estates we work in are hybrid, with v2 handling internal event flow and FHIR exposed for apps and partners. Planning a v2-free architecture in 2026 is usually wishful.
HIPAA is sector-specific with prescriptive safeguards, business associate agreements and breach notification thresholds. GDPR treats health data as special category requiring an Article 9 condition plus a lawful basis, with strong data subject rights. India's DPDP Act 2023 is consent-centric with notice, consent manager concepts and significant-data-fiduciary duties. Architecturally the union is: granular consent records, purpose limitation, residency control, retention enforcement and complete audit.
Usually, but the honest constraint is access rather than engineering. What determines the timeline is whether your EHR vendor will grant a test instance and interface credentials, what their integration licensing costs, and whether the interface is a modern API or a v2 feed over a VPN. We ask for sandbox access in week one because provisioning commonly takes four to ten weeks.
No. We are not a medical device manufacturer, we do not hold an ISO 13485 quality management system, and we do not place software on the market as a device or certify it as one. Where a client is the manufacturer and their software falls in scope, we can work inside their quality system with IEC 62304 lifecycle awareness, but the regulatory ownership stays with them.
Practically: ABHA identity creation and linking, a Health Information Provider or Health Information User role with consent flows through the Consent Manager, HIP and HIU gateway registration, discovery and linking of care contexts, and FHIR-based data exchange against ABDM profiles. The identity and consent plumbing is more work than the data exchange itself.
Real patient data never leaves production. Lower environments run synthetic data generated to match the shape and volume of production, or de-identified extracts where a legitimate need is documented and approved. This is one of the few rules we will not negotiate, because the majority of healthcare data incidents we have reviewed involved a test system.
Three weeks, fixed fee. You get an integration inventory with vendor questions issued, a privacy control map for your jurisdictions, a patient identity assessment and a costed delivery plan. The output is yours whether or not we build it.