AnpherosAnpheros PlatformDevelopers

Healthcare software development

What is different about building medical software and how a healthcare application is layered: your product on top, the Anpheros API, the FHIR record and patient consent underneath.

Healthcare software is software that creates, stores or acts on information about people's health — patient apps, clinic tools, laboratory systems, remote-monitoring services, AI assistants. What sets it apart from other software is not the user interface but the data: it is sensitive, long-lived, standardised, shared between organisations and subject to consent. Anpheros is infrastructure for that data layer; this page explains the layers of a healthcare application and which of them Anpheros can provide.

The general architecture

Healthcare application        your product: UI, workflows, notifications, business rules
        ↓
Anpheros API                  REST v1 and FHIR R4, OAuth 2.1 / SMART on FHIR, webhooks, SDKs
        ↓
FHIR medical data             one HL7 FHIR R4 record per patient, versioned, with provenance
        ↓
Consent / authorisation       per-application grants chosen and revocable by the patient

Your application owns the experience; Anpheros owns the record and the rules around it.

What is different about building medical software

The data model is a standard, not a design choice

Other software can invent its schema. Medical software that invents its own schema cannot exchange data with labs, clinics or other applications without a translation project. Using HL7 FHIR R4 resources and standard codes (LOINC, ICD-10, ATC, UCUM) from the first line of code avoids that. FHIR platform

Every value needs a source

A glucose value typed by a patient, measured by a device, imported from a lab report or produced by an AI model means different things. Anpheros records the author type (patient, practitioner, device, import, AI), organisation and source system for every write, and keeps every version.

Access is decided by the patient, not only by the application

Beyond user login and roles, medical software needs consent: which application may read which part of which person's record, for how long, and an audit that the person can see. Consent and access model

Data must survive the application

Records are kept for years and move between providers. Separating the record (infrastructure) from the application means a redesign, a new app or a new partner does not require migrating medical data. Digital medical record infrastructure

Develop and test without real patients

Real medical data should not be in development environments. Anpheros has a sandbox — a separate database with synthetic patients — and sandbox keys that physically cannot reach production data.

AI needs the same rules as everyone else

An AI feature is another reader of the record. It should get only what the patient allowed, with sources, and its outputs should be labelled as AI-generated. AI healthcare applications

What you build and what Anpheros provides

Layer You build Anpheros provides
User experience screens, flows, notifications, clinical content —
Your users and accounts sign-up, login, roles in your product per-patient consent for data access; patient sign-in on the consent page
Medical data storage — FHIR R4 record, 26 resource types, history, documents
Coding choosing what to record standard code systems, bundled LOINC/ATC search
Access control to records which of your users sees which patient project isolation, pairwise ids, OAuth scopes
Audit — provenance on writes, access log visible to the patient
Integration your partners' specifics lab import, FHIR transactions, webhooks, SDKs
AI prompts, model choice, safety of your feature context API with token budgets and provenance labels
Compliance your regulatory obligations and clinical safety EU data residency, encryption of documents with a customer-managed key, a data processing agreement for production

Where to go next

Related