leave with: a claim map that separates performance, workflow and patient outcome
allow: 45 minutes with the appropriate domain lead
start with the claim you need to support
our founding perspective began with a genetics business moving from an idea, through the lab and into the world. that experience shaped a question we bring to new ventures: what must happen between a promising technology and a useful result for someone?
describe the intended user, setting and specific purpose of the product. separate technical performance from whether the product changes a decision or improves an outcome. do not treat the size of a dataset, a demonstration or reported user reach as proof of every intended benefit.
map the people around the service
the person who benefits, the professional using the result, the purchaser and the organisation responsible for delivery may be different. identify each role and where accountability lies. explain how the product fits into an existing workflow and what happens when information is uncertain, unavailable or wrong.
for any health claim, determine the evidence and specialist oversight appropriate to the actual product and jurisdiction. a commercial screening discussion cannot establish clinical validity, regulatory status or suitability for a patient.
build an evidence plan around the intended use
as a reference for digital-health evidence planning, the uk’s nice framework distinguishes different technology functions and the evidence expected for their claimed benefits. it is useful context for asking better questions, not proof that a product meets south african requirements. read the nice evidence standards ↗
- which exact claim is being tested, for which people and in which setting?
- what comparison and outcome would make the result meaningful?
- what limitations, uncertainty and potential harms need to be visible?
- who is qualified to design, assess and oversee the evidence work?
- what could change when the service moves to another population or delivery setting?
ask who can sustain the benefit
identify who has a reason and a practical ability to pay, what recurring value they receive and the full work needed to deliver it. consider implementation, support, responsible handling of information and the people involved in the service. a software interface does not make these obligations disappear.
for lab2sky, the opportunity is a business that can carry a substantiated benefit beyond its starting point. at an early stage we look for an honest evidence plan; as a business matures, its claims need stronger support. this is our venture-assessment perspective, not medical advice or a product endorsement.
three claims that need different evidence
worked example · illustrative
a fictional digital-health service claims it can process information accurately, help a professional make a decision sooner and improve an eventual health outcome. those are three different claims. a demonstration of faster processing does not establish that the recommendation is accurate, that a professional uses it appropriately or that a patient benefits.
what this changes: the team maps each claim to the intended population, setting, comparison and responsible specialist. an administrative pilot is not relabelled as clinical validation. uncertainty, failure handling and potential harm remain visible throughout the evidence plan.
put it to work
allow: 45 minutes with the appropriate domain lead
leave with: a claim map that separates performance, workflow and patient outcome
- write the exact intended use, user, population and setting. distinguish an administrative function from a clinical claim.
- map each claimed benefit to the evidence currently available, its limits and the evidence still required.
- identify who is qualified to design and review the next study and assess requirements in the actual jurisdiction.
- describe the delivery workflow, failure response, payer and cost of responsible support. test whether the business can sustain that work.
these are lab2sky’s working questions and assessment approach. examples are illustrative unless explicitly identified otherwise. how we write our guides