FalsePay

An automated, 1-click defense shield protecting physicians from $14 billion in pharmaceutical reporting fraud.

Comment

Inspiration

Every year, pharmaceutical and medical-device manufacturers report transfers of value such as meals, travel, consulting fees, and research payments under physicians’ names through the CMS Open Payments program. For a physician, an incorrect or unfamiliar record can become a reputational and administrative burden, especially when there is a limited review and dispute window.

We saw an opportunity to transform a traditionally low-conversion cold-outbound problem into a genuinely useful, physician-first experience.

Instead of opening with another generic sales message, FalsePay starts with transparency: it helps healthcare professionals review public Open Payments activity associated with their NPI, understand why certain records may deserve attention, and generate a reviewable dispute draft when something looks inaccurate or unrelated to their specialty.

Our goal is to make HCP outreach more valuable, evidence-based, and consent-driven turning anxiety around public transparency data into a trusted, ongoing engagement channel.

What it does

FalsePay is an HCP engagement and Open Payments audit platform that helps teams identify potentially questionable payment records, enrich physician information from the live CMS NPPES registry, and provide physicians with a secure, low-friction audit experience.

The platform brings together five key workflows:

Live NPI enrichment: Search a 10-digit NPI and retrieve verified physician details from the CMS NPPES Registry, including legal name, credentials, primary taxonomy, and practice location.

Open Payments review: Organize CMS payment records into an actionable physician-level view showing reported dollars, transaction counts, reporting manufacturers, review status, and payment history.

Risk triage: Surface evidence-based signals such as unusual payment velocity and potential specialty-to-product mismatches. These are presented as review indicators not accusations or determinations of fraud.

Secure audit links: Create a tokenized, time-limited audit experience that lets a physician inspect only the records relevant to them without requiring a traditional account creation flow.

Dispute and monitoring workflow: Allow a physician to select questionable records, produce a reviewable draft dispute notice, and explicitly opt in to ongoing monitoring or alerting.

For campaign teams, FalsePay provides a command-center experience: a physician review queue, targeted outreach workflow, risk indicators, and a funnel that tracks lifecycle events such as dispatched, opened, dispute drafted, and protected.

For physicians, FalsePay provides clarity: what was reported, by whom, why it may merit review, and what they can do next.

How we built it

We built FalsePay as a full-stack, API-first healthcare data application designed around a clear separation between outreach operations, protected physician audit experiences, and data-driven risk analysis.

Full-stack architecture Frontend: Next.js, TypeScript, Tailwind CSS Backend: Python and FastAPI Database: Tiger Data managed PostgreSQL with TimescaleDB and pgvector External data enrichment: Live CMS NPPES Registry API Deployment: Dockerized frontend and backend services with environment-based configuration and CORS controls

Data and analytics layer FalsePay uses Tiger Data PostgreSQL as the system of record for physician profiles, CMS payment records, audit links, disputes, and lifecycle events.

We designed the payments layer around a TimescaleDB hypertable partitioned by payment_date. This makes time-based analysis a first-class capability rather than an afterthought. With time_bucket queries, the platform can identify patterns such as sudden monthly spikes or clusters of transactions that may warrant a closer review.

We use pgvector to compare physician specialty context with product or payment descriptions. For example, a product associated with orthopedic spine care appearing on the record of an interventional cardiologist can be flagged for human review based on semantic distance. The result is a transparent specialty-mismatch signal, not an automated claim of wrongdoing.

Secure engagement flow We designed the physician audit portal around secure, scoped audit links: Audit links are generated from cryptographically random tokens. Only a hash of each token should be stored server-side; plaintext tokens are shown only at creation. Links can expire or be revoked. The tokenized route limits access to the relevant physician’s audit information. The system records append-only lifecycle events for dispatched, opened, dispute-drafted, and protection-enrollment states.

The workflow intentionally keeps dispute generation human-controlled. FalsePay generates a reviewable draft; it does not automatically send a legal notice or represent a submitted federal dispute.

API-first integration We designed a versioned REST API contract and treat the backend as the source of truth. The frontend renders loading, empty, and error states from real API responses instead of silently replacing failures with mock data.

The live integration includes health checks, NPI enrichment, CMS payment preview and ingestion, stored-payment review operations, risk-triage operations, and the physician review queue. We also created a test strategy spanning unit tests, route-contract tests, database integration tests, external-adapter tests, and browser-level end-to-end flows.

Challenges we ran into

Building FalsePay required us to solve several difficult problems at the intersection of public healthcare data, physician trust, analytics, and secure product design.

Making public data actionable: Raw Open Payments records are not naturally physician-friendly. We had to translate transactions, manufacturers, dates, amounts, and payment context into a concise audit experience that makes it easy to identify what deserves attention.

