Life sciences data platforms
We build and migrate data platforms for life sciences and healthcare: HIPAA aligned AWS 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 projects run on AWS, and where the data has to stay inside the building, we deploy the platform on premises.
The data
Genomic data can reach hundreds of gigabytes for a sample and terabytes for a study. A single whole slide image can be several gigabytes.
Protected health information, GxP records, and clinical study data bring requirements for encryption, access, audit trails, and retention. We account for those requirements in the architecture.
Some hospital networks are closed to the internet by policy. Research environments can have residency requirements, and some instruments were never designed to talk to anything outside the lab. That shapes the deployment, and some of the older interfaces take more work to connect.
Wherever the platform runs, the security, audit and retention requirements are the same.
AWS, a data centre or a closed network
In each case the pipeline code is unchanged and the infrastructure underneath it is swapped.
Managed cloud
Traffic, stored data, backups and logs are encrypted, and access is limited to the users and services that need it. Network segmentation keeps the public tier away from the database. PHI stays inside the services covered by the business associate agreement.
On an oncology EHR project, the source data arrived through a scheduled SFTP export, and Lambda started the pipeline as each file landed in S3. The parsers handled ten HL7 v2 message types, two CCDA variants and flat report exports before the data was loaded into PostgreSQL. The raw exports stay in S3, so each row can be traced to its source file.
Some systems still send HL7 v2 while newer applications use FHIR R4. We also work with Epic. For a patient app at a clinic running a structured weight management programme, we integrated with Epic using approved API contracts, token authentication and scoped access. Failed syncs generated alerts for the care team before data reached the record.
On a Veeva Vault migration for a biotechnology company running clinical studies, more than 10,000 documents came from AODocs. We translated the metadata field by field and ran 200 representative documents first, then checked SHA and MD5 hashes after the load. The study teams continued working during the migration.
We built the AWS environment for a multisite hospital network around HIPAA requirements. Each facility moved on its own schedule while the legacy systems stayed in place.
Migration work
On the oncology pipeline, the master patient index was built before the ETL and every loader used it, so patient identity was consistent before any record reached the database.
The source and target systems on the Vault migration modelled documents differently, so each field was mapped to the target model, reviewed with the client's quality and regulatory teams, and tested on a trial set before the full run. An error found in 200 documents is an afternoon's work. The same error found in 10,000 means another migration run.
A live healthcare system cannot simply stop for a migration. The old and new systems run in parallel while the data is synchronised, and integrations are tested against the new environment before the old one is taken out of service, with a rollback path kept ready.
Eight people from software engineering and DevOps built the oncology pipeline, identity layer, and database. We tested the path from source to row and handed over the code, documentation, and test results as work for hire. The delivery was fixed fee against four written acceptance criteria.
For one migration, we designed the target environment and ran the cutover. The existing system stayed in service while the new environment and its integrations were tested.
The client's stakeholders take part in the trial and migration. We hand over the logs, reports, and integrity records with the work.
For an on premises deployment, we containerise the platform, replace the managed services, and remove outbound dependencies. The cloud and local deployments retain the core features.
Clients and projects
We work with healthcare data companies, hospital networks, biotechnology companies and research organisations, on clinical data platforms, cloud migrations, regulated content moves and deployments inside closed networks.
We do not name clients on this site. Selected engagements are described on the case studies page without identifying details.
On premises platforms
Cloud platforms deployed inside the client's own environment, including sites with no external connectivity.
AWS environments for HIPAA workloads
Encryption, access control, network segmentation and business associate coverage for PHI on AWS.
HL7 and FHIR integration
Interfaces between clinical systems over HL7 v2 for legacy feeds and FHIR R4 for newer ones.
EHR connections
Connections to the EHR the clinical team already uses, including Epic.
LIMS engineering
LIMS development, maintenance, integrations, and workflow changes.
Questions
Which cloud do you build on?
Most of our work is on AWS. The oncology pipeline uses S3, Lambda, and PostgreSQL, and the hospital network migration used a HIPAA compliant AWS environment. Where data cannot leave the client's network, the platform runs on premises.
Can you make a cloud platform run on premises or air gapped?
Yes. A genomics visualisation platform now runs at sites with no external connectivity. Keycloak handles identity inside the cluster and a local object store takes the place of S3, startup sequencing and health checks were changed for the local network, and there are no outbound calls. The client sets up new sites from the runbooks.
Do you work with HL7 v2 or FHIR?
Both. We use FHIR R4 for newer systems, HL7 v2 for legacy feeds, CCDA where clinical summaries are exchanged, and Epic's FHIR APIs where the health system uses Epic.
How do you migrate without downtime?
On the multisite hospital network, the old and new systems ran in parallel with data synchronised between them, and the integrations were tested against the new environment while the old system stayed in service. No site lost service during the move.
How do you prove a regulated migration did not lose anything?
Every document is hash checked against its source after load, and failed loads are corrected and uploaded again. The client receives the logs, migration reports, and integrity records. The Vault migration covered more than 10,000 documents without loss.
Do you build LIMS or only support them?
We build purpose built LIMS when a commercial system does not fit the lab process. We support LIMS already in production and make changes for new workflows, sample types, and instruments.
Data platform projects
Tell us about the platform you have and what needs to change.
Start a conversation