Who this is for
Healthcare data is some of the hardest data to get right. It arrives from EHRs, labs, claims, devices and research systems, in different formats and code systems, with strict privacy obligations attached. I work with health systems, digital health companies, life-sciences teams and research groups who need that data to be usable.
Common situations:
- Every new integration is a bespoke project, and the backlog keeps growing.
- Researchers spend months assembling cohorts that should take days.
- A clinical AI idea is blocked because nobody can vouch for the data underneath it.
- Security reviews stall every new use of patient data.
The problems I solve
Interoperability
I standardise exchange on HL7 FHIR, with adapters for legacy HL7 v2 feeds, so systems talk through one well-defined interface instead of dozens of point-to-point connections.
Consistent clinical meaning
Local codes are normalised to SNOMED CT, LOINC and RxNorm through a terminology service, so a diagnosis or a lab result means the same thing everywhere it is used. This is applied ontology work with a large head start.
Research-ready data
For analytics and real-world evidence I land data in the OMOP common data model and use OHDSI tools such as ATLAS for cohort definitions that are reproducible and shareable. I explain the full pipeline in FHIR to OMOP: a practical architecture.
Privacy and compliance
De-identification, consent management, encryption, fine-grained access control and audit trails are built in from the start, not added after a security review fails.
Clinical AI you can defend
Retrieval and agents grounded in clinical vocabularies and governed data, with provenance on every answer and human review where it matters. See my wider AI architecture approach.
My approach
- Inventory sources, codes and PHI flows. Know exactly what data exists, where it moves and who can see it.
- Design the target architecture. FHIR for exchange, a terminology service for meaning, OMOP for analytics, governance across every hop.
- Prove it on one source and one use case. A single feed through to a working cohort or dashboard.
- Scale source by source. With data quality checks and mapping reviews at each step.
- Layer AI on governed data. Only once provenance and access control are in place.
- Train the team and hand over. Mappings, pipelines and runbooks owned by your people.
What you get
| Area | Deliverable |
|---|---|
| Interoperability | FHIR APIs and integration patterns, including HL7 v2 adapters |
| Terminology | Mappings to SNOMED CT, LOINC, RxNorm and ICD-10 |
| Research platform | OMOP CDM pipelines and OHDSI tooling, containerised for repeatability |
| Privacy | De-identification, consent and audit design aligned with HIPAA |
| Infrastructure | Infrastructure as code on BAA-eligible cloud services |
| AI | Clinical AI patterns with provenance, guardrails and evaluation |
How an engagement runs
Most healthcare work starts with a two to four week architecture review covering sources, standards, privacy and the target platform. That leads into a build-and-hand-off project delivered one source and one use case at a time. Where the organisation needs ongoing technical leadership, I continue as a fractional CTO. If you operate in the Gulf, see my UAE practice, where residency and local data-protection rules apply as well.
The clinical interoperability case study shows a typical FHIR to OMOP engagement end to end.
Common pitfalls in healthcare data projects
Mapping too late
Teams often load raw data first and plan to standardise later. Later rarely comes, and every downstream report carries its own local interpretation of the codes. I bring vocabulary mapping into the pipeline from the first source.
One model for every purpose
FHIR is excellent for exchanging data about a patient right now. It is a poor shape for population-level research. OMOP is the reverse. Trying to force one standard to do both jobs leads to slow queries or brittle integrations. Using each where it fits avoids both.
Treating de-identification as a one-off
De-identification is a pipeline step, not a project. New sources, new fields and free-text notes keep introducing identifiers. I design it as a repeatable, tested stage with clear rules for what is removed, generalised or tokenised, and audit evidence for each run.
AI before provenance
A clinical model trained or grounded on data nobody can trace is a liability. Lineage from source record to answer is what lets clinicians, researchers and auditors trust the output. I put provenance in place before any AI goes near patient data.
Underestimating vocabulary maintenance
Standard vocabularies are updated regularly. Mappings that were right last year can drift. A small, scheduled process to refresh vocabularies and review unmapped codes keeps the platform honest.
Questions to ask before you start
- Which decisions should the platform support first: care coordination, quality reporting, research cohorts or AI?
- Which sources are in scope, and who owns each one?
- What consent and data-sharing agreements already exist, and what do they allow?
- Where must the data physically live, and which cloud services are covered by your agreements?
- Who will own mappings and data quality once the project ends?
Clear answers to these five questions save months. If some are open, the architecture review is where we settle them, with your clinical, legal and IT leads in the room.
Relevant experience
- Hands-on work with the OMOP common data model and the OHDSI stack, including ATLAS, WebAPI and the Broadsea containerised deployment.
- Co-author of peer-reviewed research published in Science Immunology.
- Production RAG and agent systems built with LangChain and LangGraph, with evaluation and guardrails.
- Multi-cloud infrastructure as code with Terraform across AWS, Azure and GCP, and Kubernetes platforms.