Example datasets used in this workshop
| Dataset | What it is | Used for |
|---|
| Clinical + claims (Tuva model) | A synthetic, patient-level Medicare claims + clinical dataset (the open Tuva data model): patients, encounters, conditions, procedures, claims, eligibility, member-months. | Track A — rich entities for metrics like readmission rate and cost PMPM. |
| Medicare Part D + demographics | Public CMS Part D landscape data — plans, formulary, costs, prescribers — plus county-level socioeconomic reference data. | Cross-source analysis and the role-based-access examples. |
Demo data —Numbers and dates are illustrative. For your own build, connect your data sources and run the same steps. Set connectors at the start of a session; credentials are managed in connector settings — never stored in the ontology repo.
Bringing your documents to Ana
| Method | How it works | Best for |
|---|
| Upload to a session | Add files directly (PDF, DOCX, PPTX, XLSX, CSV, Markdown). | A handful of documents, or adding “one more”. |
| Cloud document store | Connect a shared drive and point Ana at a folder. | Teams whose documents live in a managed drive. |
| Enterprise document systems | SharePoint / OneDrive, Confluence, or internal object storage (S3 / Azure Blob / GCS). | Larger or regulated organizations. |
| Git repository | Keep the distilled ontology (Markdown + .tql) in your own git repo. | The governed ontology itself. |
For regulated organizations —Keep documents and data inside your own boundary. With a single-tenant / in-VPC deployment, sensitive content never leaves your environment, and Ana ingests from your sanctioned stores rather than a consumer drive. A common pattern is a watched location — a designated folder or bucket Ana monitors, so a newly dropped document is distilled into the ontology as a reviewable change.
.tql that lives there.
