Document Prescription Use Case

[jandrieu]

In issue # 12 of the VC-Data-Model @agropper wrote:

Privacy engineering can help sort through the different aspects of privacy in a use case. I’d like to relate this issue to the specific prescription use case that I maintain.

The highest privacy goal of this use-case is to maintain the self-sovereignty of the physician-patient relationship in the face of regulatory requirements. Specifically, we seek to enable a transaction system for a prescription that does not depend on institutional trust as an identity provider for the physician and the patient together. The privacy benefit is the ability for the physician and the patient to interact without having that interaction monitored by an intermediary institution such as a hospital. This opportunity for an un-mediated patient-physician relationship was common with paper prescriptions and has been lost in the transition to electronic health records.

In order to achieve this privacy goal, the role of the hospital intermediary as a combined root of trust for patient ID, physician ID, physician attribute, and transaction auditability needs to be distributed among various substitutable actors with a minimum of correlation risk across the actors.

Working backward, the physician claim must be verified against a directory operated by an issuer that has no role relative to the issuance of the physician ID or any role whatsoever relative to patient ID. The reason for this is that the directory operator does not want any responsibility for security breaches of any patient information and has no interest in sharing an identity provider used by the patient. For the physician ID, the directory provider does not want to bear responsibility for identity proofing the physician. Cost-effective operation of directories requires they trust identity providers. The directory operator is merely a relying party, using whatever identity the physician chooses. The federation implied by the physician’s IDP is responsible for identity proofing to a level adequate for prescribing controlled substances per DEA and access to patient records under state and federal privacy mandates.

The physician ID used to maintain the physician claim must be non-repudiable and able to:

Sign updates to the physician directory operated by the issuer prescription in an auditable way (e.g.: associated with a blockchain timestamp).

Sign a prescription for a specific patient in an auditable way.

The patient identity (but not necessarily the patient ID) captured in the prescription and presented to the pharmacy must be correlated in a non-repudiable way. The pharmacy transaction must be auditable.

The pharmacy must be able to verify the physician claim in a way that does not allow the pharmacy to correlate other transactions by the same physician. (The sale of physician prescribing info has been challenged in high courts and is allowed as free speech by the pharmacy. This causes a lot of privacy problems for the physician and the patient. It is the primary source of the huge data broker market in healthcare.)

The physician must be able to report the transaction to a (law-enforcement) registry that can track patient identity across different physician-patient relationships and physicians must be able to query this registry prior to issuing a prescription. The registry itself, as a law enforcement function, can have access to the identity of the physician and the patient. (These state-operated registries are called prescription drug monitoring programs.) The pharmacy must be able to verify that the prescription was reported to the registry (to keep the doctors honest). The pharmacy may have it’s own law enforcement registry reporting requirements but these are outside the physician-patient relationship privacy engineering issue.

Note that in most, maybe all, states, the pharmacy can deliver a prescription to the physician for the physician to distribute to the patient. In this somewhat inconvenient way, the privacy of the patient relative to the pharmacy can be absolute.

This issue moves my (@jandrieu) response to this use case repo:

Thanks for the example, @agropper. It's a solid example of where Verifiable Claims can help with privacy.

To help us move towards a more rigorous lexicon, I'd like to call this a "use domain" instead of a "use case." I'm hoping to establish a specific semantics for use cases:

A use case defines a specific value-creating transaction between an individual and the system.

A use domain defines a related set of use cases.

I'm still working through the best alternative language, but "use domain" or "domain of use" seems like a good way to describe this example, which include several transactions, as well as domain-specific non-functional requirements, such as both the correlatability and non-correlatability you outline.

From what I read, I tease out a few different transactions:

1. Issue prescription
2. Verify prescription
3. Present prescription
4. Audit pharmacy
5. Register prescription

There may also be transactions related to the credential that enables a doctor to prescribe as well as recording pharmacy interactions: requesting fulfilment of a prescription, fulfilling a prescription, etc., so we can understand the needs of the audit. As with many of these kinds of use, the trick is defining the coherent boundary so we can focus on the new and interesting bits. For example, one could discuss how all of the entities in the domain provision their credentials: the monitoring agencys, the pharmacies, the pharmacists, the insurance companies (surprisingly missing from your example). Clearly, taking some of these entities (and their credentialing) as a given greatly simplifies the documentation.

To try and tease out the correlatability:

Intended correlations:

