Digital Health Architecture & SaMD Readiness Checklist

Decide what the product legally is before you decide how to build it.

• Intended use and target population are written down in one paragraph the whole team agrees on.
• Product is classified as SaMD or not, with a rationale (does the software output drive a clinical decision?).
• Risk category is estimated against the IMDRF SaMD framework (state of condition × significance of information).
• Regulatory pathway is hypothesized (wellness / 510(k) / De Novo / PMA, or non-device) and revisited as claims evolve.
• Marketing claims are separated from clinical claims — and clinical claims are traceable to evidence.
• Predicate devices or precedents are identified where a clearance pathway is likely.
• Geographic scope is set (FDA / MDR / UKCA…) since it changes obligations materially.
• A "change that triggers re-review" line is defined so the roadmap doesn't quietly cross it.

The structural decisions that are expensive to reverse after launch.

• Core data model is designed for longitudinal, per-subject clinical data — not retrofitted from a consumer schema.
• Multi-tenancy / site isolation is explicit (one study or client cannot see another's data).
• An immutable audit trail records who changed what, when, and why (ALCOA+ principles).
• Schema and API versioning strategy exists so protocol amendments don't break historical data.
• Offline-first behavior and conflict resolution are defined for mobile data capture in the field.
• Time, timezone, and clock-skew handling is specified (clinical timestamps must be defensible).
• Environments are separated (dev / staging / validation / production) with controlled promotion.
• Observability (logging, metrics, alerting) covers data-integrity failures, not just uptime.
• Backup, restore, and disaster-recovery objectives (RPO/RTO) are documented and tested.

Where health data comes from, how it's identified, and where it has to go.

• FHIR is the default interchange model; custom formats are justified, not assumed.
• EHR integration approach is chosen (SMART on FHIR, HL7v2, bulk FHIR) with a named target system.
• Wearable / sensor ingestion defines sampling rate, gaps, units, and device provenance per stream.
• Patient and subject identity is resolved deliberately (MRN vs. study ID vs. account) with a linking strategy.
• Terminologies are standardized (LOINC, SNOMED CT, RxNorm, UCUM) where data will be shared or analyzed.
• Data provenance and lineage are captured end-to-end (raw → derived → reported).
• Missing-data semantics are explicit (not-collected vs. null vs. device-off) before analysis exists.
• Export paths for biostatisticians (analysis-ready datasets) are designed, not improvised at the end.
• Consent scope is bound to data flows — what was consented governs what can be used and shared.

The difference between collecting data and generating evidence.

• Each digital endpoint has a clear definition, rationale, and link to a meaningful aspect of health.
• Digital measures follow the V3 framework: verification, analytical validation, and clinical validation.
• eCOA / ePRO instruments are validated and licensed appropriately for the target population.
• Sensor-derived measures have a documented algorithm and a reference/ground-truth comparison.
• A statistical analysis plan exists before data lock; endpoints aren't chosen after seeing the data.
• Data quality checks (adherence, wear-time, range, drift) are defined and monitored during collection.
• Sample size / power considerations are sane for the claim being made.
• Bias and generalizability are considered (who is represented in the data, and who isn't).
• Regulatory-grade documentation of the measurement pipeline is maintained as it changes.

Table stakes for anyone who will trust you with patient data.

• HIPAA roles are clear (covered entity vs. business associate) and BAAs are in place with every vendor touching PHI.
• Data is encrypted in transit and at rest, with a documented key-management approach.
• Access control is role-based and least-privilege, with access reviewed on a schedule.
• A SOC 2 (or equivalent) path is planned early — enterprise health buyers will ask.
• Data residency and cross-border transfer rules are satisfied for every market in scope.
• De-identification / anonymization approach is defined for analytics and secondary use.
• An incident-response and breach-notification plan exists and names owners.
• Consent, privacy policy, and data-subject rights (access, deletion) are implemented, not just written.
• Third-party dependencies are inventoried and monitored for vulnerabilities (SBOM where feasible).

The processes that make regulated software auditable — right-sized to your stage.

• A quality management system (QMS) exists at a scale that fits the risk — ISO 13485 when it applies.
• Design controls trace requirements → design → implementation → verification → validation.
• Risk management follows ISO 14971 (hazards, harms, mitigations, residual-risk review).
• Software lifecycle processes align to IEC 62304 at the appropriate software safety class.
• Change control and a documented release process govern what ships to production.
• Verification and validation evidence is generated and retained, not reconstructed later.
• Human factors / usability risks are considered for clinician- and patient-facing flows.
• Post-market surveillance and a feedback/complaint loop are planned before launch.

Who owns the work, and whether it survives after the first release.

• Someone owns the seam between engineering and clinical/regulatory — decisions don't fall in the gap.
• Build-vs-buy is decided per component with total cost and regulatory burden in view.
• Vendors and CROs are managed against clear technical acceptance criteria.
• Documentation is written as you go (architecture decisions, data dictionary, runbooks).
• A hiring plan matches the roadmap — the first engineering hires fit the regulated context.
• Technical due-diligence readiness is maintained (investors and partners will look).
• A handoff / knowledge-transfer plan exists so the platform isn't hostage to one contractor.
• Cost and scaling model is understood before growth makes it urgent.