Resolving identities accurately: Open Payments data alone does not provide the complete context necessary for trustworthy outreach. We integrated live NPPES enrichment to validate provider identity, credentials, specialty taxonomy, and practice location.

Avoiding misleading “AI fraud” claims: A specialty mismatch or payment spike is a signal, not proof of fraud. We designed the product language and workflows around evidence, review, and physician control rather than making unsupported conclusions.

Balancing low friction with security: A zero-login audit link improves usability, but bearer tokens can be sensitive. We designed for expiring, revocable, hashed tokens; minimal scope; no plaintext token logging; and explicit identity and consent handling before any production submission or enrollment.

Modeling money and payment history correctly: Payment amounts cannot safely use floating-point arithmetic. We designed monetary values as fixed-precision database values and serialized them as strings in the API to avoid rounding drift.

Handling time-series and vector workloads together: We wanted both payment-velocity analysis and semantic specialty matching. Tiger Data’s PostgreSQL, TimescaleDB, and pgvector foundation gave us a unified design instead of requiring disconnected analytics systems.

Creating a credible demo without overpromising: We focused on a polished prototype and real data integrations, while documenting the necessary production requirements: staff authorization, consent boundaries, audit logging, rate limiting, reliable ingestion, migrations, and compliance review.

Accomplishments that we're proud of

Built a complete physician-focused workflow that reframes outbound engagement around immediate utility and transparency.

Integrated live CMS NPPES Registry enrichment to retrieve verified provider identity, credential, specialty taxonomy, and practice information from an NPI.

Designed a high-signal HCP review queue with payment totals, transaction counts, manufacturer context, and evidence-based risk indicators.

Created a physician audit experience that transforms complex Open Payments activity into an understandable and actionable view.

Implemented the foundation for a secure, tokenized audit-link flow with expiry, revocation, hashed-token storage, and lifecycle event tracking.

Used TimescaleDB to make payment velocity analysis queryable over time, including monthly bucketing for surge detection.

Used pgvector to support semantic specialty-to-product mismatch scoring, helping prioritize records that may be unrelated to a physician’s clinical practice.

Treated disputes responsibly: FalsePay generates a draft for review rather than sending an automatic legal notice.

Defined a production-minded integration plan with typed API contracts, OpenAPI-driven frontend types, error-state handling, idempotency, database migrations, and real-stack end-to-end testing.

Dockerized both frontend and backend services for repeatable local and hosted deployment.

What we learned

FalsePay taught us that a strong healthcare product is not just about intelligent analysis—it is about presenting uncertainty responsibly and giving people meaningful control.

We learned that:

Trust is the product. A physician will only engage if the platform is clear about what data it shows, where it came from, what a risk signal means, and what action the physician is actually taking.

Public data needs context. A payment amount alone is rarely useful. Enrichment through the NPPES Registry, payment timing, manufacturer context, and specialty relevance makes the data understandable.

“AI-powered” must not mean “AI decides.” Semantic matching can highlight records for review, but a human should remain in control of decisions, attestations, and dispute submissions.

Security and UX must be designed together. Tokenized links reduce friction, but secure implementation requires expiration, revocation, hashing, scoped permissions, redaction, and explicit consent.

Typed contracts prevent fragile full-stack systems. Defining API schemas first, generating frontend types from OpenAPI, and testing error paths keeps the interface honest and reduces hidden assumptions between the UI and backend.

Event history is more useful than mutable counters. Tracking append-only lifecycle events makes campaign metrics auditable and lets us derive funnel performance from real activity rather than unreliable client-side increments.

Healthcare workflows demand restraint. The right product behavior is often to show evidence, generate a draft, and let a qualified person review not to automate an irreversible action.

What's next for FalsePay

FalsePay’s next phase is about turning the prototype into a robust, compliant, physician-trusted platform.

Complete the production API surface for audit links, token-scoped audit views, dispute drafts, protection enrollments, campaign metrics, and real-time event notifications.

Implement staff authentication and granular authorization for administrative campaign operations.

Add clinician identity verification before enabling sensitive actions such as enrollment or formal dispute submission.

Expand CMS Open Payments ingestion with idempotent source-record fingerprints, scheduled refreshes, and stronger record lineage.

Add production-grade observability: redacted audit logs, request IDs, token-safe analytics, error monitoring, and operational dashboards.

Introduce a physician-centered notification preference center with explicit consent, opt-out, and communication-frequency controls.

Improve the anomaly system with explainable evidence panels so physicians can see exactly why a record was flagged.

Add a compliance-reviewed workflow for manufacturer contacts and submitted disputes, ensuring FalsePay never misrepresents a draft as a filed regulatory action.

Build campaign experimentation tools that measure whether a utility-first audit invitation produces better engagement than traditional outbound messaging.

Run usability testing with physicians and compliance stakeholders to ensure the product remains helpful, respectful, and clinically credible.

Built With

Share this project:

Updates

Submission history