Patient journey, population, adherence and market analytics built on governed real-world data, with versioned cohorts, honest treatment of what the data cannot see, and a hard line between commercial insight and individual care.
A patient who disappears from your persistence curve may have discontinued therapy. They may also have moved to a pharmacy outside the data panel, changed payer, started paying cash, or been captured under a different token.
Longitudinal patient data is assembled from claims, pharmacy transactions, and other sources that capture a patient only when that patient interacts with a participating party. Coverage is partial, and it varies by payer, channel, geography and therapy area.
So the patient record is a trace, not a history. Gaps in it have at least four explanations, and the analysis usually assumes the clinical one.
Patient drop-off is read as discontinuation
When it is a data event until something establishes otherwise.
Cohort definitions were set once and never versioned
So last quarter’s number cannot be reproduced and nobody knows why it moved.
Diagnosis to treatment time measures recorded dates
Which are coded encounters and observed fills, not clinical decisions.
Adherence is reported as a fact rather than a computation
When the method choices move the answer more than the behaviour does.
De-identification is treated as a one-time switch
Rather than as a risk position that changes every time a source is linked.
A dispensing record is treated as medication taken
When it establishes supply and nothing beyond supply.
A diagnosis code is read as a confirmed diagnosis
When it may be a rule-out, a suspicion or a billing requirement.
Commercial and clinical uses are separated by policy alone
Which is the control most likely to fail when somebody is in a hurry.
Take one persistence curve and ask what the drop-off is made of. Pick a published persistence figure and ask the team to decompose the patients who left the curve: how many had an observed discontinuation, how many simply stopped appearing, and how many are known to have changed payer, channel or programme. In most organizations the second group is the largest and has never been separated from the first. Doing it once changes what the curve is allowed to claim, and usually changes the conclusion drawn from it.
Everything on this page is downstream of a cohort definition. Get that wrong, or leave it undocumented, and every figure built on it inherits the problem invisibly.
Step 1
Assess the decisions the analytics has to support
Step 2
Establish the permitted use of every dataset before design
Step 3
Integrate licensed and authorised sources with coverage recorded
Step 4
Harmonize across sources through privacy-preserving linkage
Step 5
Define patient cohorts explicitly, and version them
Step 6
Map treatment journeys against observable events only
Step 7
Segment populations on criteria your business has approved
Step 8
Analyze market dynamics with access and payer context included
Step 9
Identify care and treatment gaps at population level
Step 10
Model patient behaviour with the method stated on the output
Step 11
Validate against an independent source or a clinical reviewer
Step 12
Monitor cohort stability, coverage, freshness and model accuracy
Step 13
Improve continuously, with every published figure reproducible
Ask which cohort version produced your current patient population number. Take the patient population figure your organization is currently using in planning and ask for the cohort definition behind it, its version, its effective date and the data vintage it was computed on. If the answer is a description rather than a versioned artifact, the number cannot be reproduced and any movement in it cannot be explained. That is a half-day of work to establish and it determines whether the rest of the analytics can be trusted.
Grouped by the question each capability answers. Every one of them is cohort-based, and every output carries its observability and method caveats.
Market and population
Patient population analytics and population sizing, stated as an observable estimate with its basis
Epidemiology and disease prevalence analytics using governed sources and documented assumptions
Journey and treatment patterns
Patient journey mapping built on observable events, with unobserved periods marked as such
Diagnosis and treatment pattern analysis including pathway variation
Treatment initiation and discontinuation analytics, with discontinuation distinguished from disappearance
Behaviour and need
Adherence and persistence analytics with the computation method stated on the output
Unmet medical need identification at population level
Patient services and support programme analytics, in a separately governed environment
The third column is the point of the table. It states the main limit on each use case, because the limit is what determines whether the output is usable for the decision being made on it.
| Use case | What it answers | The main limit to state |
|---|---|---|
| Patient population sizing | How many patients the market plausibly contains | An observable estimate, projected, not a count |
| Diagnosis to treatment journey | How long the recorded path takes and where it stalls | Measures recorded dates, biased by setting |
| Treatment initiation barriers | What sits between a prescription and a first fill | Needs payer and access data or it misattributes |
| Patient drop-off analysis | Who leaves the pathway and at which step | Must separate discontinuation from loss of observability |
| Adherence and persistence | How supply behaviour trends over time | A computation, reportable only with its method |
| Therapy switching | What patients move to, from what, and after what | Switch direction is observable, the reason rarely is |
| Patient support programme analytics | How programme engagement relates to outcomes | Separately governed data, often identifiable |
| Market opportunity assessment | What share of the population is addressable | Addressable and realisable are different numbers |
| Launch planning | Where to concentrate before any sales history exists | Rests entirely on cohort and access assumptions |
| Patient-centric forecasting | How the population feeds a commercial forecast | Forecast method and limits sit on our Forecasting page |
On most platforms the design question is what the system enables. Here an equal part of it is what the system makes impossible, because the controls have to survive a hurried, well-intentioned user.
Licensed and authorised sources ingested with their permitted use, panel coverage, vintage and methodology version captured as metadata at intake
A linkage layer using the privacy-preserving method your privacy function approves, with no persistent re-identification pathway available to analysts
A cohort layer where definitions are versioned artifacts with effective dates, not queries written inside reports
A metric layer holding journey, adherence, persistence and funnel computations, each carrying its method version
A structural distinction between three kinds of evidence, because a recorded prescription, a calculated treatment gap and a modelled discontinuation probability are not the same claim and should never render identically
A delivery layer applying minimum population rules, suppression and permitted-use restrictions at query time, including on export
Licensed longitudinal patient data, de-identified claims and prescription datasets
Electronic health record data where appropriately authorised, under the basis your privacy function determines
Specialty pharmacy data and patient services platform data, separately governed
Payer and market access datasets, plus HCP and HCO master data from the commercial estate
Licensed healthcare data providers including IQVIA and equivalents
Platforms: Microsoft Fabric, Azure Data Lake, Databricks, Snowflake, AWS
Pipelines and modelling: ETL and ELT orchestration, privacy-preserving linkage, AI and machine learning
Delivery: Power BI and enterprise analytics integration
Test whether a small-cell result can be produced at all. Ask an analyst to run a legitimate query that would return a very small patient count in a narrow geography, and watch what the platform does. If it returns the number and relies on the analyst to suppress it, the control is a convention, and it will be defeated by somebody competent and busy. If the platform refuses to generate it, the architecture is doing its job. Ten minutes, and it tells you more than a policy review will.
Which privacy frameworks apply to a given dataset and activity, how that dataset is classified, which de-identification method governs it, and what uses are permitted, are all determined by your legal, privacy and compliance functions. We do not interpret those frameworks and this page does not state which apply to you.
What follows is the set of controls engineering can be asked to implement and evidence.
Privacy and de-identification
- HIPAA where protected health information is handled, and GDPR and other applicable privacy regulations, as your privacy function determines
- The de-identification or pseudonymisation method applied per source as determined by your privacy function, with the determination recorded and dated
- Re-identification risk treated as a position that changes whenever a source is added or a linkage is extended, and reassessed on that trigger
Permitted use
- Licensed healthcare data restrictions encoded per source: audience, grain, combination, derivation, retention and exit
- Technical access distinguished from permitted use, since a user may hold two datasets and not be permitted to link them
- AI and model training eligibility recorded per dataset at onboarding, not decided at project time
Separation of commercial from clinical
- No pathway from the commercial analytical environment to an individual patient identifier, enforced by architecture and access
- Minimum population rules and suppression applied in the model, consistently across reports, including on export
- Patient services and support programme data held in a separate governed environment with its own permitted uses
- Every output carrying a stated permitted use, because the realistic risk is a downstream user acting in good faith
Security and evidence
- Role-based access with least privilege, resolved per user and per dataset
- Lineage from every published figure back to source, cohort version, method version and data vintage
Pipelines fail loudly. Cohorts, coverage, de-identification risk and model accuracy all drift quietly, and each one changes what the published numbers mean while every job reports success.
| Failure | How it presents |
|---|---|
| Cohort composition shifted | The metric moves and gets read as a market change, with no code altered |
| A vendor restated methodology | History and current view diverge, and both are defended as correct |
| Panel coverage changed in a geography | Patients appear to leave therapy in one region only |
| Tokenisation stability degraded | One patient becomes two, inflating counts and shortening persistence |
| Linkage produced false matches | Two patients become one and the journey contains impossible sequences |
| Follow-up window silently shortened | Persistence improves because the hardest patients were excluded |
| Suppression applied inconsistently | Two reports can be combined to defeat it, which is the real exposure |
| Linkage scope extended without reassessment | The de-identification position is now older than the data estate |
| A model was used at individual level | A cohort-level output reached a patient-level decision somewhere |
The outcomes below follow from two changes: cohorts treated as versioned products, and observability stated on every number.
Patient population and treatment journey visibility improved, with each figure defensible about what it rests on
Unmet need and treatment barriers identified, and attributed to the right step of the funnel rather than to prescriber behaviour by default
Adherence and persistence challenges understood as behaviour plus method, so the response addresses the behaviour
Forecasting inputs that the forecasting function can actually use, because the population basis is documented
A privacy posture that survives scrutiny, because the controls are in the architecture rather than in a policy
We will take one patient metric you currently publish and establish what it rests on: the cohort definition and version, the panel coverage, the method, and the completeness position. If it holds up, we will say so and tell you what to do next.
CaliberFocus builds patient journey, population, adherence and market analytics on governed real-world data. We version every cohort, state what the data can and cannot observe on every number, record the method behind adherence and persistence, enforce minimum population rules in the model, and keep a hard architectural line between commercial insight and individual care.
- Versioned cohorts with coverage and data vintage on every figure
- Discontinuation separated from loss of observability
- Small-cell suppression and permitted use enforced in the model
- No pathway from commercial analytics to an individual patient
Security & Compliance
