Life sciences data comes with practical constraints
We build and migrate data platforms for life sciences and healthcare organisations. That includes HIPAA aligned cloud environments, EHR and laboratory data pipelines, HL7 v2 and FHIR integrations, regulated content migrations, LIMS, and deployments inside networks with no route to the internet. Most of our work runs on AWS. When the data has to stay inside the building, we build the platform to run on premises.
Large. Regulated. And sometimes beyond the reach of the cloud.
Genomic datasets can run to hundreds of gigabytes per sample and terabytes per study. A single whole slide image can be several gigabytes.
Protected health information, GxP records and clinical study data each come with requirements around encryption, access, audit trails and retention. Those requirements shape the architecture from the outset.
Hospital networks closed to the internet by policy. Research environments with residency requirements. Labs with instruments that were never designed to communicate beyond the room.
A cloud architecture designed for a typical software company does not always fit these constraints. The work is adapting the platform without losing the underlying requirements.
When the data cannot leave, the platform has to come to it.
Pick an environment.
Managed services where they make sense
Encryption in transit and at rest, including backups and logs. Least privilege for users and services. Network segmentation keeps the public tier separate from the database. PHI is handled only by services covered by the business associate agreement.
From the systems that produce it into a form people can use. On an oncology EHR project, that meant a scheduled SFTP export, a Lambda that copied each file into S3 and started the run, a master patient index built before the parsers, extract and load code for ten message types across HL7 v2, two CCDA variants and flat report exports, and PostgreSQL at the end. Every raw export stays in S3, so each row can be traced back to its source file.
HL7 v2 feeds from legacy systems, FHIR R4 on the modern side, and Epic where the health system runs it. For a patient app used by a clinic running a structured weight management programme, we integrated with Epic against approved API contracts, with token authentication and scoped access. Reconciliation and alerts on failed syncs gave the care team a way to check the data before it reached the record. Most real deployments involve both standards.
Moving records between systems where the result has to withstand regulatory review. On a Veeva Vault migration for a biotechnology company running clinical studies, more than 10,000 documents moved from AODocs, with metadata translated field by field. We first ran a trial with 200 representative documents, then checked SHA and MD5 hashes on every file after load. Nothing was lost or altered, and the study teams kept working throughout.
HIPAA shaped the architecture from the beginning rather than becoming a review exercise at the end. We built a HIPAA compliant AWS environment for a multisite hospital network and moved each facility onto it on its own schedule, with its legacy systems in place and no downtime at cutover.
Migrations rarely fail because the files could not be copied. They fail on identity, metadata and cutover.
Identity comes first. On the oncology pipeline, the master patient index was built before the ETL and used by every loader, so the data had a consistent identity before it reached the database.
Metadata is usually where the work sits. On the Vault move, the two systems modelled documents very differently, so every field had to be mapped to something meaningful in the target system, agreed with the client's quality and regulatory teams, and proven on a trial set before the full run. A mapping bug found in 200 documents costs an afternoon. The same bug found in 10,000 costs a rerun.
Cutover has to be planned because a live healthcare system cannot simply stop. The migration runs in parallel, data is synchronised between old and new, integrations are tested against the new environment while the old one is still serving, and a rollback path is ready.
We build the pipeline, identity layer and database, test the path from source to row, and hand over the code, documentation and test results as work for hire. The oncology pipeline was a fixed fee delivery against four written acceptance criteria, delivered by a team of eight across software engineering and DevOps.
We design the target environment, plan the parallel run and cutover, and stay through the transition.
We plan it with the client's stakeholders, run the trial, run the migration, and deliver the logs, reports and integrity records needed for review.
We containerise it, replace the managed services, remove the outbound dependencies, and preserve feature parity so the team is not left supporting two products.
Who we work with
Healthcare data companies that need clinical data in usable form, hospital networks moving to the cloud without interrupting clinical operations, biotechnology companies moving regulated content out of general purpose document systems, and research organisations working inside closed networks.
We do not name clients on this site. Where an engagement can be described, it appears on the case studies page with identifying details removed.
Air gapped and on premises deployment
Running a cloud native platform where there is no cloud.
HIPAA compliant cloud architecture
What compliance actually requires of the design, not just the paperwork.
HL7 FHIR integration
The standard that lets a platform exchange data with the rest of healthcare.
Epic and EHR integration
Getting a platform into the record clinicians already work in, rather than beside it.
LIMS development and support
Building, maintaining, and customizing the system that tracks every sample in the lab.
Questions people ask
Which cloud do you build on?
Most of our work is on AWS. The oncology pipeline runs on S3, Lambda and PostgreSQL, and the hospital network migration was to a HIPAA compliant AWS environment. When the data cannot leave the client's network, we build the same platform to run on premises.
Can you make a cloud platform run on premises or air gapped?
Yes, and we have. A genomics visualisation platform now runs at sites with no external connectivity, at parity with the cloud version: Keycloak in the cluster in place of cloud identity, a local object store in place of S3, startup sequencing and health checks reworked for a local network, and no outbound calls left anywhere. The client deploys new sites from our runbooks.
Do you work with HL7 v2 or FHIR?
Both, and most deployments need both. FHIR R4 on the modern side, HL7 v2 feeds from the legacy systems around it, CCDA where clinical summaries are exchanged, and Epic's FHIR APIs where the health system runs Epic.
How do you migrate without downtime?
The migration runs in parallel with the old system. Data is synchronised between the two, integrations are tested against the new environment while the old one still serves, and the cutover is planned to the minute with a rollback path. That is how a multi site hospital network moved with no site losing service.
How do you prove a regulated migration did not lose anything?
Every document is hash checked against its source after load, load failures are re translated and re uploaded until the ledger is clean, and the client receives the logs, migration reports and integrity records. On the Vault migration that covered over 10,000 documents with zero loss.
Do you build LIMS or only support them?
Both. Both are in scope. A purpose built LIMS where commercial systems do not fit the lab process, support for one already in production including the change control a validated system needs, or changes for new workflows, sample types and instruments.
Have data that needs to move, become queryable, or stay inside its current environment and still be usable?
Tell us what it is, where it lives, and what it has to comply with.
Start a conversation