Draft BAA Template (contract for dental practices)
P4 + P5⚠ RIAZ: T9 + T10
P9
Get cyber liability insurance
P3–P7
P10
Attorney review of BAA + all policies (one-time, ~$500–1,500)
P4–P8
P11
Register with GA Department of Revenue (may not be needed yet — single-member LLC files on personal return)
⚠ WAITING ON ATTORNEY: L11
P12
Get local business license (city/county) 📞 Monday AM: Call City of Atlanta — ask if a home-based software company needs an occupational tax certificate. You're in Fulton County, 30324.
Nothing Abram produces moves forward until Riaz has read and approved it.
#
Document / Deliverable
Read
Approved
P1
Operating Agreement
P3
HIPAA Risk Assessment
P4
HIPAA Privacy Policy
P5
HIPAA Security Policy
P6
Breach Notification Plan
P7
Incident Response Plan
P8
BAA Template
P9
Insurance Policy Details
P10
Attorney Review Summary
P13
Dental Office Interview Notes
P14
Patient Interview Notes
P15
Specialist Interview Notes
Attorney Review Items
Questions and determinations that require legal counsel. This list is updated as new documents are drafted or technical decisions raise legal questions. Bring this list to your attorney meeting.
L1Business Associate vs. Covered Entity ClassificationHigh
Question: Is Alset Records LLC a Business Associate or a Covered Entity under HIPAA?
Our assumption: Business Associate — we build SaaS software that dental practices (the Covered Entities) use to manage patient images. We handle PHI on behalf of practices, not directly in a provider relationship with patients.
Complication: Patients also use the portal directly to store, view, and share their own medical images. Does this direct patient relationship change our classification? Could we be considered a "Personal Health Record" vendor under the HITECH Act (which has different rules)?
Why it matters: This determination affects every other legal document — BAA structure, who signs what, whether we need a Notice of Privacy Practices, breach notification obligations, and our overall regulatory framework.
Question: Is designating the sole member as both HIPAA Privacy Officer and Security Officer in the Operating Agreement legally sufficient, or should these be in separate standalone resolutions?
Context: The Operating Agreement (Article VI) designates Riaz Salehi as both Privacy Officer and Security Officer. As a single-member LLC with no other employees, this is the only option currently. But as the company grows, how should this transition?
Also ask: Should the Operating Agreement include a provision for automatic reassignment of these roles if the member becomes incapacitated?
Operating Agreement (Art. VI)
L3FDA/SaMD Classification — DICOM ViewerHigh
Question: Does the browser-based DICOM viewer make Wardenclyffe a Software as a Medical Device (SaMD) requiring FDA 510(k) clearance?
Our position: The product description is "Platform for patients to store, view, and share medical images with providers for clinical review including second opinions." The viewer displays images — it does not provide diagnostic measurements, AI analysis, or clinical decision support.
Complication: Practitioners use the shared images for "clinical review including second opinions." If a dentist makes a clinical decision based on an image viewed through our platform, does the viewer become a diagnostic tool? The FDA's 2019 Clinical Decision Support guidance and the De Novo pathway for image viewing software are relevant.
Why it matters: If FDA-regulated, this is a potential launch blocker. 510(k) clearance takes 6-12 months and costs $15K-$100K+. We need a clear determination before going to market.
Product RoadmapMarketing ClaimsTerms of ServiceLaunch Timeline
L4Operating Agreement — Effective Date vs. Approval DateLow
Question: The Operating Agreement is dated February 10, 2026 (the filing date), but the Georgia LLC registration is still pending approval. Should the effective date be the filing date or the approval date?
Context: Georgia typically approves LLC filings within 5-15 business days. The Operating Agreement was drafted with the filing date as the effective date, which is common practice, but confirm this is appropriate under Georgia law.
Question: What steps beyond the Operating Agreement are needed to protect the corporate veil of a single-member LLC handling PHI?
Context: Single-member LLCs are more vulnerable to veil piercing than multi-member LLCs. With HIPAA liability in play (fines up to $1.5M/year per violation category), personal liability protection is critical. The Operating Agreement includes separate bank accounts (Art. VIII, Sec. 8.3) and insurance requirements (Art. VII, Sec. 7.3).
Ask specifically: (1) Is the insurance coverage list in Section 7.3 sufficient? (2) What minimum cyber liability coverage amount is recommended for a health tech startup? (3) Should we carry a corporate umbrella policy?
Operating Agreement (Art. VII)Insurance (P9)
L6Patient Consent Model — Who Obtains Consent?Medium
Question: Who is responsible for obtaining patient consent before PHI enters Wardenclyffe — the practice or Alset Records?
Context: The AWS BAA requires patient consent before PHI goes on AWS (Legal checklist document #10). If we're a Business Associate, the Covered Entity (practice) normally obtains consent. But patients also sign up directly to view their images. Do we need a separate patient consent/authorization form for the patient-facing portal?
Affects the codebase: If Alset needs its own consent flow, we need to build a consent capture screen during patient registration — the technical terminal needs to know this.
BAA Template (P8)Privacy Policy (P4)Patient Registration (T6)Terms of Service
L7Share Link Functionality — Liability for Misdirected PHIMedium
Question: When a patient shares medical images via a time-limited link, who is liable if the link is sent to the wrong person?
Context: Wardenclyffe lets patients generate share links (with optional PIN protection, expiry dates, and view limits) to send images to practitioners for second opinions. The patient controls who receives the link. If a patient accidentally shares PHI with the wrong recipient, is this a breach under HIPAA? Is Alset Records liable?
Technical safeguards in place: PIN protection, link expiry, view count limits, link revocation, full audit logging of every view with IP address.
Ask specifically: Should the Terms of Service include a disclaimer about patient-initiated sharing? Does patient-directed sharing fall under the "right of access" provisions?
Terms of ServicePrivacy Policy (P4)Share Link Feature (T8)
Question: What are the legal implications of promising "lifetime" image storage as a product feature?
Context: The architecture uses S3 lifecycle policies (Standard → IA → Glacier) to store images indefinitely. This is marketed as a feature. But what happens if Alset Records dissolves? The Operating Agreement (Art. X) requires returning/destroying PHI upon dissolution, but "lifetime storage" implies permanence.
Ask specifically: (1) Should Terms of Service define "lifetime" with a caveat? (2) Do we need a data portability plan (export feature) to fulfill this promise? (3) If the company is acquired, what happens to the storage commitment?
Terms of ServiceOperating Agreement (Art. X)Marketing Materials
Question: What level of identity verification is legally required before a patient can access their PHI through Wardenclyffe? Can or should we collect Social Security Numbers (SSNs) for identity verification?
Context: Patients access their own medical images (PHI) through the portal. HIPAA requires that we verify the identity of anyone requesting access to PHI (45 CFR 164.514(h)). Currently the system has no identity verification — anyone with an email address could create an account and claim to be a patient. This is a security gap.
Options under consideration:
(a) Invitation code model (like MyChart) — practice creates patient record first, generates an activation code, patient registers using the code + date of birth verification. No SSN needed.
(b) SSN-based verification — collect last 4 digits of SSN to match against practice records. More secure but creates massive liability: SSNs are PII under state breach notification laws (not just HIPAA) and require additional security controls. A breach involving SSNs triggers notification obligations in all 50 states.
(c) Knowledge-based verification — patient answers questions only they would know (DOB, MRN, address on file).
(d) Government ID upload — patient uploads photo ID for manual or automated verification.
SSN-specific concerns: If we collect SSNs (even last 4 digits), this data becomes subject to additional state laws beyond HIPAA (e.g., Georgia Personal Identity Protection Act O.C.G.A. 10-1-911). A data breach involving SSNs dramatically increases liability exposure and notification obligations. Most healthcare portals (MyChart, FollowMyHealth) avoid collecting SSNs and use invitation codes instead.
Why it matters: Without proper identity verification, an unauthorized person could access someone else's medical images — a clear HIPAA violation. But the verification method chosen has significant legal implications for data liability, breach notification scope, and user experience. This decision directly affects codebase architecture (T6).
Patient Registration (T6)Privacy Policy (P4)Security Policy (P5)Terms of ServiceBreach Notification Plan (P6)
Question: Should offering SMS OTP as an MFA method be formally documented as a risk-accepted deviation from NIST SP 800-63B?
Context: NIST SP 800-63B Section 5.1.3.3 deprecates SMS as an out-of-band authenticator due to SIM swapping and SS7 interception vulnerabilities. Wardenclyffe offers SMS OTP only as a fallback for patients who lack an authenticator app — passkeys (WebAuthn) are the recommended primary method. System administrators are restricted to TOTP only and cannot use SMS. Technical mitigations include per-user send rate limiting (3 codes per 15 minutes), per-IP Rack-layer throttling, 5-minute code expiry, and 3-attempt verification limits.
Why it matters: While HIPAA does not mandate a specific MFA technology, a future auditor or breach investigation could cite NIST's deprecation of SMS. A formal risk acceptance memo documenting the rationale (SMS MFA is dramatically better than no MFA for patients who can't use passkeys or TOTP) would demonstrate due diligence and a reasoned security decision.
Question: Is Wardenclyffe's SaaS subscription subject to Georgia sales tax?
Context: Georgia generally taxes tangible personal property, not services. Cloud-based SaaS (no downloaded software) is generally not taxable in Georgia. However, Georgia's stance on SaaS taxation has been evolving and some states have started taxing SaaS. Need confirmation that a monthly subscription for a cloud-hosted medical imaging platform is exempt.
Also ask: If we sell to practices in other states, do we need to worry about sales tax nexus in those states? Many states DO tax SaaS (e.g., Texas, New York, Pennsylvania). At what point do we need to collect and remit sales tax in other jurisdictions?
Why it matters: Affects GA Dept of Revenue registration (whether to register for a sales tax account), pricing structure, and multi-state compliance as we grow.
GA Dept of Revenue RegistrationPricing / BillingMulti-State Compliance
Background: Some dental customers will be multi-location groups (e.g., "Atlanta Endodontics Group" with offices in Buckhead, Midtown, and Alpharetta). The database already supports staff and patients belonging to multiple practices. A future enhancement would add an "Organization" entity that groups multiple practices under one business for unified management.
What would be built:
• New organizations table (id, name, slug, timestamps)
• New organization_id column on practices (nullable — solo practices don't need one)
• Organization model with has_many :practices
• Org-admin role for managing staff/settings across all locations
• Practice switcher in the nav bar for multi-location staff
• Optional: org-level dashboard aggregating stats across locations
Legal questions that arise:
1. BAA structure: Does a multi-location dental group sign one BAA with Alset covering all locations, or a separate BAA per practice/location? If one umbrella BAA, who is the signing Covered Entity — the parent organization or each individual practice? Many dental groups operate each location under a separate legal entity (separate P.C. or PLLC per location) even though they share ownership.
2. Cross-location PHI access (minimum necessary rule): If an org-admin can see a combined dashboard across all locations, they can see patient counts, image counts, and potentially patient names from locations they don't work at. Does this violate HIPAA's minimum necessary standard (45 CFR 164.502(b))? Should org-level views be restricted to aggregate statistics only (no PHI), or is it permissible for an org-admin to see patient-level data across all their locations?
3. Staff floating between locations: When a hygienist works at Buckhead on Monday and Midtown on Tuesday, she can currently see patients at both locations (the Pundit policies scope across all active staff assignments). Is this appropriate, or should access be restricted to only the location where the staff member is physically working that day? The audit log records which practice context was active, but the staff member could switch at will.
4. Patient data portability within an org: If a patient is seen at the Buckhead location and then visits Midtown, should their images from Buckhead be visible at Midtown automatically (because it's the same organization), or does the patient need to be explicitly enrolled at the new location? Automatic sharing is more convenient but raises minimum necessary concerns.
Not needed for launch — first customers will be single-location practices. This is a post-launch feature that needs legal guidance before implementation.
L13Uplink Desktop App — Persistent Practice Session Without TimeoutLow
Question: Does allowing the practice-level login session on the Uplink desktop app to persist indefinitely (without an inactivity timeout) comply with HIPAA's automatic logoff requirement?
Context: The Uplink desktop app uses a two-layer login: (1) a Practice Admin logs in to establish which office the app is connected to, then (2) individual staff members authenticate with their own credentials to access PHI. The practice-level session (layer 1) is essentially a configuration context — it identifies WHICH office the computer belongs to but grants zero access to patient data on its own. No PHI is visible until a staff member completes their own login (layer 2), which does have the standard 15-minute inactivity timeout.
Our interpretation: HIPAA's automatic logoff requirement (45 CFR 164.312(a)(2)(iii)) applies to sessions that provide access to ePHI. Since the practice context alone provides no access to any patient data, it functions like a device configuration (similar to connecting to an office network) rather than an authenticated PHI session. The individual staff session — where PHI access occurs — enforces the 15-minute timeout as required.
Why it matters: If the practice session must also time out, the Practice Admin would need to re-authenticate every day (or more frequently), which adds friction and may discourage adoption. Confirming this interpretation avoids over-engineering a timeout that isn't legally required while ensuring we're not creating a compliance gap.
L14Intellectual Property Strategy — Patents, Trade Secrets, and Competitive MoatMedium
Question: Does Wardenclyffe have any patentable innovations, and what IP protection strategy should we pursue?
Potentially patentable elements: (1) The multi-confidence DICOM-to-PMS patient matching algorithm (3-tier confidence scoring using Patient ID, name, and DOB with graduated confirmation gates); (2) The cross-practice patient-owned medical image model (patient's records follow them across providers, unlike practice-locked systems like Dexis/Schick); (3) The automated PMS column detection and mapping system for bulk patient import across different dental software formats.
Trade secret considerations: The matching algorithm, column mapping heuristics, and dedup logic are currently protected as trade secrets in private repositories. Would filing a patent (which requires public disclosure) weaken our position compared to keeping these as trade secrets?
Copyright: Source code is automatically copyrighted. Should we register with the US Copyright Office for stronger enforcement rights?
Competitive context: Established dental imaging companies (Dexis, Planmeca, Carestream) could build similar patient portals. Our differentiator is the patient-centric, practice-agnostic model. Ask attorney whether a provisional patent ($2-5K) is worth filing to preserve the option while we validate the market.
Why it matters: Need to decide IP strategy before launch — once the product is public, the 1-year patent filing window starts for any publicly demonstrated features.
Business StrategyOperating AgreementLaunch Timeline
L16Transparent Flywheel Pricing Model — Data Dividend Legal StructureMedium
Question: How should the "data dividend" (credits to practices from de-identified data licensing revenue) be legally structured?
Context: We are considering a pricing model where practices receive a quarterly credit ("data dividend") against their platform fees, funded by revenue from licensing de-identified dental imaging datasets to research institutions and AI companies. The credit is proportional to total images uploaded (platform participation), NOT consent rates — specifically to avoid incentivizing practices to pressure patients into consenting. See the Business Strategy section of this checklist for full details.
Ask specifically: (1) Should the dividend be structured as a rebate, cooperative distribution, revenue share, or platform credit? Each has different tax treatment. (2) Does distributing data licensing revenue to practices create any issues under HIPAA's "sale of PHI" prohibition (45 CFR 164.502(a)(5)(ii)), given the data is de-identified? (3) Does this model change Alset's relationship with practices beyond the BAA? (4) Any anti-kickback statute concerns with a dividend tied to data contribution volume? (5) How should this be documented — amendment to BAA, separate data licensing agreement, or terms of service?
Why it matters: The pricing model is a core competitive differentiator. Getting the legal structure right before launch prevents costly restructuring later. The model affects BAA language, practice agreements, and patient consent forms.
Practice BAATerms of ServicePatient Consent FormsBusiness ModelTax Structure
L17AI Training on CBCT Uploads — HIPAA Authorization, De-Identification, and FDA ImplicationsHigh
Question: Can Alset collect and use CBCT volumetric data uploaded through the platform to train proprietary AI models, and what legal framework is required?
Context: Every CBCT scan uploaded via Uplink represents valuable training data for AI models (auto-windowing, image quality scoring, anomaly detection, anatomy segmentation). We want to build a pipeline that extracts anonymized features from every upload for future AI development. However, CBCT voxel data is PHI — volumetric dental anatomy is unique enough to potentially re-identify patients even without DICOM metadata. Standard BAAs only authorize PHI use for treatment/payment/operations, not product development or research.
Key concerns: (1) HIPAA authorization — using PHI for AI training likely requires separate patient authorization beyond the BAA (45 CFR 164.508), not just a consent checkbox; (2) De-identification standard — does Safe Harbor (strip 18 identifiers) suffice for 3D volumetric data, or is Expert Determination (45 CFR 164.514(b)) required given re-identification risk from unique dental anatomy?; (3) If the AI ever informs clinical decisions (even indirectly), it enters FDA SaMD territory; (4) The "sale of PHI" prohibition (45 CFR 164.502(a)(5)(ii)) — if we use patient data to build a commercial AI product, does that constitute a sale?; (5) State-specific consent laws (Georgia and others) may impose additional requirements.
Ask specifically: (1) What authorization language do we need in the patient consent form to permit AI training use of de-identified imaging data? (2) Is a separate opt-in consent required, or can this be included in the general Terms of Service? (3) What de-identification standard applies to 3D volumetric CBCT data — Safe Harbor or Expert Determination? (4) Can we start collecting non-PHI features immediately (histogram distributions, noise levels, voxel spacing, manufacturer metadata) without additional consent? (5) Does building an internal AI model from patient data change Alset's HIPAA classification or BAA obligations? (6) At what point does an AI trained on medical imaging data require FDA clearance?
Why it matters: This is a significant long-term competitive advantage — proprietary AI trained on real-world dental CBCT data is extremely valuable. But getting consent/authorization wrong could result in HIPAA violations ($1.5M/year per category), and deploying an AI without FDA clearance where required could result in enforcement action. We need the legal framework established before writing any data collection code.
Patient Consent FormsTerms of ServicePrivacy PolicyPractice BAAFDA/SaMD ClassificationData Architecture
L15Deceased Patient Data — Retention, Deletion, and Research UseMedium
Question: What are the retention obligations for deceased patients' PHI, and can we license de-identified imaging data for research purposes?
HIPAA rules: The Privacy Rule protects a deceased individual's PHI for 50 years after the date of death. After 50 years, the data is no longer considered PHI under HIPAA. However, state laws (Georgia and others) may impose different retention requirements.
Research/commercial use opportunity: De-identified dental images (x-rays, CBCTs with all 18 HIPAA identifiers stripped) are valuable to AI training companies, dental schools, and forensic dentistry researchers. Options: (1) Obtain patient consent during their lifetime authorizing post-mortem research use of de-identified images; (2) De-identify images after 50 years post-death when HIPAA no longer applies; (3) Build a de-identification pipeline (strip DICOM metadata, scrub embedded text) and sell/license datasets regardless of patient status — de-identified data is not PHI.
Ask specifically: (1) Can we add a clause to our Terms of Service or patient consent form authorizing use of de-identified images for research? (2) What de-identification standard applies — Safe Harbor (remove 18 identifiers) or Expert Determination? (3) Does selling de-identified datasets trigger any HIPAA "sale of PHI" concerns under 45 CFR 164.502(a)(5)(ii)? (4) Are there Georgia-specific data retention laws for medical images beyond HIPAA's 50-year post-mortem rule? (5) What liability exists if a de-identified dataset is later re-identified?
Terms of ServicePrivacy Policy (P4)Patient Consent FormsData Retention PolicyBusiness Model / Revenue
Research Questions — Product & Technical
Open questions that need investigation. Not legal — these are product/technical decisions that affect how we build features.
#
Question
Context
Resolved
R1
Enhanced Multi-Frame DICOM — Which dental CBCT systems export this format?
Some CBCT systems pack all slices into a single DICOM file (enhanced multi-frame) instead of exporting 450+ individual .dcm files. We currently only handle the individual-file format (bundle into ZIP → 3D viewer). Need to research:
• Which dental CBCT brands export enhanced multi-frame? (i-CAT, Planmeca, Carestream, Sirona, Vatech, Dexis)
• How common is this in dental vs medical CT?
• Can Cornerstone.js load a single multi-frame DICOM as a volume?
• Detection: check DICOM tag NumberOfFrames (0028,0008) — if > 1 in a CT file, it's multi-frame
Current behavior: A single multi-frame CT file would upload as a regular image and display flat (wrong). It should be detected and loaded into the 3D viewer.
Priority: Low — Ez-Denti (our first customer's system) exports individual files. Build this when we encounter it in the wild.
Office Imaging Software — Export Recommendations
Recommended export settings for Wardenclyffe Uplink by practice management software. These settings preserve maximum diagnostic image quality.
Software
Sensor/Hardware
Export Format
Notes
Eaglesoft
Schick CDR Elite (USB interface only, no standalone software)
TIF — Uncompressed, 8-bit
Do NOT export as JPG. Eaglesoft's JPG export uses aggressive compression (~85% size reduction) and downscales resolution (e.g., 1200px → 846px). It also converts 8-bit grayscale to 24-bit RGB unnecessarily.
TIF Uncompressed at 8-bit preserves the original sensor data (~1MB per PA). Avoid CCITT (fax format) and JTIF (lossy JPEG inside TIF).
No standalone DICOM software (CDR DICOM / Sidexis) is installed at this office — Schick sensor connects directly through Eaglesoft's bridge.
Ez-Denti (VaTech)
VaTech CBCT + PA sensors
DICOM preferred, JPG acceptable
Ez-Denti supports DICOM export for CBCTs and may export PAs as JPG. Test exported DICOMs for patient metadata fields (Patient Name, Patient ID/MRN, DOB) — needed for Uplink's patient matching cross-reference.
Do NOT watch Ez-Denti's active server folder — VaTech confirmed this can corrupt files. Always use Ez-Denti's manual export function instead.
General guidance for all offices: Export one patient at a time to a dedicated folder. Upload through Uplink. Clear the folder before exporting the next patient. This prevents cross-patient file mixing, especially for JPG/TIF files that lack embedded patient metadata.
Business Strategy — The Transparent Flywheel
A novel pricing model where Wardenclyffe gets cheaper for everyone as it grows. Status: CONCEPT — needs financial modeling and attorney review before committing.
COREThe Pricing Formula
Every practice sees a transparent, auditable bill:
Monthly Bill = Your Storage (at-cost) + Platform Fee − Data Dividend
Your Storage = actual AWS cost for your images at their current tier. No markup. A practice with 500GB of images older than 1 year pays ~$2/month. They can verify this against public AWS pricing.
Platform Fee = fixed monthly fee covering compute, compliance, support, development. Same for every practice.
Data Dividend = the practice's share of revenue from licensing de-identified datasets to research institutions, dental AI companies, and dental schools. Proportional to total images contributed to the platform.
PricingRevenue ModelNeeds Financial Modeling
WHYThe Flywheel Effect
1. The platform gets cheaper over time. Images tier from S3 Standard ($0.023/GB) to Glacier Instant Retrieval ($0.004/GB) after a year — 83% cost reduction. This savings passes through to the practice because storage is billed at-cost.
2. The platform gets more valuable over time. A larger de-identified dataset attracts bigger licensing deals. More licensing revenue means a bigger dividend pool, which means lower effective cost for every practice.
3. Early adopters are rewarded. Their images are the cheapest (already in Glacier) and they've contributed the most to the dataset (largest dividend share). Being early is a genuine financial advantage — no artificial "founding member" discount needed.
4. New practices don't subsidize old ones. Each practice pays for its own storage at actual cost. The dividend starts small (few images uploaded) and grows proportionally. No one carries anyone else's weight.
5. Practices become growth evangelists. Every new practice that joins grows the dataset → attracts bigger licensing deals → increases everyone's dividend. Practices are incentivized to recruit other practices because a larger network literally makes their own bill smaller.
6. The "Inverse Upsell." Traditional SaaS: "We launched a new feature, pay more." Flywheel: "We launched a new revenue stream, your bill goes down." When Alset adds CE courses or a second-opinion marketplace, that revenue feeds the dividend pool — every practice benefits even if they don't use the new feature.
UXWhat the Practice Dashboard Shows
Your Wardenclyffe Bill — March 2027
─────────────────────────────────────
Storage (12,456 images) $23.41
└ 9,200 in Glacier $1.84
└ 2,100 in Standard-IA $6.30
└ 1,156 in Standard $15.27
Platform fee $149.00
Data dividend −$45.20
────────────
Total $127.21
Network stats:
2.3M images · 847 practices
Q1 research licensing: $234,000
Your share: 0.54% (12,456 / 2.3M images)
Every number is auditable. Practices can verify storage cost against public AWS pricing. They can see licensing revenue totals (not contract terms). Radical transparency builds trust.
REVENUERevenue Streams That Feed the Dividend Pool
Every secondary revenue stream Alset develops feeds the dividend pool, reducing every practice's effective cost. The more Alset diversifies, the cheaper the platform gets for everyone.
Stream 1: De-Identified Research Data Licensing (Primary)
License the de-identified dataset to dental AI companies (Pearl, Overjet, VideaHealth), university research programs, and dental schools. Wardenclyffe's cooperative model aggregates data across hundreds of independent practices — a more diverse dataset than any single DSO can offer. This is the core flywheel asset.
Stream 2: Continuing Education (CE) Platform
Dental professionals need CE credits annually — it's a massive, recurring market. Use real de-identified cases from the platform as teaching material (not textbook cases). Offer courses for a per-course fee or CE subscription. The dataset makes the courses uniquely valuable because they're drawn from real clinical variety. Revenue feeds the pool.
Stream 3: Second Opinion Marketplace
Patients already share images with other providers via Wardenclyffe. Formalize this as a marketplace: patient requests a second opinion → matched with a specialist (endodontist, oral surgeon, orthodontist) → specialist reviews images on the platform → provides opinion. Transaction fee on each consultation. The images are already there — no re-imaging, no radiation, no delay. Revenue feeds the pool.
Stream 4: Insurance Pre-Authorization Automation
Insurance companies require pre-authorization with images for many dental procedures. Practices currently do this manually (print, scan, fax, email). Wardenclyffe can offer one-click pre-auth submission: select the images, select the procedure, submit directly to the insurer's portal. Per-submission fee or insurer pays for integration. Massive time saver for front desk staff. Revenue feeds the pool.
Stream 5: Practice Analytics & Benchmarking
Aggregated, anonymized data across the network powers practice-level analytics: "Your practice performs 23% more root canals than the network average." "Your imaging volume is trending up 12% QoQ." "Average time from imaging to treatment plan in your region: 4.2 days." Premium analytics dashboard as an optional subscription. Practices love benchmarking data — it's how they optimize operations and identify growth opportunities. Revenue feeds the pool.
Stream 6: White-Label API / Infrastructure Licensing
Other dental software companies (PMS, EHR vendors) could integrate Wardenclyffe's imaging infrastructure via API. Why build HIPAA-compliant image storage, DICOM viewing, and patient sharing from scratch when Wardenclyffe already has it? API call pricing or per-integration licensing. Wardenclyffe becomes the "Stripe of dental imaging." Revenue feeds the pool.
Stream 7: Dental School Institutional Licensing
Dental schools need diverse case libraries for training students. Wardenclyffe's de-identified dataset — with variety across patient demographics, pathologies, and imaging modalities — is exactly what they need. Institutional licenses for teaching use, priced per-school per-year. Revenue feeds the pool.
The dividend must NOT be tied to how many of a practice's patients consented. That creates a perverse incentive for practices to pressure patients into consenting. Instead:
• Patients consent independently and freely — their choice doesn't affect their access or care
• The dividend is based on total images uploaded (platform participation), not consent rates
• A practice with 50,000 images gets 5x the dividend of one with 10,000 — regardless of how many patients consented
• Patient consent is a platform-wide metric, not a per-practice metric
• Practices never touch the data licensing process — Alset handles it entirely
• Staff cannot see individual patient consent status (no pressure vector)
• All research data is de-identified before it leaves the platform — practices never see or access the research dataset
This entire model needs attorney review before any public commitment. The data dividend structure, interaction with BAAs, consent/licensing separation, and how it's characterized (cooperative credit vs. revenue sharing) all have legal implications.
HIPAAEthicsAttorney Review Required
MOATWhy This Is Hard to Copy
Data network effect: The dataset gets more valuable with every practice that joins. A competitor starting from zero can't offer meaningful dividends, so practices have no reason to switch. The lead compounds.
Switching cost is inverted: In traditional SaaS, switching costs are usually negative (vendor lock-in annoys customers). Here, staying is genuinely better — your images are cheapest, your dividend share is largest, and you've contributed the most to the dataset. Leaving means losing accumulated value you helped build.
Transparency as trust: A competitor offering opaque "competitive pricing" can't match the trust of a model where every line item is verifiable. Once a practice sees their actual AWS cost is $2/month and the platform fee is clearly justified, no sales pitch from a competitor can create doubt.
Dental AI data gap: Pearl, Overjet, and VideaHealth all struggle to get training data — they partner with DSOs one at a time. Wardenclyffe's cooperative structure lets independent practices collectively build a dataset that rivals or exceeds any single DSO. This positioning only strengthens as AI demand grows.
RISKSKnown Risks & Mitigations
Research revenue is $0 in year 1. The dataset needs critical mass before it's licensable. Be upfront about this — show projected trajectory. The storage-at-cost transparency alone differentiates from competitors even with no dividend. Consider a "founding member" platform fee discount for the first 50 practices to reward early risk.
"You're selling our patients' data." This framing will come up. The answer: patients consent independently, the data is irreversibly de-identified (no re-identification possible), and the dividend is based on platform participation (images uploaded) not consent rates. Practices never touch the data licensing. Alset handles it. The consent infrastructure we built explicitly separates consent from platform access — declining doesn't limit functionality.
Practices gaming the system with junk uploads. Dividend is based on valid clinical images only. The existing processing pipeline validates image type, quality, and metadata. Junk uploads fail processing and don't count.
Regulatory classification of the dividend. Is it a rebate? Revenue sharing? Cooperative distribution? The tax and legal treatment matters. Attorney review required before committing to this publicly.
FDA/SaMD risk on AI features. If Alset builds proprietary AI tools using the dataset (e.g., caries detection), those tools may require FDA clearance. Research licensing to third parties avoids this — they handle their own regulatory burden. Alset's own AI features must stay operational (not diagnostic) unless 510(k) is obtained.
📅 Phase Timeline
Phase 1 — Foundation
Weeks 1–3 • No cross-dependencies — both work freely