The ACCESS Pre-Launch Verification Checklist
Most ACCESS program teams reach go-live having made all the right decisions on paper: they selected a data standardization approach, defined their device strategy, mapped clinical workflows, and aligned on reporting requirements.
Then they launch and discover that what was decided and what actually works are two different things.
This checklist is not about planning. It's about verification. It assumes your team has already worked through the foundational questions: what data you need, what infrastructure you're building, what workflows you're designing. If you haven't, What ACCESS Model Companies Need to Build Before Go-Live is the right starting point.
What this checklist covers is the step most teams skip or compress: proving that each component works before the first real participant connects.
Before you start: align every team on what "verified" means
A plan is not a verified system. Use these three categories to assess every item in this checklist:
Verified: Tested end-to-end, with documented results and a named owner.
Built but untested: The component exists, but hasn't been validated under real or realistic conditions.
Unresolved: Depends on a decision — technical, clinical, operational, or compliance — that hasn't been finalized.
Anything in the third category is a launch risk. Anything in the second is a potential surprise.
1. Verify your data layer works — not just that it exists
Your team has decided how to standardize data. This section is about confirming it actually does what you need.
Can you prove every metric is arriving correctly?
For each data signal your program depends on, run a verification test. Don't stop at confirming a connection — confirm the data itself.
Verify that:
Values fall within clinically plausible ranges
Units are consistent regardless of which device sent the data
Timestamps are accurate and time zone–adjusted correctly
Summary metrics match the underlying granular data
Participant identifiers are preserved end to end
A standardization layer that passes an integration test but fails a data quality check is not ready for a clinical workflow. For a reference on how ROOK structures and validates biomarker data, see Understanding Our API: Biomarker Data Structure Vol. 1.
Has every metric been assigned a verified source of truth?
Most teams treat this as documentation work. It isn't — it's a conflict-prevention exercise. For each metric, confirm in writing:
Which system is the authoritative source
Which system receives and normalizes it
Where it appears in dashboards and reports
What happens when two sources return different values
Until this is documented and agreed across teams, you will generate inconsistent results from the same participant data — often without realizing it.
Have you tested what happens when data is missing or arrives late?
Your team has probably defined a missing data policy. Now verify the system actually enforces it.
Run tests for:
A device that stops syncing for 48 hours
Data that arrives 3–5 days after collection
A participant who revokes app permissions mid-program
A device that reconnects after a long gap and sends backdated data
For each scenario: Does the system respond the way your policy says it should? Does the right person get notified? Does missing data get flagged — not silently dropped?
Programs that skip this step end up treating infrastructure gaps as clinical signals. For a detailed look at where remote health programs break down when data isn't flowing reliably, see Why Most Remote Monitoring Setups Don't Scale.
2. Verify devices work end-to-end for real participants
Your device list is defined and your eligibility criteria are documented. Now verify the experience actually works — from a participant's first tap to confirmed data in your system.
Have you tested the full connection flow as a participant, not as an engineer?
Engineering environments don't replicate participant conditions. Test the complete flow on a consumer device, with a fresh account, under realistic conditions:
Account creation and consent
Device or platform connection and permission selection
First synchronization — and how the participant knows it worked
Reconnection after permissions expire
What happens when a participant changes phones
What happens when a participant replaces their wearable
The most common failure point isn't the integration — it's the participant not knowing whether it worked and having no clear path to fix it when it didn't. For context on what makes device-level failures particularly hard to anticipate, see The Real Challenges of Wearable Data: From Access to Trust.
Can your support team resolve the most likely failures without escalating every one?
Don't just write the support documentation — test it. Run the five most likely failure scenarios with your actual support team, not with engineers:
Device not appearing as supported
Sync not triggering after connection
Permissions missing after an OS update
Participant changed phones and lost their connection
Data visible on the device but not appearing in the program
If support needs to escalate all of them, you don't have a support process — you have a dependency on engineering. Fix that before launch, not during it.
3. Verify workflows are operational — not just documented
Documented workflows are assumptions. Verified workflows are tested processes.
Does every data signal connect to a tested response path?
Your team has mapped which metrics to monitor and what to do when a threshold is crossed. Now verify that when that threshold is crossed in a real test, the right person knows about it and knows what to do.
For each alertable signal, confirm:
The threshold triggers as expected under test conditions
The alert routes to the correct role
The person in that role knows the expected response
The response is documented somewhere they can find it
The alert doesn't fire repeatedly for the same condition
A metric without a verified response path is noise, not a workflow.
Have you stress-tested your alert logic against over-notification?
Poorly calibrated alerts are one of the fastest ways to lose clinical buy-in. Before launch, run your alert configuration against a representative sample of historical or synthetic data.
Ask: How many alerts fire per participant per day under normal conditions? Are there signals that generate alerts consistently but never require action? Can a care team member realistically act on the volume your configuration produces?
If the answer to the last question is no, recalibrate before launch — not after the first week of complaints. For a reference on how wearable data fits into clinical operations and where friction typically appears, see How to Integrate Wearables into Clinical Workflows (Without Breaking Your Stack).
Have you tested exception scenarios — not just standard flows?
Standard QA rarely catches the scenarios that create the most operational problems at launch. Run through these deliberately and document the expected response for each:
A participant who enrolls but never connects a device
A participant who is active for two weeks, then disconnects entirely
A clinical team member who disagrees with an automated flag
An alert triggered at 2 AM on a weekend
A consent withdrawal mid-program
A third-party integration that goes down during business hours
Does every workflow have a named, confirmed owner — not just a role?
Assigning ownership to a role is not the same as a person knowing they own it. Before launch, confirm that each individual — not just their team — knows they are responsible, knows their escalation path, and knows the expected response time.
Do this explicitly for: participant onboarding, device support, data quality monitoring, clinical review, escalation, consent management, and reporting.
4. Verify reporting produces results you can stand behind
Your reporting framework is designed. Now verify it produces numbers that are accurate, reproducible, and agreed upon before anyone sees them for the first time.
Have you run a full reporting test on synthetic or pilot data?
The first time your reports run should not be during a stakeholder review. Before launch, run the complete process — including eligibility rules, exclusion logic, metric calculations, and output formatting — using test participants or synthetic data.
Confirm:
The included population matches what your eligibility rules define
Exclusion criteria are applied consistently
Date ranges are correct
Missing data is handled the way your policy specifies
The same inputs produce the same outputs every time
If your reports can't pass a reproducibility test before launch, they won't hold up to scrutiny after it.
Does every metric have one agreed-upon, documented definition?
This is where reporting breaks down most quietly. "Active participants," "engaged users," and "compliant participants" each sound like a single number. In practice, different teams often calculate them differently.
Before launch, create a data dictionary that specifies — for every reported metric — the exact population, time window, data source, calculation method, and the team responsible for it. Then verify the definition with every team that will use the report. If there's a disagreement, resolve it now, not when two teams show up to a meeting with different numbers.
For a full breakdown of which outcomes to track for ACCESS programs and the calculation logic behind each one, see How to Track Outcomes for ACCESS: BP, HbA1c, Activity, and More.
Can you monitor program health in real time between formal reports?
Formal reports follow a fixed schedule. Between those cycles, your team needs operational visibility. Confirm you have a live dashboard showing at minimum:
Enrollment status and device connection rates
Participants with data gaps exceeding your defined threshold
Open alerts and their age
Technical failures or integration errors
Workflow completion rates
If a participant's device has been disconnected for five days, your team should know before the next weekly report — not because of it.
5. Verify consent and governance have been tested — not just written
Consent and data governance are compliance checkboxes on paper. They are operational risks at launch.
Before go-live, verify that:
Consent language has been reviewed by legal and approved in final form
The consent withdrawal flow has been tested end-to-end, including what happens to participant data after withdrawal
Role-based access controls have been tested — not just configured
The process for deleting or disconnecting participant data works as documented
Your security incident procedure has at least one named person who knows they own it
These should be reviewed jointly by product, legal, compliance, clinical, and engineering — not passed sequentially between them.
6. Verify your team is ready — not just trained
Product training and operational readiness are not the same thing. Test your team with realistic scenarios, not product walkthroughs.
Every person with an active role in the program should be able to answer — without looking it up:
What is this program trying to measure, and by when?
What data am I responsible for acting on?
What does an alert mean, and what do I do when I see one?
What are the limitations of the data I'm working with?
Who do I escalate to, and what's the expected response time?
If there's meaningful uncertainty in those answers, you have a training gap — and training gaps show up in the first week of a launch.
The final go-live gate
Use this as your last check before the first participant connects. Every item should have a verified "yes," a named owner, and documented evidence.
Data
☐ All required metrics are arriving in a validated, consistent format
☐ Every metric has a documented, agreed-upon source of truth
☐ Missing and late data scenarios have been tested and respond as expected
☐ Data quality checks have been run and passed
Devices
☐ The full participant connection flow has been tested on a consumer device
☐ Support teams have been tested — not just trained — on the most likely failure scenarios
☐ Escalation paths for device issues are documented and confirmed
Workflows
☐ Every alertable signal has a tested, calibrated response path with a named owner
☐ Alert volume under normal conditions is within manageable range for the care team
☐ Exception scenarios have been run and documented responses confirmed
☐ Every workflow owner knows — by name — that they own it
Reporting
☐ Full reporting has been run on synthetic data and results are reproducible
☐ Every reported metric has one agreed-upon definition in writing
☐ A live monitoring dashboard is operational
Governance
☐ Consent and withdrawal flows have been tested end-to-end
☐ Role-based access controls have been validated
☐ Security incident ownership is confirmed
Team
☐ Every team member with an active role can answer escalation and data questions without looking them up
Any remaining unchecked item needs an owner, a mitigation plan, and a date. An unowned risk at go-live is not a risk — it's a guarantee.
From built to verified
The gap between a program that's been built and one that's ready to scale is almost always operational, not technical. The infrastructure works. The workflows are mapped. The data is flowing. But exception scenarios haven't been tested, ownership isn't confirmed, and the first real failure catches the team unprepared.
This checklist is designed to close that gap before it costs you.
For the foundational planning layer — what data infrastructure to build, what onboarding flows to design, and how to align reporting requirements before data starts flowing — start with What ACCESS Model Companies Need to Build Before Go-Live. And for why standardized data is the prerequisite that determines whether everything else holds, Why the ACCESS Model Needs Standardized Wearable Data is the right foundation.
ROOK provides the health data infrastructure ACCESS model companies need to connect, normalize, and deliver wearable data through a single API — so the layer that's hardest to verify is the one your team doesn't have to build from scratch.