1. The live person redeeming a prescription needs to be correlatable to the patient for whom the prescription was given, by the pharmacist, prior to distribution so that the medicine is given to the actual patient.
2. The patient needs to be correlatable to a singular legal person by the prescription drug monitoring program for the purposes of assuring that individuals are not getting multiple prescriptions by visiting multiple doctors. The physician needs to be able to query the program prior to issuing a prescription.
3. The physician and patients need to be correlatable across multiple prescriptions for physician audits.
4. A given prescription must be resolvable to a delivery address while preventing the pharmacy from correlating the doctor to the prescription. This resolution must be non-repudiable.
5. Upon delivery, a prescription must be correlatable by the issuing doctor to the patient

Blocked correlations:

1. The pharmacy must not be able to correlate the physician's prescriptions across different patients.
2. Someone who is not the intended patient must not be able to redeem a prescription (must not be falsely correlated as the patient).
3. The prescription may be redeemed at any pharmacy. There is no innate correlation between a given prescription and the pharmacy that fulfills it.

Do these transactions and correlations seem correct?

Questions:

1. If I assume for the sake of discussion that all of this information is stored in an effectively public repository--this assumption addresses both public ledgers and compromised data stores--then can we assume that certain information is encrypted for the intended recipient? For example is the prescription delivery address encrypted for a specific delivery service?

2. For correlation 3, who is doing the audit? How do we allow an audit without allowing the pharmacy to perform the same correlation? Are there baked in assumptions about where "auditable" data is stored that can be trusted to be secure from the Pharmacy? I don't think we care about pharmacies that are bad actors willing to hack a physician's database. For this use domain, it might be valuable to identify a strawman architecture that distinguishes who holds what data. I'm assuming that the monitoring program and the physician both have private data stores for audit purposes, while the rest of the data could be stored in a self-sovereign public ledger. (If insurance is involved, the pharmacy will probably need its own data store as well.) Or... is there a way that all of this information could be in a public data store?

