01
Pharma RWE and HEOR teams
Research-ready data for observational studies and evidence programs.
Healthcare / Real World Data
Real world data platform development
EHR, claims and registry data were collected for care and payment, not for research. Agnotic Technologies builds the platform that turns them into research-ready real world data, with de-identification, linkage, OMOP mapping and a record of where every value came from.
Sources
EHR, claims and registry data in one pipeline
OMOP
One model, standard vocabularies
Provenance
Every value traced to its source
Trusted by global innovators
Industry Overview
What is a real world data platform?
A real world data platform is the system that turns EHR, claims and registry data into research-ready real world data: it ingests each source, de-identifies it, links records with privacy-preserving tokens, maps them to the OMOP common data model, checks quality and records provenance. Agnotic Technologies builds these platforms for pharma companies, data partners and research networks.
Industry Challenges
Why do real world data projects stall before the first study?
The common blockers, most of which are about process rather than technology.
A source arrives without a data dictionary, so mapping starts with guesswork.
De-identification was done once by hand and cannot be repeated on the next refresh.
Each data partner uses a different linkage token, so the same patient cannot be followed across sources.
The OMOP mapping drops source values, and researchers cannot see what a concept was built from.
Quality checks run only after a researcher finds a problem.
Nobody recorded which data release a finished study used.
Access is granted to the whole warehouse instead of to the data a project was approved for.
De-identification
Safe Harbor or expert determination: which route fits the data?
HIPAA offers two de-identification methods. The choice changes what the platform keeps, especially dates and geography, which longitudinal research often needs. Your privacy officer or counsel makes the decision; we build the pipeline for either.
| Question | Safe Harbor (45 CFR 164.514(b)(2)) | Expert determination (45 CFR 164.514(b)(1)) |
|---|---|---|
| What is removed | The listed identifiers, including names, geography smaller than a State (with a limited three-digit ZIP exception) and all elements of dates except year | Whatever the expert's analysis requires; dates and geography may be shifted or generalized instead of removed |
| Who decides | The covered entity, which must also have no actual knowledge that the remaining data could identify someone | A qualified expert, who documents the methods and results |
| Fit for longitudinal research | Limited, because dates are cut to the year | Often better, because intervals between events can be kept |
| What the platform builds | Rule-based removal that runs on every refresh, with tests | The transformations the expert specifies, re-run and re-checked on every refresh |
Our Approach
How should a sponsor or data partner approach the build?
Three principles that keep the data usable for research and defensible later.
Keep the source, the map and the output
Raw source data, the mapping rules and the OMOP output are all kept, so any value can be traced back to the record it came from.
Make de-identification a pipeline step
De-identification and tokenization run automatically on every refresh, with tests, instead of as a one-off manual job.
Version every release
Each data release has a version, and every study records the version it used, so results can be reproduced.
Capabilities
What do we build into a real world data platform?
Components we build on your cloud, sized to your sources and studies.
Source connectors
FHIR Bulk Data exports from EHRs, claims files and registry extracts, each landed unchanged.
Profiling and data dictionary
Field-level profiles of every source, so mapping starts from facts.
De-identification pipeline
Safe Harbor rules or the expert's specified transformations, run on every refresh.
Tokenization and linkage
Linkage tokens created where identifiers are allowed to be, and records matched across sources.
OMOP CDM transform
Source codes mapped to OMOP standard concepts, with source values kept.
Data quality checks
Completeness, conformance and plausibility checks run before each release.
Provenance and release versioning
Every release versioned, with lineage from source file to OMOP table.
Governed research workspace
Project-level access to approved data, with analysis tools and logged exports.
How It Works
What does the reference architecture look like, and who owns each step?
The platform we build, step by step, with the owner of each step. Clear ownership is what makes the data defensible when a study is reviewed.
1. Source ingest
EHR data through FHIR Bulk Data export, claims files and registry extracts land in a raw zone per source, unchanged. Owner: the data partner supplies the data; Agnotic builds and runs the connectors.
01
1
2. Tokenization
Identifiers are turned into linkage tokens inside the environment of the party allowed to hold them. Owner: the data partner or its tokenization provider.
02
2
3. De-identification
Safe Harbor rules or the expert's specified transformations are applied, and identifiers are removed. Owner: the privacy officer or the qualified expert signs off the method.
03
3
4. OMOP CDM transform
Records are mapped to OMOP tables and standard concepts, keeping source values. Owner: Agnotic data engineering with your clinical informatics lead.
04
4
5. Data quality checks
Checks run on every release, and failures block publication. Owner: your data quality lead.
05
5
6. Release and provenance
The release is versioned, with lineage from source file to table. Owner: the platform owner.
06
6
7. Governed research workspace
Approved projects get access to the data they were approved for, and exports are logged. Owner: your research governance board.
07
7
Engineering Stack
Which standards and tools does the platform use?
Open standards first, so the data and the code outlive any one vendor.
Ingest
HL7 FHIR R4 Bulk Data export (NDJSON)Claims extracts, including X12 837 and 835 dataRegistry files
Data model
OMOP Common Data ModelOHDSI standardized vocabulariesSource-to-concept maps
Quality and analysis
Automated data quality checksOHDSI tools such as ATLASR and Python
Platform
Cloud data warehouseSpark or SQL pipelinesRole-based access and audit logsAWS or Azure in your account
Measured Impact
What should a real world data platform report?
Measures published with every data release.
Mapping
Concept coverage
Share of source codes mapped to standard concepts, by domain.
Quality
Checks passed
Quality checks passed and failed for the release.
Refresh
Data lag
Time from a source update to a published release.
Lineage
Traceable values
Tables with lineage back to source files.
My Lauren Maternal Health Platform | Built by Agnotic
A HIPAA-ready maternal health platform enabling remote patient monitoring, care coordination, and personalized engagement from pre-pregnancy through postpartum.
Case Study
LERA Health: Women's Health App Platform
A women’s health product experience focused on guided care journeys, education, and compliance-aware workflows to support long-term engagement.
Case Study
Use Cases
Who builds a real world data platform with us?
Organizations that hold or use real world data for research.
02
Health systems sharing data for research
EHR data prepared for research partners under data use agreements.
03
Research networks
Several sites mapped to one model so the same analysis runs everywhere.
04
Disease registries
Registry data linked to EHR and claims with privacy-preserving tokens.
05
Data partners
Licensable data sets with documented provenance and quality.
06
CROs running observational studies
Study data sets built from versioned releases.
Integrations
Which systems feed the platform?
Sources and tools on both ends of the pipeline.
FHIR Bulk Data
EHRs, including Epic and Oracle Health (Cerner)
Medical and pharmacy claims
Claims sources
Disease and product registries
Registries
Privacy-preserving linkage
Tokenization service
ATLAS, R and Python
Research tools
External controls and feasibility
Trial systems
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, and strict access controls.
General Data Protection Regulation
Implement lawful consent flows, data minimization, and secure processing for global data privacy.
Fast Healthcare Interoperability Resources
Enabling standardized health data exchange through standards-based API mappings.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we cut setup work so your first release reaches users sooner.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How does a real world data platform engagement work?
We start with one source and one research question. Timing depends on scope; we agree a fixed first release on the scoping call.
01
Scoping call
We review your sources, data agreements, research questions and privacy approach.
02
Source assessment
Profile the first source and agree the de-identification route with your privacy lead.
03
First source end to end
Ingest, de-identification, OMOP mapping, quality checks and a versioned release for one source.
04
More sources and linkage
Additional sources added and linked with tokens.
05
Operate
Scheduled refreshes, releases and workspace support.
Facts and sources
Which rules and standards shape real world data platforms?
Short facts we design the pipeline, privacy and data model around, each linked to its primary source.
FDA defines real-world data as data relating to patient health status or the delivery of health care routinely collected from a variety of sources, such as electronic health records, medical claims, product or disease registries and digital health technologies.
Source: FDA, Real-World EvidenceUnder the HIPAA expert determination method, a qualified expert must determine that the risk is very small that an anticipated recipient could identify an individual, and must document the methods and results of the analysis.
Source: 45 CFR 164.514(b)(1) (eCFR)HIPAA lets a covered entity keep a re-identification code for de-identified data only if the code is not derived from or related to information about the individual and the mechanism for re-identification is not disclosed.
Source: 45 CFR 164.514(c) (eCFR)The OHDSI standardized vocabularies are a central component of the OMOP Common Data Model, standardizing medical terms across clinical domains so the same analytics can run across data sources.
Source: OHDSI, OMOP Common Data ModelThe HL7 FHIR Bulk Data Access implementation guide (v3.0.0) defines an asynchronous export of data for all patients, a defined group of patients or a whole server, and requires servers to support Newline Delimited JSON output.
Source: HL7, FHIR Bulk Data Access, Export operation
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
Related services
Related data and research software
This page covers building the real world data platform. These pages cover the trial, analytics and privacy work around it.
Clinical trial management software
Trial operations and real-world evidence pipelines into trials.
Life sciences software development
Software for sponsors, CROs and research teams.
Healthcare data analytics
Analytics and dashboards on clinical and operational data.
PHI data security
Tokenization, de-identification and protection of patient data.
Data engineering services
Pipelines, warehouses and data platforms.
CRO clinical trial analytics
Risk-based monitoring analytics across studies.
More in Healthcare
More Healthcare Solutions
Explore other production-grade engineering platforms we deliver across healthcare.
Cross-Industry Reach
The Same Engineering Patterns, Across Other Industries
The technical patterns behind this platform translate naturally into adjacent verticals.
Frequently Asked Questions
Usually both, for different jobs. FHIR, and its Bulk Data export, is a good way to get data out of EHRs. OMOP is built for research, with standard vocabularies that let the same analysis run across sources. The platform ingests FHIR and publishes OMOP.
Yes. Tokens are created where identifiers are allowed to be, and only tokens travel to the platform. Because such tokens are derived from identifiers, they are not a HIPAA re-identification code, so the token method is reviewed with your privacy expert or counsel.
Yes. Data use agreements, project approvals, access limits and export logs still apply, and linkage can raise re-identification risk. The research workspace enforces the project approvals your governance board grants.
Every release is versioned and keeps lineage from source file to OMOP table, along with the mapping rules and quality results. A study records the release it used, so its data set can be rebuilt and explained.
Yes. We connect to EHRs through FHIR Bulk Data where they support it and agreed extracts where they do not, and take claims and registry files in the formats your partners send.
It depends on the number of sources, the linkage approach and the review your privacy team needs. We agree a fixed first release on the scoping call, usually one source end to end, and give you a timeline for it.
Our engineers use AI coding assistants for drafts, tests and refactoring, and every change still goes through code review, automated tests and the same release checks as hand-written code. AI never makes a regulated decision in the delivered system unless that is the agreed design and a person reviews the output.
Industries