Healthcare Services

Yes — we build systems designed to meet HIPAA Security Rule requirements: role-based access control, encryption of PHI at rest and in transit, audit logging, session management and secure disposal. To be precise about what that means: HIPAA compliance is a property of your organisation and its operating procedures, not a certificate a development vendor holds. We build the technical safeguards and produce the documentation your compliance team needs; the programme itself remains yours, and we will sign a BAA where the engagement requires it.

HL7 v2 messaging (ADT, ORM, ORU), FHIR R4 REST APIs, DICOM for imaging, X12 837 and 835 for claims and remittance, and code systems including ICD-10, SNOMED CT, LOINC and RxNorm. In most projects the difficult part is not the specification but the variation: two hospitals running the same EHR will send you subtly different message shapes, so we build parsing that tolerates that rather than assuming a clean feed.

Usually yes, though the honest answer depends on what your vendor exposes. Epic, Cerner, Athenahealth and Allscripts all offer FHIR APIs of varying completeness, and most have an app-registration process with its own timeline that is worth starting early. Where no modern API exists we work with HL7 interface engines or flat-file exchange. We will tell you in discovery if a required data element simply is not reachable, rather than discovering it mid-build.

Developers work against synthetic or de-identified datasets. Production PHI stays in production, access is limited to named individuals with a business reason, and every access is logged. Where a defect can only be reproduced with real data, that happens in your environment under your controls with your team present — not by copying a database to a workstation. This is one of the areas where we will not be flexible, because it is where most breaches in this sector originate.

That is the common arrangement. Engineers join your sprints, your repository and your review process as an extension of the team you already have, rather than working in a separate silo and integrating at the end. You interview each engineer before committing, and there is a one-week trial so fit is proven on your codebase instead of on a CV.

Usually within one to two weeks for common requirements. Healthcare-specific roles — FHIR integration, clinical data modelling, medical imaging — can take longer to staff because the pool is genuinely smaller, and we would rather say two weeks and place the right engineer than fill the seat immediately with someone learning on your project.

You own all of it on payment: source code, infrastructure configuration, architecture documentation and any compliance artefacts we produced. Repositories and cloud accounts should be in your organisation's name from day one, not ours. A handover period with your engineers is built into the closing sprints, so nothing about running or extending the system depends on us still being involved.

Yes, and it is a large part of this work. The usual pattern is incremental: put an API layer in front of the existing system, move functionality outward piece by piece, and keep both running in parallel until the old path carries no traffic. A full rewrite with a single cut-over date is rarely the right choice for a system clinicians depend on daily, and we will say so if that is what is being proposed.