3. For correlation 2, are we trusting the monitoring program to operate a secure, live system? Or is the goal to have that monitoring (and the doctor's query) based in a public ledger? In other words, along with question 2, can we clarify where, for this use domain, we need to trust a system (and its operator) with certain information and which systems we choose not to trust with certain information?

4. What about insurance companies? Are they an important part of the privacy engineering?

5. Does the pharmacy need to verify that the prescription has been registered with the monitoring program?

[jandrieu]

@agropper replied (on prior issue): Thanks @jandrieu You're structuring this is a useful way. The correlations and transactions seem correct.

Questions: 1 - Good question. I'm not sure what to say about encryption but I suspect security design will be evident as we go forward.

2 - I agree with your framing. I don't know the legal answer to who does routine audits. I would allow for a separate registry no matter what. The pharmacy is handling controlled substances and subject to audit by the DEA. I'm skeptical of storing anything other than timestamps in a public data store.

3 - Good point. I think we need to do both. Keep in mind that some states will require the querying physician to have a relationship with the patient and others will simply require they be a licensed practitioner.

4 - The insurance may need to be consulted for decision support and/or costs before the prescription is finalized by the physician. The pharmacy also needs insurance access, unless the patient pays cash - which is allowed by law. Once we create the "use domain" representation, we would do well to add insurance.

5 - Maybe. The monitoring programs are run at state level and can include the pharmacy. some states also mandate that physicians check the registry before prescribing controlled substances and we could imagine transactions that warn the physician or regulators if this is not done.

[jandrieu]

Note: I changed this back to a "use case" instead of a "use domain" because I think that change in language is going to be impossible to win.

Instead, when the distinction I was pushing for is relevant, I'll use the term "aggregate" to refer to multi-transaction use cases and either "discrete" or "singular" to refer to use cases describing a single value-creating transaction.

[jandrieu]

Use case specific notes from our conference call today.

We used NIST's privacy engineering perspective to flesh out this use case and better understand the privacy implications. http://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf

The goal is to distill this use case down to a single context so that we can understand the data actions within that context. Such actions may cross trust boundaries between domains and will often involve different data sets.

ACTORS

These are the actual human beings who will be interacting with systems throughout this use case.

1. physician
2. pharmacist
3. patient
4. auditor

INHERENT DOMAINS

These are the secure domains with coherent trust boundaries. We assume that within a domain, information is equally accessible to all with access to the domain and that no information leaks from the domain: all information that crosses domains is explicit. In other words, for privacy analysis, domains are secure.

1. Physician's Information System
2. Pharmacy's Information System
3. Patient's Information System
4. State Prescription drug monitoring system (PDMP)

EXTERNAL DOMAINS & ENTITIES

These are outside of any trust boundaries and while may be present, should not have access to private data.

1. Insurance provider's system
2. Delivery service
3. Pharmaceutical companies
4. Device manufacter
5. Marketing firms
6. Clinical trials system (learning medical system)
7. FDA (Adverse drug reports)

DATA

1. Prescription
2. Other prescriptions (inherent in the system, not necessarily linked explicitly)
3. Patient identity (traditional PII), including but not limited to a. name b. address c. age d. medical condition(s)

Core use case

The prescribing and fulfilment of a single prescription of a non-controlled substance for a single patient, paid for by the patient.

Variant use cases

1. Prescription is for a controlled substance
2. A delivery service delivers the prescription
3. A caregiver picks up the prescription
4. An insurance company is used to pay for the prescription
5. Adverse effects reported to FDA
6. Samples given by physician

Non-distinctive variant use cases

1. Payment by the patient using credit card, debit, or other means.

Questions

1. Use of term "Prescription" I sometimes use "prescription" to refer to the thing that fulfills it, e.g., the bottle of medicine, but I believe the term is better restricted to the Doctor's orders, e.g., as historically written on a piece of paper and given to the patient to give to the pharmacist. Is there better generic terminology for the stuff prescribed in the prescription?

2. Identifiers for authentication The original description included registries and perhaps implied fiat credentials for doctors. Are there external credentials or identifiers that are inherent in the use case?

Next step

Shawn Brooks re: NIST privacy engineering. Privacy worksheets.

[agropper]

To External domains and entities, I might add:

• Decision support service (e.g.: GoodRx) accessible to either the prescriber before the order is signed or the patient before or after the order is signed. This is a cousin to the formulary query that might be done against an insurance system but the decision support system should not be able to correlate the request to any particular patient or prescriber.

Question 1. I think it's useful to consider a prescription as a doctor's order that can be mediated or redirected, but not changed, by the patient subject of the order. This recognizes that the patient has some agency in the process.

Question 2. Not sure. I will check with an expert.

[jandrieu]

Ok. So, is there a generic term for the object of the prescription? When we say we go to the pharmacy to pick up a prescription, that's not quite correct, as we are actually picking up the medication (assuming a pharmacological prescription).

[ghost]

On Wed., 1 Feb. 2017, 4:34 am Joe Andrieu, notifications@github.com wrote:

Use case specific notes from our conference call today.

We used NIST's privacy engineering perspective to flesh out this use case and better understand the privacy implications. http://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf

The goal is to distill this use case down to a single context so that we can understand the data actions within that context. Such actions may cross trust boundaries between domains and will often involve different data sets. ACTORS

These are the actual human beings who will be interacting with systems throughout this use case.

1. physician
2. pharmacist
3. patient
4. auditor

Some controlled substances have a seperate process for providing approvals prior to specialised doctors being able to prescribe.

Also, specialists providing the means for GP's to write repeats using the same authorisation, et.al.

INHERENT DOMAINS

These are the secure domains with coherent trust boundaries. We assume that within a domain, information is equally accessible to all with access to the domain and that no information leaks from the domain: all information that crosses domains is explicit. In other words, for privacy analysis, domains are secure.

1. Physician's Information System
2. Pharmacy's Information System
3. Patient's Information System
4. State Prescription drug monitoring system (PDMP)

EXTERNAL DOMAINS & ENTITIES

These are outside of any trust boundaries and while may be present, should not have access to private data.

1. Insurance provider's system
2. Delivery service
3. Pharmaceutical companies
4. Device manufacter
5. Marketing firms
6. Clinical trials system (learning medical system)
7. FDA (Adverse drug reports)

DATA

1. Prescription
2. Other prescriptions (inherent in the system, not necessarily linked explicitly)
3. Patient identity (traditional PII), including but not limited to a. name b. address c. age d. medical condition(s)

Core use case

The prescribing and fulfilment of a single prescription of a non-controlled substance for a single patient, paid for by the patient. Variant use cases

1. Prescription is for a controlled substance
2. A delivery service delivers the prescription
3. A caregiver picks up the prescription
4. An insurance company is used to pay for the prescription
5. Adverse effects reported to FDA
6. Samples given by physician

Non-distinctive variant use cases

1. Payment by the patient using credit card, debit, or other means.

Questions

1.

Use of term "Prescription" I sometimes use "prescription" to refer to the thing that fulfills it, e.g., the bottle of medicine, but I believe the term is better restricted to the Doctor's orders, e.g., as historically written on a piece of paper and given to the patient to give to the pharmacist. Is there better generic terminology for the stuff prescribed in the prescription? 2.

Identifiers for authentication The original description included registries and perhaps implied fiat credentials for doctors. Are there external credentials or identifiers that are inherent in the use case?

Next step

Shawn Brooks re: NIST privacy engineering. Privacy worksheets.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opencreds/vc-use-cases/issues/38#issuecomment-276433882, or mute the thread https://github.com/notifications/unsubscribe-auth/AFdABoLovLn_5htgAI8IwyXcQprMcg4eks5rX3CqgaJpZM4LscFc .

[ghost]

Some Pharmacists also make things: https://en.m.wikipedia.org/wiki/Compounding

And/or specialise in different fields (ie: renal)

On Thu., 2 Feb. 2017, 3:06 am Timothy Holborn, timothy.holborn@gmail.com wrote:

On Wed., 1 Feb. 2017, 4:34 am Joe Andrieu, notifications@github.com wrote:

Use case specific notes from our conference call today.

We used NIST's privacy engineering perspective to flesh out this use case and better understand the privacy implications. http://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf

The goal is to distill this use case down to a single context so that we can understand the data actions within that context. Such actions may cross trust boundaries between domains and will often involve different data sets. ACTORS

These are the actual human beings who will be interacting with systems throughout this use case.

1. physician
2. pharmacist
3. patient
4. auditor

Some controlled substances have a seperate process for providing approvals prior to specialised doctors being able to prescribe.

Also, specialists providing the means for GP's to write repeats using the same authorisation, et.al.

INHERENT DOMAINS

These are the secure domains with coherent trust boundaries. We assume that within a domain, information is equally accessible to all with access to the domain and that no information leaks from the domain: all information that crosses domains is explicit. In other words, for privacy analysis, domains are secure.

1. Physician's Information System
2. Pharmacy's Information System
3. Patient's Information System
4. State Prescription drug monitoring system (PDMP)

EXTERNAL DOMAINS & ENTITIES

These are outside of any trust boundaries and while may be present, should not have access to private data.

1. Insurance provider's system
2. Delivery service
3. Pharmaceutical companies
4. Device manufacter
5. Marketing firms
6. Clinical trials system (learning medical system)
7. FDA (Adverse drug reports)

DATA

1. Prescription
2. Other prescriptions (inherent in the system, not necessarily linked explicitly)
3. Patient identity (traditional PII), including but not limited to a. name b. address c. age d. medical condition(s)

Core use case

The prescribing and fulfilment of a single prescription of a non-controlled substance for a single patient, paid for by the patient. Variant use cases

1. Prescription is for a controlled substance
2. A delivery service delivers the prescription
3. A caregiver picks up the prescription
4. An insurance company is used to pay for the prescription
5. Adverse effects reported to FDA
6. Samples given by physician

Non-distinctive variant use cases

1. Payment by the patient using credit card, debit, or other means.

Questions

1.

Use of term "Prescription" I sometimes use "prescription" to refer to the thing that fulfills it, e.g., the bottle of medicine, but I believe the term is better restricted to the Doctor's orders, e.g., as historically written on a piece of paper and given to the patient to give to the pharmacist. Is there better generic terminology for the stuff prescribed in the prescription? 2.

Identifiers for authentication The original description included registries and perhaps implied fiat credentials for doctors. Are there external credentials or identifiers that are inherent in the use case?

Next step

Shawn Brooks re: NIST privacy engineering. Privacy worksheets.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opencreds/vc-use-cases/issues/38#issuecomment-276433882, or mute the thread https://github.com/notifications/unsubscribe-auth/AFdABoLovLn_5htgAI8IwyXcQprMcg4eks5rX3CqgaJpZM4LscFc .

[jandrieu]

We have H.1 Prescribing as one of our use cases. I'd personally love to see the additional detail proposed here. I'm just not sure where it would go.

[agropper]

The https://github.com/WebOfTrustInfo/rwot7/blob/master/draft-documents/Agent-Communication-Protocols.md paper provides additional detail including the credential of the issuer and revocation to avoid double spend of the prescription document. Im not sure if and where to add more details.

[jandrieu]

@agropper Are you still interested in getting this into the use case document?

We sent a call for input to the mailing list https://lists.w3.org/Archives/Public/public-vc-wg/2023Apr/0000.html and if you're still interested, we'd consider something on this topic.

The easiest option would be create a new issue using one of our templates.

[agropper]

I'm inclined to leave this issue in its current state and see if any community chooses to pay some attention to it at some point in the future.

I hope whatever document is being created, leaves a link to it as a footnote or appendix.

In general, I have found a lack of interest in working on real world use domains that involve delegation as part of a solution. For example, I also wrote up a Cruise Ship Use Case and multiple comments around public notaries.

Standards are essential for human rights but I have yet to find a community of technical experts willing to work on human rights first while ignoring the business model issues of the participating sponsors.

As we move to digitize every aspect of human life and then blend and amplify it with machine learning, we have an unmet need to identify and expand digital public goods. W3C and related standards communities seem inadequate to create the next wave of public goods.

[jandrieu]

Ok. We've had no further action on this in over a month.

Marking pending close.

[jandrieu]

Continued lack of engagement, closing.