Health products must make the boundary between information and care unmistakable
Health software can change who notices a condition, how evidence is interpreted, who may decide and what action is recorded.
- Health software
- Care products
- AI interaction
The domain is wider than one clinical workflow
| Product subdomain | Dominant product condition | Decisions that carry more consequence |
|---|---|---|
Patient access and engagement | A person must understand records, tasks and choices outside a clinical setting | identity, consent, comprehension, accessibility and escalation |
Care coordination and operations | Several roles act on one care journey with different authority | assignment, hand-off, acknowledgement, exception and history |
Clinical workflow and decision support | Evidence informs a qualified decision in a time-constrained environment | provenance, uncertainty, alert priority, override and accountability |
Research, scientific learning and evidence platforms | Complex material must remain discoverable and interpretable without losing source context | taxonomy, retrieval, evidence quality, citation and learning progression |
Devices and digital therapeutics | Use error can affect safety or effectiveness | intended user, use environment, risk control and validation |
Health administration, payer and benefits products | Eligibility, documentation and policy become operational workflow | status, rule explanation, appeal, correction and audit trail |
These areas share sensitive information and consequential decisions, but they do not share one regulatory or clinical model. The product category, users, use environment and authority boundary have to be understood before the interaction model can be trusted.
The care-information-authority model
A dependable health product keeps four layers connected without collapsing them:
- 01
Evidence
observation, measurement, record, source, date, coverage and missing data.
- 02
Interpretation
summary, classification, recommendation, uncertainty and reason.
- 03
Authority
person or role permitted to review, decide, approve, override or escalate.
- 04
Action
order, intervention, communication, follow-up, completion and correction.
Ambiguity between these layers creates product risk. A summary may look like a diagnosis. A recommendation may look approved. A completed form may look like completed care. The interface should identify the transition, the responsible role and the record created by the action.
What kind of consequence can this screen create?
| If the product can | The design must make visible |
|---|---|
inform | source, recency, completeness and limitations |
recommend | basis, uncertainty, intended user and alternatives |
request approval | approver, decision criteria, pending state and expiry |
trigger an action | scope, consequence, reversibility and confirmation |
record care | author, timestamp, amendments and retained history |
escalate | threshold, recipient, urgency and what happens while waiting |
If one transition is currently hard to explain, approve or recover from, a bounded review can locate whether the problem sits in evidence, interpretation, authority or action.
How Tcules shapes the product
The work begins with the real care or operating pathway, not a screen inventory. Tcules maps the people, information, decisions, hand-offs and exceptions; identifies where product state can diverge from real-world state; and decides what must remain inspectable after an action.
Research and modelling can continue into workflow design, prototyping, accessibility, design systems, AI interaction, frontend and backend implementation, integrations, QA or a defined product slice, depending on the agreed scope.
For higher-consequence products, evaluation should reflect intended users, use environments and use-related risks. The FDA's human-factors guidance for medical devices (opens in a new tab) makes that relationship explicit for medical devices. It should not be borrowed as a compliance claim for every health product.
Interoperability changes the experience as well. HL7 FHIR (opens in a new tab) defines a standard for electronic healthcare information exchange. A product still has to explain provenance, missing records, synchronisation, permissions and what a person can responsibly conclude from exchanged information.
AI changes where interpretation enters the workflow
AI can retrieve evidence, draft notes, summarise records, identify patterns and prepare next actions. The product decision is not simply whether a model can perform the task. It is where interpretation enters the workflow, how its basis can be inspected, which role may rely on it and how disagreement or correction changes the record.
For a representative care-coordination workflow, an AI-generated activity summary can remain separate from medication or clinical interpretation, show which records were included, reveal missing coverage and route consequential judgement to an authorised professional. The example demonstrates the interaction model; it is not presented as delivered client work.
When this expertise is useful
This work is useful when a health or care product has sensitive evidence, several roles, consequential transitions, interoperability constraints, recovery paths or AI entering interpretation and decision support.
A useful starting point is one workflow together with the people involved, the evidence they use, the decisions they are allowed to make, known exceptions and the system boundaries already in place. Tcules can then determine whether the first useful move is research, product modelling, an audit, design or agreed software delivery.
Start with one consequential health-product transition
Use one workflow, transition or evidence-to-action path where the current product makes authority, consequence or recovery difficult to understand.
Start with one consequential health-product transition
Use one workflow, transition or evidence-to-action path where the current product makes authority, consequence or recovery difficult to understand.