Move fast is fine. Break things is not

Compliance belongs to the organisation operating the system, not to a codebase or a vendor. What we do is build software that supports your obligations under HIPAA, GDPR or the local equivalent, encryption, access control, audit logging, minimum-necessary access, retention and breach detection, and sign a BAA where the engagement calls for one. Any agency telling you its code is "HIPAA certified" is describing something that does not exist.

Usually. FHIR APIs where the vendor exposes them, HL7 v2 interfaces where they do not, and an integration engine in between when the mapping gets ugly. The technical work is rarely the constraint, vendor access, interface fees and scheduling are, so we plan around those explicitly and start them in week one.

Ambient documentation, intake and history summarisation, coding and billing support, prior-authorisation paperwork, and administrative triage, each with a clinician reviewing before anything is committed. Autonomous diagnosis or treatment recommendation is a regulated medical device question rather than a software project one, and we say so at the first meeting rather than the last.

We do not develop against production patient data. Synthetic and de-identified datasets for build and test, restricted and logged access where real data is genuinely unavoidable, and environments separated so a development mistake cannot reach a live record.

On the build itself, close to it. What is genuinely slower is the front and the back, the data and access design at the start, and the staged, validated rollout at the end. Anyone quoting you consumer-app timelines for a clinical system has not priced those two parts.