Consent architecture is not a single event. It is a course of events that need to be updated as the interaction with the individual evolves.
When I design consent processes, I build for a consistent structure that can be updated as the relationship with the individual changes. The three stages are scope, collection, and persistence. This order works well because each one depends on what the previous stage established. Get the sequence right and the architecture holds over time. Get it out of order and you have three components that coexist without actually working together.
Here is what each stage requires.
Scope
Scope defines what the organization is authorized to do with an individual’s information, and for what purpose. It has to be established first because collection and persistence are both downstream of it. Clear scope is what makes everything else meaningful.
A well-defined scope answers two questions plainly: what will this data be used for, and what will it not be used for. “Treatment, payment, and healthcare operations” is a legal category. It is not a scope definition. A scope definition names the actual uses in plain language and draws a real boundary around them. For health tech companies, that means accounting for every feature that touches PHI, including integrations and capabilities added after launch (because the scope written at company formation rarely reflects what the product actually does at 24 months). For provider organizations, it means keeping the notice of privacy practices current with what the organization actually does, not just what it intended to do when the notice was drafted.
The right question to ask about scope is not “do we have one?” It is “is ours specific enough that someone outside our organization could look at any given data use and tell, without asking us, whether it falls inside or outside our authorization?”
Collection
Collection is the act of obtaining genuine, informed consent from the individual. Genuine is the operative word. A signature is evidence that a collection moment occurred. Comprehension is what makes it consent.
The standard I design toward is straightforward: a person who went through the consent process yesterday should be able to tell a family member, in plain terms, what they agreed to. That requires that the collection moment be timed to when the data use is actually relevant to the individual, not to when it is convenient for the workflow. It requires that the language be plain enough to be understood, not dense enough to be defensible. And it requires that the process, whether that is an intake form in a clinical setting or a consent flow in a digital product, be designed to support comprehension rather than optimize for completion.
For providers, that often means rethinking what gets handed to a patient at intake and when. For health tech companies, it means treating the consent flow as something the user should actually read, not a screen to clear before reaching the product.
The evaluation question for collection is “does our process make comprehension possible, or does it make completion easy?”
Persistence
Persistence is what keeps the architecture honest over time. It is the stage that connects what the individual agreed to with what the organization is actually doing with their data, on an ongoing basis.
A well-built persistence layer does three things. It maintains a current record of what consent has been collected and what it covers. It maps new data uses, integrations, and capabilities against existing consent records as they are added. And it surfaces the gap to the individual and captures updated consent before the new use begins, not after.
This is where the architecture has to stay connected to the product roadmap. For health tech companies, that means building a mechanism that flags consent implications when new features or integrations are scoped, not during legal review six months later. For provider organizations, it means having a process for consent refresh when the organization adds a service line, enters a data-sharing arrangement, or changes how existing data is used.
Persistence answers the question that scope and collection cannot: not just what the individual agreed to, but whether what you are doing today is still covered by it.
The Shared Obligation
Provider organizations and health tech companies operate with different regulatory profiles, different user populations, and different risk exposures. The architecture requirement is the same. Scope establishes the authorization. Collection produces genuine understanding of it. Persistence keeps the two aligned as both the organization and the individual’s relationship with it evolve.
Built in that sequence, consent architecture does what it is supposed to do: it creates a living record of what individuals have actually agreed to, not just a trail of signatures and clicks.
Post 1 of a series on consent architecture and privacy program design.