Data Card

This document is the governance-facing companion to the data statement. Where the data statement provides the full dataset card under the Google Data Cards Playbook structure, this document focuses on provenance traceability, licensing posture, and regulatory alignment. Read alongside the model card and the regulatory posture.

Overview

The published distribution includes two synthetic datasets, both committed as version-controlled JSONL:

Eval corpus — curated multi-turn conversational cases across three locales (en, es-419, pt-BR). Cases cover golden, adversarial, and no-match categories with gold-label expected behaviour per turn.
Knowledge-base cards — short structured cards on medication-adherence content, each with provenance metadata (source_url, accessed_at, source_license).

Both datasets are 100% synthetic, carry no PHI or PII, and are redistributable under the MIT license. The surrounding code is Apache-2.0.

Data Provenance

Eval Corpus

Property	Value
Format	JSONL (one JSON object per line)
Size	315 cases (105 en, 105 es-419, 105 pt-BR)
Generation	LLM persona/script-aligned generation with producer-critic loop
Curation	100% manual review by the author
Adversarial seeds	25 hand-authored English plus adversarial slices in es-419/pt-BR
Licence	MIT

Generation methodology follows a four-stage pipeline: persona creation (five condition clusters sampled from published epidemiological ranges), dialogue generation with producer-critic scoring on motivational-interviewing fidelity, scope compliance, and groundedness, manual curation of every generated turn, and hand-authored adversarial case injection. Full methodology is documented in the data statement.

Knowledge-Base Cards

Property	Value
Format	JSONL (id, title, text, source_url, source_license, topics, accessed_at)
Size	38 cards
Licence	MIT (paraphrased content)

Each card is a short structured summary paraphrased from public-domain sources:

DailyMed (FDA Structured Product Labeling) — US Government work, public domain
MedlinePlus (US National Library of Medicine) — US Government work, public domain
WHO Essential Medicines List — consulted for medication selection; card content is independently paraphrased, never verbatim

A per-source license audit accompanies the synthetic data. Cards without provenance fail validation at load time.

Excluded Corpora

The following corpora are explicitly excluded from the distribution in any form:

MedDialog (academic-use-only licence)
ChatDoctor / HealthCareMagic-100K (terms-of-service redistribution prohibition)
MIMIC-IV / MIMIC-IV-Note (PhysioNet DUA forbids redistribution)
i2b2 / n2c2 (institutional DUA forbids redistribution)
Asclepius (CC-BY-NC-SA incompatible with permissive redistribution)

Data Categories

The eval corpus is organised into three categories across all locales:

Category	Description
Golden	In-scope medication-adherence conversations
Adversarial	Dosing, diagnosis, prompt-injection, role-coercion attempts
No-match	Clinical questions with no KB card match

All three locale slices are held at parity (105 cases each); the es-419 and pt-BR slices (105 cases each) include both golden and adversarial coverage. The knowledge base comprises 38 medication-adherence content cards.

Source Licensing Summary

Source	Licence	Usage in Distribution
DailyMed	Public domain (US Gov)	Paraphrased KB card content
MedlinePlus	Public domain (US Gov)	Paraphrased KB card content
WHO Essential Medicines List	CC-BY-NC-SA	Medication selection reference; content paraphrased independently
LLM-generated dialogues	MIT	No copyrighted input; outputs redistributable under MIT
Code	Apache-2.0	Independent from data licence

Current State

This reference implementation operates on 100% synthetic data. No real patient data, no real EHR data, and no identifiable information enters the distribution at any point. The data-acceptance check in CI rejects any file that has not passed an identifiability review.

Key data governance controls that exist today:

Synthetic-only policy: enforced by the contribution workflow and documented in the data statement
Provenance metadata: every KB card carries source_url, accessed_at, and source_license; the loader rejects cards without provenance
Locale parity: the eval harness holds en, es-419, and pt-BR to identical thresholds on every CI run
Version control: data files are committed JSONL, versioned with the code under semantic versioning; changes to the eval corpus or KB are change-gated
IRB statement: no human-subject data; IRB approval is not applicable (see the data statement IRB section)

Known limitations carried from the data statement:

Single-domain corpus; coverage is intentionally narrow
US-English clinical vocabulary bias in synthetic data, partially corrected by the producer-critic loop but documented as residual
KB cards are English; a localised KB is on the roadmap
Near-miss off-corpus clinical questions are not reliably refused (see the model card “Known risks and limitations”)

Sub-processors and Data Handling

The following external services receive request-derived data from this implementation. All disclosures are based on vendor public terms as of 2026-06-09 (the Langfuse Cloud row was re-verified 2026-07-14). No DPA or BAA has been executed for this demo, which operates on 100% synthetic data and handles no PHI.

Sub-processor	Egress point	Data category	Training / retention posture	Certifications (advertised)
LLM inference (completion): OpenAI `gpt-4o-mini` (primary), Anthropic `claude-haiku-4-5` (fallback)	completion API call on the live `/chat` path	Redacted prompt plus retrieved KB context	No training on API data by default; inputs/outputs retained up to ~30 days for abuse monitoring, then deleted; zero-data-retention available under enterprise terms	SOC 2 Type II / HIPAA (BAA) / GDPR (advertised; access-gated)
Voyage AI - `voyage-3.5` embeddings + `rerank-2.5` reranking	embedding API call; reranking API call	Redacted query text	Content is licensed for training by default unless the org Admin opts out; opt-out yields zero-day post-processing retention (prospective-only)	SOC 2 Type II / HIPAA / GDPR (access-gated). Sub-processors: AWS + Google LLC
Langfuse Cloud - OTLP telemetry (live-demo sink)	telemetry / trace exporter	Span attributes only; the user’s message text is never written to a span (enforced privacy invariant); input/output values redacted	No training on customer trace data; the Hobby free tier retains 30 days at 50K observations/month; paid tiers add configurable retention, data masking, and deletion	SOC 2 Type II / ISO 27001 / GDPR (DPA) / HIPAA controls (BAA and HIPAA-ready region, access-gated). Data region: US / EU / Japan selectable

Eval-run traces export to a self-hosted Phoenix instance (Docker Compose, session-only retention, local UI). Because it runs inside the operator’s own deployment and receives no live request data, it is not an external sub-processor; Arize AX is supported only as an optional secondary dashboard on the same OTLP stream and is not enabled in the demo.

Production path: Execute each vendor DPA, confirm BAA availability, enable Voyage training opt-out via the org Admin dashboard, and re-verify sub-processor lists and data residency at contract time.

Production Path

A real deployment handling patient data would need to augment or replace the synthetic datasets and address the following:

Real patient data governance: IRB approval, informed consent, data processing agreements, and jurisdiction-specific health-data regulations (HIPAA, GDPR, Chile Ley 19.628, etc.)
Clinical knowledge base expansion: the demo corpus covers five condition clusters; a production system would need a clinically validated KB with regular clinical review, source verification, and recency checks
Data quality monitoring: automated pipelines for detecting data drift, coverage gaps, and label quality degradation in both the eval corpus and KB cards
Localised content: native-language clinical review for each locale, not just translation of English-generated content; locale-specific clinical escalation paths
Data retention and deletion policies: the reference implementation has no persistent user data; production would need retention schedules, deletion procedures, and data-subject access request handling
Bias audit: systematic assessment of demographic representation in training and evaluation data, beyond the locale-parity checks currently in place