Health data and interoperability software that moves data safely
FHIR interoperability APIs, patient data hubs, consent management, pseudonymised data warehouses and population health dashboards. Built so data reaches the people allowed to see it, and no one else.
What health data and interoperability software has to get right
Health data is spread across EHRs, labs, payers and apps that each speak a slightly different dialect. Connecting them is slow because every partner varies, consent is often recorded on paper, and the same patient appears under several identities.
The builds below use one internal data model with tested mappings to FHIR and HL7 v2, consent that is enforced by the system rather than remembered by staff, and pseudonymisation before data is used for analytics or research.
Problems we are asked to fix
The problems teams bring to us, the system that fixes each one and the builds that did it.
FHIR interoperability platform
Connecting apps to EHRs over FHIR is slow and inconsistent.
One API layer with profiles validated against US Core, SMART authorisation and bulk export, so each partner connection follows the same pattern.
Health data warehouse
Clinical data sits in silos and cannot be analysed.
Data from many sources pseudonymised and loaded into one warehouse, with access for each use set by permit and logged.
Consent management platform
Patient consent is tracked on paper and not enforced in systems.
Consent captured once, versioned, and checked by every system before data is shared, used for research or used for contact.
Population health dashboard
Care teams cannot see risk across a population.
Risk cohorts and care gaps across a population, with drill-down to the patients who need action.
Patient data hub
Patient records are duplicated across systems.
A hub that receives HL7 v2 and FHIR, matches identities, and serves one record with security labels on sensitive data.
5 kinds of health data and interoperability system we have built
Each one links the product build behind it, counted from our case studies.
Health data and interoperability products we built
Headgate - FHIR Interoperability API Platform for Claims, Clinical Data and Prior Authorization
Designed and built a clickable console for the FHIR APIs a US regional health plan must run under federal interoperability rules: API health across Patient Access, Provider Directory, Formulary, Provider Access, Payer-to-Payer and Prior Authorization, a security review queue for third-party apps, and one clock for every prior authorization request, however it arrived.
Sutura - HIPAA-Compliant Patient Data Hub over HL7 and FHIR
Designed and built a clickable patient data hub for a US health system running Epic, Oracle Health, athenahealth and eClinicalWorks: a live monitor for every HL7 v2, FHIR and HIE feed, one matched enterprise patient with a provenance-tagged record, and a duplicates queue where a person decides every uncertain match.
Kaivo - Pseudonymised Health Data Warehouse for Leadership Analytics and Permitted Research
Designed and built a clickable data platform console for a bilingual Finnish wellbeing services county: nightly pipelines that pseudonymise patient, lab, imaging, social care and finance data, leadership dashboards built only from aggregates, and a research request desk that ties every project to its data permit.
Beiaard - Consent Management Platform for Health Data Sharing, Research and Communication
Designed and built a clickable consent platform for a four-campus Belgian hospital network: one record per patient for eHealth sharing, hub publication, research, biobank and newsletter consent, kept in step with the national eHealth record, with access log review for the DPO and a sync console for the hubs and the metahub.
Mandacaru - Population Health Dashboard with Risk Cohorts and Care Gaps
Designed and built a clickable population health platform, in Portuguese, for a Brazilian state health secretariat and its municipalities: primary care dashboards against performance goals, risk cohorts such as uncontrolled hypertension, identified patient lists for Family Health teams with every access recorded, and dengue surveillance alerts by municipality.
The rules involved
The rules this kind of software usually has to follow. Guidance, not legal advice.
- 01
Interoperability rules
In the US, ONC certification, CMS interoperability rules and the information blocking rules require FHIR access. Other countries run national FHIR programmes.
- 02
Health data protection
HIPAA and extra rules for sensitive records in the US, the GDPR in the EU, and national health data laws elsewhere.
- 03
Secondary use of data
Using health data for research or analytics often needs a permit or a legal basis of its own, and pseudonymisation first.
- 04
Consent
Who agreed to what, for which purpose, and for how long, recorded so it can be proven and enforced.
Framework guides
Rules our health data and interoperability builds cite most
- GDPR2
- HL7 FHIR R4 and US Core2
- 21st Century Cures Act (information blocking)1
- 42 CFR Part 21
- Access to Information Law (Lei 12.527/2011)1
- Belgian Data Protection Act 20181
- CARIN Blue Button1
- Client data logging (Finland)1
- CMS Conditions of Participation1
Two ways to work with OceanLab
Project build
We design and build the system as one project. It starts with a clickable prototype your team tries before any production code is written. Pay per milestone (outcome-based) or hourly at $30-50/hr, depending on role and seniority.
Embedded engineers
Our engineers join your team on a flexible monthly retainer. Part-time is fine and it runs month to month, with hours that overlap the US, UK and Europe, the Middle East, and Australia and Asia. Outcome-based or $30-50/hr.
Guides and tools
Health data and interoperability software questions
Do we need FHIR if our partners use HL7 v2?
Usually yes, both. Hospitals send most real-time events as HL7 v2, while apps, payers and regulators expect FHIR. We map both to one internal model so you are not maintaining two data models.
How do you handle patient matching?
With clear matching rules on identifiers and demographics, and a review queue for uncertain matches. Automatic merges only happen when the match is certain.
Can analytics run on live health data?
We keep analytics on a pseudonymised copy with its own access rules, so the live system is not exposed and each analysis can be traced to a permitted purpose.
