Stream: fmg
Topic: Converting Profile to Resource
John Moehrke (May 27 2016 at 17:33):
During the CBCC meeting on Privacy Consent Directive we discussed my proposal to switch our work to a Resource, rather than a profile on a resource. This has many advantages in my view, and I understand by overwhelming positive feedback both openly and directly. The committee would like to be sure that they would be allowed to make this switch at this time, and not need to write a new PSS. I asserted that the PSS is about the use-case output, not the technical approach. However the committee would like to control this risk by asking FMG if it would be okay if they were to switch without writing a new PSS and thus hitting PSS deadline problems.
John Moehrke (May 27 2016 at 17:35):
Supporrting evidence: I have prototyped the first draft of this Consent (Privacy authorization focused). It is in the build today as "Consent". and I explained my methodology on my blog http://healthcaresecprivacy.blogspot.com/2016/05/start-at-consent-as-fhir-resource.html
John Moehrke (May 27 2016 at 17:37):
separate concern raised by Paul about what happens in the future when someone wants to handle the other consents (e.g. advanced directives). I assert this is independent, as the current PSS has always been focused only on Privacy consent. That is all they intend, and all the SME they have. I bring it up here for completeness.
John Moehrke (May 27 2016 at 18:29):
PSS Project 1130 http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1130
John Moehrke (May 27 2016 at 18:31):
Profile/Resource proposal -- Note originally written as Resource proposal -- http://wiki.hl7.org/index.php?title=ConsentDirective_FHIR_Resource_Proposal
Grahame Grieve (May 27 2016 at 21:07):
I agree that the project proposal is about the intent/use cases, and that changing from a profile to a resource does not require a new project (but does require FMG resource proposal)
Grahame Grieve (May 27 2016 at 21:08):
with regard to Paul's point, I think that would apply whether it's a resource or a profile
Grahame Grieve (May 27 2016 at 21:09):
- will it change the profile, or be a new profile.. same question if it's a resource
John Moehrke (May 27 2016 at 21:13):
The wiki proposal is both... meaning I don;t think the wki based proposal is decidedly a profile or resource. We often discusss in FMG that changes after approval of proposal will happen and dont rquire the wiki proposal to be modified...
Grahame Grieve (May 27 2016 at 21:27):
I think that elevating a profile to a resource should specifically require FMG approval as a resoure, but not vice versa, on the grounds that there's extra considerations for a resource
John Moehrke (May 27 2016 at 21:28):
fair... from a process perspective what is needed to cause that approval to happen? Is there a June 1st deadline?
Grahame Grieve (May 27 2016 at 21:43):
That I'm not sure about
Lloyd McKenzie (May 27 2016 at 23:32):
We'd need to re-visit the resource proposal. But given that most of the WG thought it should be a resource when it was originally submitted, I doubt it will be an issue. If you can make the deadline, great. But given that this is existing approved scope and we don't have to worry about whether it should or shouldn't be part of core, I don't think we'd let a missed deadline get in the way of the change occurring. While I recognize that the scope, thus far, has been limited to privacy authorization focused consents, if the resource gets stripped down to the core components (what's being consented to, who's consenting, etc.), my suspicion is that the resource could easily support other types of consents. The driver for whether one resource or multiple resources makes sense here is whether implementers typically store that information together or separately.
John Moehrke (May 28 2016 at 12:28):
Consents other than Privacy have been scoped out as they are not the priority. I also suspect they will fit, but bringing them in will only cause more churn and bring in more risk. Can we please agree with the workgroup to focus on Privacy consents?
Lloyd McKenzie (May 28 2016 at 14:47):
I think scoping down is the mistake. If you set the scope large, then the 80% tends to be simpler. By focusing on a narrow use-case, it's easier to bring in edge case stuff. In the end, the resource needs to reflect the full scope.
Grahame Grieve (May 29 2016 at 06:29):
Agree about the effect of scope, but I think most people would argue the other way as a consequence
Grahame Grieve (May 29 2016 at 06:29):
given where we are overall, I agree with john: let's keep the scope as narrow as we can
Lloyd McKenzie (May 29 2016 at 14:55):
Well, right now the scope is narrowed to patient consents for humans handled by very sophisticated consent management systems - which means there are both constraints and core elements that don't make sense for the long-term future of the resource.
John Moehrke (May 29 2016 at 16:26):
Lloyd please be specific. Your perspective is not obvious. The consent use-cases are not just for sophisticated consent management systems, it degenerates nicely to the simple indicator of opt-in, opt-out, none.. We just want also to support opt-in with some reasonable exceptions, and opt-out with some reasonable exceptions. Where these exceptions are only those currently implemented: List of objects, List of authors, List of recipients, List of Organizations, List of purposeOfUse, and Date Range. --- This scope is however not properly said, but I would be glad to indicate it or a sub-set as the goal. I suspect you need to participate and show us the error that you see and we do not. -- Don't assign to malice what can more easily be explained by ignorance.
Lloyd McKenzie (May 29 2016 at 16:55):
But resource designs aren't supposed to degenerate, they're supposed to build. The base resource should only include what everyone needs. The sophisticated stuff should be extensions.
John Moehrke (May 29 2016 at 17:20):
You are misreading my words. I am using the words in the same way that one might say that they only need Patient resource to hold the name, and phone number; that they don't need Patient resource to hold all that other optional stuff that is in Patient. Else Patient would be nothing but the basic resource and all elements would be extensions... that is surely not what you wold want, right?
Lloyd McKenzie (May 29 2016 at 17:33):
Well, the question is how many systems support sending things like "here's the full text of the consent document" or "here's all the customizations of what permissions the patient is granting". I think that's a rather small percentage of systems. I don't think that level of sophistication is super common in the U.S. and I think it's much rarer elsewhere.
Lloyd McKenzie (May 29 2016 at 17:34):
Detailed fine-grained control is typically too hard to manage from an "informed" consent perspective - too easy for the patient to get it wrong or to get overwhelmed.
John Moehrke (May 29 2016 at 22:31):
As I said in the email. I welcome others to break the tie. You and I clearly have very different views of the marketplace.
John Moehrke (May 29 2016 at 22:33):
Further, you have made it clear that the 80% rule is not used for acceptance of a resource, that only requires 1%. So I assert that all those systems that you are referring to are outside the 1% that I am looking at as those driving for a Consent Resource. So I only need to show 80% within that %1 percent that want the resource.
Lloyd McKenzie (May 29 2016 at 22:54):
At least 1% of systems that will use FHIR will use a Consent resource. All systems that will use Consent (including those that will only capture Patient, ConsentType & Date form the denominator for determining the 80%.
Lloyd McKenzie (May 29 2016 at 22:55):
We can't exclude some types of consent because we want a more complicated resource. That's why I'm not comfortable with a narrow scope. If the scope is broad (as I think it eventually ought to be), then the 80% is much more clear.
Grahame Grieve (May 29 2016 at 23:06):
I think you're thinking the wrong way around - the questions about scope are about usage. The other kinds of consent you can think of - are they overlapping in operational usage? what are the other scopes?
Lloyd McKenzie (May 29 2016 at 23:30):
I agree we need to determine if consents for procedures are typically stored in the same space and use the same interfaces as consent for information disclose. All types of information disclosure are certainly in the same space though - we don't want systems to have to query one resource for "light" constraint information and a different one for more sophisticated consents.
John Moehrke (May 30 2016 at 01:17):
Adding Consent for procedure or Advanced Directives is a very big scope change; and one the committee has never accepted in their scope.
Lloyd McKenzie (May 30 2016 at 02:20):
Well, the acceptance of the committee is less important than the needs of the implementer community. The question is whether implementer typically handle "consent for procedures" and "consent for information disclosure" via the same underlying structures. If they do, then FHIR should align with that - and it's our job to manage the responsible and involved work groups to allow that to occur. We need to get an answer to the question of what the implementers want, but I'm not sure what the best way is to get that answer.
Grahame Grieve (May 30 2016 at 02:38):
I'm just looking at Ioana's email - it looks like her work is not about consent to sahre, but about consent to do (or take part)
John Moehrke (May 30 2016 at 02:54):
The difference we (CBCC and Security) have identified is the Privacy Consents are a set of authorizations (denials) that an Access Control engine would enforce. The other consents are not anything that an Access Control engine would touch. So the distinction is relative to Access Controls, not because they are instructions given by a patient. This is the distinction we have used. It is a significant difference.
John Moehrke (May 31 2016 at 20:20):
Please add this to the FMG meeting agenda. The CBCC committee has agreed to the Privacy Consent Directive as a Resource. This is not an agreement to stop work on the Privacy Consent Directive IG as a Profile on Contract. That step may, or may not, come later. The Resource proposal is the very same resource proposal we approved May 2014 http://wiki.hl7.org/index.php?title=ConsentDirective_FHIR_Resource_Proposal; where that resource proposal got converted into a Profile in committee work, that Profile got converted into an IG in DSTU2 when the concept of Profile got improved to IG. So there is no new concept, there is just renewed interest in developing the original proposal as a originally proposed Resource. Further the following - unresolved - ballot comments have asked for this as a Resource vs Profile/IG - GF#5524, GF#5525, GF#6284, GF#6285, GF#7533, and GF#7871. Note that this Resource proposal continues to have the scope originally proposed to only address Privacy Consent, and not include other types of Consent such as Consent-to-treat, or Advanced Directives. These other types of Consent might be supported now or in the future, but are not part of the scope due to the subject-matter-expertise of the CBCC and Security workgroups; and these other consent types would not be enforced by an Access Control engine.
Grahame Grieve (May 31 2016 at 23:14):
thanks John. question for FMG: who is the right group(s) to take on consent to treat and advance care directive? I would propose leaving the scope limited for now, and then when those groups take on the requirements analysis, then we can decide whether that's the same resource or something else
Lloyd McKenzie (Jun 01 2016 at 01:43):
Ok, but we can't progress past FMM3 until the analysis has been done.
John Moehrke (Jun 01 2016 at 12:58):
why is FMM3 a blocking point? I don't see any rules in FMM3 of FMM4 on this topic.
John Moehrke (Jun 01 2016 at 13:01):
I might predict that if we could get this Privacy Consent through to a bit more completeness; that the CBCC committee might be willing to take up the other Consents, and might find that the structure works.... I am pushing back because it is hard enough to get a focused scope done because this is a very difficult topic filled with both technical, ethical, legal, and emotional baggage. The focus of the committees (CBCC and Security) have been Privacy for the past 5 years, so I would like to get a basic solution built on that experience and focus.
Lloyd McKenzie (Jun 01 2016 at 17:06):
Coverage across full scope. If the full scope isn't clear (i.e. the FMG thinks there may need to be a need to broaden it), then you can't possibly be certain the resources has been tested across its full scope
John Moehrke (Jun 15 2016 at 00:33):
Can we please discuss consent resource. I believe that it is simply acceptance of the same use-case we originally agreed to for CBCC to do that CBCC converted into the Privacy Consent Directive IG. So I want confirmation that CBCC can go forward with this. They have proposed it last week, we didn't get to it last week FMG. -- Discussion points: 1. governance status of PCD IG vs Resource; 2. continue focused on Privacy Consent Directive with expectation that future might expand scope to other 'consent' types (Advanced Directives, consent to treat, consent to research, etc). 3. independent of consent tracker discussion although I argue that the consent tracker can be accomplished with the same resource.
Last updated: Apr 12 2022 at 19:14 UTC
