Stream: implementers
Topic: Consent Directive
Mohammad Jafari (May 10 2016 at 18:13):
It seems that there has been a few parallel efforts for modelling consent directives as a contract resource. As the Security WG is going to discuss this, I'm starting this thread to ask everyone who has done something similar to share it here.
Grahame Grieve (May 10 2016 at 18:14):
I create a consent record for each time a smart on fhir login happens on my machine. here's an example:
Grahame Grieve (May 10 2016 at 18:14):
http://fhir3.healthintersections.com.au/open/Contract/3/_history/1
Grahame Grieve (May 10 2016 at 18:15):
frankly, I found the existing ConsentDirective document confusing and/or irrelevant. And it basically didn't help me at all
Grahame Grieve (May 10 2016 at 18:16):
the WG claims that a profile on contract is appropraite - but the profile is entirely useless. I can't tell whether that's because it's not properly executed, or because it shouldn't be a profile.
Grahame Grieve (May 10 2016 at 18:16):
if a consent directive is going ot be based on a contract - a notion that makes sense - I would have thought it could reference one
Drew Torres (May 10 2016 at 18:38):
This is something we are looking to accomplish as well. I was looking at the consent directive for some general guidelines and agree with what Grahame stated. Our use-case is MU3 specific for the patients or proxies using apps, and granting those apps access to their health data.
Drew Torres (May 10 2016 at 18:38):
Is there a specific quarter security may pick this conversation up?
Drew Torres (May 10 2016 at 18:40):
I was in Salon Garcia Lorca waiting for the CBCC/security session to talk about it, but there was no one present.
Mohammad Jafari (May 10 2016 at 18:46):
@Andrew Torres We are meeting NOW at Salon 4.
Ioana Singureanu (May 10 2016 at 18:49):
I created several example consent (or auhorization to disclose) using HAPI:
Ioana Singureanu (May 10 2016 at 18:52):
The BHIT project exaples are available in GForge/SVN and cover basic consent, granular consent (includes references toprotected data types), cosent for researchL http://gforge.hl7.org/gf/project/cbcc/scmsvn/?action=browse&path=%2Ftrunk%2FIExHub%2FIExHub%2Fiexhub%2Fsrc%2Ftest%2Fresources%2FXML%2F
Drew Torres (May 10 2016 at 19:00):
Seeing as it is 3:00 is there another quarter you are going to continue the conversation?
Mohammad Jafari (May 10 2016 at 19:08):
I think we will continue in the next Q until 5pm.
Drew Torres (May 10 2016 at 19:09):
Which room?
Mohammad Jafari (May 10 2016 at 19:11):
salon 4
Ioana Singureanu (May 10 2016 at 19:24):
For HAPI implementers here is code for: Granular Consent and Consent for Research:
http://gforge.hl7.org/gf/project/cbcc/scmsvn/?action=browse&path=%2Ftrunk%2FIExHub%2FIExHub%2Fiexhub%2Fsrc%2Ftest%2Fjava%2Forg%2Fiexhub%2Fservices%2Ftest%2F
John Moehrke (May 10 2016 at 22:45):
There is much work yet to be shown on the Privacy Consent Directive. We need more bodies creating content. committee progress has been very slow. As such I have taken to put my thoughts on my blog -- see http://healthcaresecprivacy.blogspot.com/2016/04/consent-given-to-authorized.html and http://healthcaresecprivacy.blogspot.com/2016/04/consent-to-grant-read-access-to.html
John Moehrke (May 10 2016 at 22:47):
Grahame, I don't understand what you mean by creating a consent record each time a smart on fhir login happens? I see your example, but it looks more like what I would expect in an AuditEvent. A Consent is a record of agreement to share information for a given purpose under given constraints. Are you missing the point?
Lloyd McKenzie (May 10 2016 at 23:54):
When you use SMART, you are creating a record of agreement to allow a particular application to access a particular portion of an EHR's record for a particular time. That sounds like Consent to me.
Mohammad Jafari (May 11 2016 at 10:08):
@John Moehrke
Mohammad Jafari (May 11 2016 at 10:15):
I actually think the idea of capturing the OAuth consent (embodied in clicking a button on a webpage) as a machine-generated "consent directive" is very interesting. When we worked on the FHIR-UMA demonstration at HIMSS, there was a long debate between the developers and the lawyers whether the consent expressed when the patient approves some kind of access at the UMA authorization server suffices for legal purposes where patient's Consent Directive is required. I think what @Grahame Grieve described here is a very interesting step in closing that gap by turning that implicit web event into a potentially reliable legal consent directive.
Grahame Grieve (May 11 2016 at 10:30):
right. It's not a really significant 'consent' in the way other consents are. But that doesn't mean it's not a consent.
Grahame Grieve (May 11 2016 at 10:31):
and I didn't right it because I think that sharing such a consent record is justified on a cost-benefit basis, but primarily to engage with the ConsentDirective.
Grahame Grieve (May 11 2016 at 10:32):
And so far, every person I have spoken to, even those recommended by the committee, have said the same thing:
Grahame Grieve (May 11 2016 at 10:32):
- yes, we can make ConsentDirective as a profile on Contract work
- we'd rather not do that - it would be much easier if it was a standalone resource
John Moehrke (May 11 2016 at 13:00):
I would clearly like to separate Consent from Contract. This is not to say that a Consent couldn't be wrapped in a Contract, wrapped in a document... But the model for what would be captured should be a fundamental core Resource.. It might even look very much like Contract, but I doubt it. I wold rather see us design it based on real-world use-cases, and Agile method; getting away from top-down method used now.
John Moehrke (May 11 2016 at 13:55):
I have said it publicly on my blog - http://healthcaresecprivacy.blogspot.com/2016/05/fhir-consent-as-resource-or-profile.html
Mohammad Jafari (May 11 2016 at 14:04):
Thanks @John Moehrke . So as I am collecting and compiling these opinions for the group, what do other implementers think about Consent Directive and Contract? I also heard from @Ioana Singureanu that they didn't like using Contract for Consent Directive. How about you @Andrew Torres? Is there anyone with an argument FOR keeping Consent Directive a profile of Contract?
Mohammad Jafari (May 11 2016 at 14:08):
Kathleen seems to have an administrative argument here about the timeline of getting the new resource in the ballot. But aside from that, I'd like to hear any conceptual/technical concerns people might have against having an independent Consent Directive resource.
John Moehrke (May 11 2016 at 14:14):
We already have MANY open CPs on this topic asking for a Resource... so I think that argment is moot. Also we are in no way ready for ballot given the current structure. The current structue requires three weeks to get anything changed as we must coordinate with FM.
John Moehrke (May 11 2016 at 14:15):
I can have a Consent resource, based on what we have today, done by the end of the week. It is trivial to get from where we are today to having a prototype Consent resource of equivilant capability.
Lloyd McKenzie (May 11 2016 at 15:03):
It doesn't take that long to create a resource. Half day's effort for someone who knows the tools. So there's certainly lots of time to put it together and review it as a workgroup before mid-July
Drew Torres (May 11 2016 at 15:11):
I would agree that a new consent/authroization resource would be more intuitive than a profile on contract.
Grahame Grieve (May 11 2016 at 16:19):
John - please draft a resource ASAP. We can at least dsicuss it
John Moehrke (May 11 2016 at 18:24):
working on it.. :-)
Russell Bateman (May 11 2016 at 19:35):
While very new, I would like to add my feather weight to this. We have all sorts of data about consent, but really none of it lines up with what I'm presently seeing in the examples of Contract. Hope rises as I read these posts.
John Moehrke (May 11 2016 at 19:41):
please share.
John Moehrke (May 16 2016 at 15:09):
Grahame asked that I try to get a Consent resource ASAP... so it is now in the current build. Here is my blog writeup http://healthcaresecprivacy.blogspot.com/2016/05/start-at-consent-as-fhir-resource.html
John Moehrke (May 16 2016 at 15:10):
I welcome comments, complaints, improvements.... Please engage.
Erich Schulz (May 17 2016 at 22:39):
is the scope here just information disclosure consent? or clinical action consent?
Erich Schulz (May 17 2016 at 22:47):
two of the key elements of consent that I'm curious about are - how to provide evedence of information presented to decision maker? (a list of risks, benefits, ?costs, and importantly alternative actions) - and how does the agent collecting consent assert "the consent giver understood this information *and* they are free of duress"?
Lloyd McKenzie (May 17 2016 at 22:49):
The resource should support capturing consent for information access that isn't necessarily patient-centric too. E.g. permission granted to access certain information for research or regulatory purposes (in addition to or in place of patient-specific consent)
Erich Schulz (May 17 2016 at 23:14):
I would think its probably worth considering rolling them both up - tracking patient consent (and lost consent forms) is one of the biggest headaches in my work team
Erich Schulz (May 17 2016 at 23:15):
and private providers often collect consent remotely in time and place from where the action occurs
John Moehrke (May 18 2016 at 03:04):
The scope is Privacy Consent. It is not limited to Patient access. But it is limited to forms of patient directed authorization of access.
John Moehrke (May 18 2016 at 03:05):
This is not to say other consents are not needed, but we are struggling enough with this limited scope. And the experts we have are Privacy experts.
John Moehrke (May 18 2016 at 03:05):
Is there some part of the text that is confusing?
Lloyd McKenzie (May 18 2016 at 03:44):
Why would we create multiple resources that are all dealing with recording permission to access information? The scope of resources should be broad unless we're certain that the implementer community compartmentalizes different functions consistently with different interfaces and persistence layers and there's significant difference in content.
Lloyd McKenzie (May 18 2016 at 03:44):
We don't want 20 different consent-related resources in FHIR.
John Moehrke (May 18 2016 at 11:53):
Did I imply that the one resource can't handle all use-cases for Privacy consent? It certainly can, and there is a set of examples that cover most of the space. What we are not covering is: Authorization for a Procedure (I authorize surgery), Advanced Directives (Do not resuscitate (DNR)), agreement to participate in a clinical trial. These are not our focus, but are commonly discussed as a form of 'consent'. we are only covering (today) "Privacy Consent Directives".
John Moehrke (May 18 2016 at 11:54):
I really need people to review, comment; try it out in their usecases, guide us...
Lloyd McKenzie (May 18 2016 at 13:36):
I can live with two resources - one for "consent to disclose" and another for "consent for activity", but I don't think we should have more than two. And the one that does exist for "consent to disclose" can't be created focusing on a narrow use-case, it has to support every type of information disclosure (and be based on the 80% across all those possible types of disclosure).
John Moehrke (May 18 2016 at 15:31):
Good.. that is our goal... broad to support all consent to disclose usecases including authorization for external access, authorization for research use, etc. If you don't see a use-case listed on the current Consent resource, please let me know.
Paul Knapp (May 19 2016 at 05:54):
I'm seeing 2 new design principles in this discussion thread,
1) we can convert profiles on existing resources into new resources if there is implementer interest;
2) we can design based on what '80% of what a topic could encompass from an information perspective' not '80% of what system currently do'.
Do you have a pool of existing consent directives which are serving as your use case base?
John Moehrke (May 19 2016 at 12:41):
Yes, they are in the model. There are 9 samples that were brought to us from various places. These are presented to us as what systems do actually do today. It is true that most of the use-cases are what systems do today in an XDS environment. But given there is no FHIR environment, we must pull from existing systems of any type. I find he use-cases translate well, except for a few that are specific to how XDS federates which we didn't include. These are what I used. I welcome more to help build the model. -- Agile -- I think this is exactly the normal FHIR process. @Paul Knapp
Grahame Grieve (May 19 2016 at 21:55):
@Paul Knapp : "we can convert profiles on existing resources into new resources if there is implementer interest" - this is not what is going on here. The contention of the implementers is that presenting a consent agreement as as a profile on contract is not what is actually going on
Paul Knapp (May 20 2016 at 15:49):
If CBCC hasn't been providing a content model for the exchange of Consent Agreements through the provision of a profile, or profiles, on Contract then what do the implementers suggest CBCC has been doing?
Given that the Consent resource is as John says the needed elements and valuesets from the Contract and the profile with some trweaking/renaming, which matches my quick review of both, it appears that CBCC has been doing exactly that - creating a profile on Contract to meet the Consent Agreement content model needs.
John Moehrke (May 20 2016 at 17:46):
@Paul Knapp you have the benefit of understanding both Contract and the Profiling. It looks simple to you. We are hearing it isn't as simple to others.... BUT more to another part of your question, it has taken far too long to get to where we are because we had to cooperate with FM to get Contract changes. This is NOT a negative against FM, nor the very good interface we have. It is simply a fact that owning a Resource is far easier than owning a profile on someone elses resource. So, although what I presented is mostly a derivative that could be done through profiling; that might not be the case by September. The CBCC community could (if they choose to accept) completely change the Consent Resource without having to align with the modeling that FM has in mind for Contract. Further Consent can still be an attachment on a Contract. -- These are all points that I have made in my presentation of this potentially new pathway.
John Moehrke (May 20 2016 at 17:47):
Many people, including myself, still don't fully understand Contract. Contract is under developed, doesn't describe the elements it has, doesn't have vocabulary, and has no useful examples.. So building on Contract has been very difficult. Separation seems the right hing to do.
Paul Knapp (May 20 2016 at 20:50):
I have been looking at the Consent profile and see where the lack of a UML diagram, which would have roughly matched that of your Consent resource, and that the Structure display is not consistent with the Structure display used for resources could make the use of profiles difficult. I agree that whenever a level of indirection is introduced this makes it more conceptual and therefore more difficult than having a native instance.
I am concerned about what this says about FHIR in general as it is dependant on the use of profile on genericized resources. In some cases where we have pushed some far more diverse resources into a single resource your experience suggests those should be revisited to avoid similar situations. Also, if profiles on resources are difficult for implementers then how will profiles on profiles be received by implementers?
John Moehrke (May 20 2016 at 20:59):
I agree it is a data point. The struggle that I have is that today few people manage privacy consents (or other consents) as contracts. That is not to say that they don't have legal text, but they are viewed as something unto themselves. Which is why, I think, people are looking for a consent resource; rather than thinking they should look for a contract with a consent profile. So it is more because of existing practice.
Grahame Grieve (May 20 2016 at 22:53):
I agree with John. Consent is a computable structure backed by some paperwork somewhere. I think it's saying that Contract itself is a weird construct - the faux computable bit it has is too generic, and it doesn't match a real world construct I recognise
John Moehrke (May 23 2016 at 14:07):
Waking this thread up again, now that it is a new week. Didn't get much reaction last week, but I will assume it was the week off following the HL7 meeting.
John Moehrke (May 23 2016 at 14:08):
During the WGM, which I was unable to attend, Grahame asked that I prototype the Consent as a Resource 'asap', so I present it today. It has been in the FHIR Build since the beginning of of the week, and some have found it from my blog article, tweets, and chat.fhir.org.
http://hl7-fhir.github.io/consent.html
This is just a proposal, it has no formal standing. It is up to the CBCC community to decide if this is a better path forward vs the previous path of using a profile on Contract. I offer it as a prototype, so that people can make an informed decision. Please let the CBCC (cbhs@lists.hl7.org) know if you like this or not. Getting community input direct to the committee is very important. If you don't want to join the CBCC mailing list, then please send email to the co-chairs of CBCC -- details can be found on their workgroup home page http://www.hl7.org/Special/committees/homehealth/index.cfm
my blog were I describe the approach I took
http://healthcaresecprivacy.blogspot.com/2016/05/start-at-consent-as-fhir-resource.html
Grahame Grieve (May 23 2016 at 21:16):
thanks John. I'll implement it this week to see how works for me. Keep an eye out for questions here
Pascal Pfiffner (May 24 2016 at 08:56):
Thanks for drafting this, John, I just got to take a look. Here's my use-case for consent:
We have an iOS research app and obviously need to get consent from participants first. This builds on ResearchKit and I'm using a Contract resource to hold our consent terms. I'm using one term per consenting section, giving it a title in term.type.coding[0].code, a one-liner in term.text and (via extension) a file name to a HTML file holding on to one or two paragraphs for the section. The last part is certainly not FHIR-y but works for our iOS-App use-case at the moment. At the end, a review step is presented which concatenates all the term sections into one HTML document (using the title and the paragraphs in the external files), to which the participant can agree and which is then signed.
For subject we contain a Group where the group's characteristic defines the eligibility criteria we have (over 18, lives in the states and such). Before being able to consent, we look at these characteristics and let the user answer them.
An example of the consent flow, with data pulled from the Contract, is in the following video. Eligibility starts at 00:30, consenting at 00:45:
https://dl.dropboxusercontent.com/u/6971499/C%20Tracker%20Onboarding.m4v
In the current Consent proposal I'd have to split out our consenting sections into small friendly (or legal) pieces, either an Attachment or more likely a DocumentReference. Neither are very suitable to host individual sections, and I'd lose the "sexyness" of having the consent in the Consent resource.
What do you think?
John Moehrke (May 24 2016 at 14:35):
Can you present this at the Friday call http://wiki.hl7.org/index.php?title=HL7_FHIR_Consent_Directive_Project @Pascal Pfiffner ? Do you have an example available?
Pascal Pfiffner (May 24 2016 at 14:36):
Friday is the first day of my 2-week vacation I'm afraid. Let me share a link to the Contract (and a sample "section").
John Moehrke (May 24 2016 at 14:37):
thanks. I think your writeup (above) and an example will help us understand. I think I follow your writeup, but struggle with visualizing it.
Pascal Pfiffner (May 24 2016 at 14:45):
Here's Contract.json and one HTML section file: https://gist.github.com/p2/dedd8b4b26ef4cce600216a9fbe9ac31
John Moehrke (May 24 2016 at 16:43):
That is very much NOT what was expected. All you used Contract for is a list of strings.
Pascal Pfiffner (May 24 2016 at 19:51):
Yes. There were other factors as to why we needed the actual text in external files, but a clean solution would be desirable. But I guess this serves to show what I would like to use Consent for.
John Moehrke (May 25 2016 at 15:07):
What you have seems more like a use of Questionnaire to interact with the patient with the result being a filled out Consent resource instance. Why did you not go that way?
Pascal Pfiffner (May 26 2016 at 12:39):
If you imagine the text in the referenced files being included in the Contract, then we'd have a pretty standard contract/consent, with terms being agreed to. The eligibility part could be a questionnaire, yes.
Peter Bernhardt (May 26 2016 at 16:01):
So how would you model a DNR in FHIR? Is this a profile on Contract?
Grahame Grieve (May 26 2016 at 18:29):
not done yet. So Basic...?
Aleksandra Pavlyshina (Sep 02 2016 at 12:53):
I'm at the moment figuring our how to represent DNR in FHIR. In our application, it's recorded as an answer to the question "Is the patient a DNR?" with a Yes/No radio button, and a saved answer of "Yes" should toggle a red DNR on the patient banner.
scr-02.09.2016_15-37-51.png
Can it be recorded as an Observation.code = 304251008 | Resuscitation status (observable entity) with values Observation.value = 304252001 | For resuscitation (finding) (if not DNR), and Observation.value = 304253006 | Not for resuscitation (finding) and Flag.code =
304253006 | Not for resuscitation (finding) (if DNR)?
Also LOINC has 81351-9 Do Not Resuscitate, Do Not Attempt Resuscitation, or Allow Natural Death order is in place [Reported] with EXAMPLE ANSWER LIST Yes/No/..., probably this can be used in Questionnaire.item.concept for this question?
scr-02.09.2016_15-45-56.png
Paul Knapp (Sep 03 2016 at 07:14):
I would expect your question to be "Does the patient have a DNR?" and that would be a search on Contract (Consent Profile) or Consent if it supports a DNR.
John Moehrke (Sep 03 2016 at 15:29):
The modeling for advanced directives has not yet been done, although it is in scope for the Consent resource. To find if a patient as an advanced directive one would search for Consent resources with the Consent.patient of that patient, and with Consent.category of type advanced directive. Likely want to also make sure that you only ask for active resources, etc... One might have used a Questionnaire originally get this 'consent', but it would be persisted as a Consent resource, possibly linked to the questionaire answers through the Consent.souce element.
Aleksandra Pavlyshina (Sep 08 2016 at 13:34):
Application requirements have been changed recently. Now we display the question "Does the patient wish to attempt resuscitation?"
and the answers are Yes / No (DNR) (an answer of "No (DNR)" should toggle the red DNR flag on the patient banner).
And we display the question "Does the patient have documentation supporting this decision?" Yes / No
And we capture the following questions for each type of the 'Advanced Directive / Living Will / DNR / POST/POLST' documents:
Does the patient have a <document type>? Yes/No
If, yes?
Does the patient need to make changes to the <document type>?Yes/No
Does the patient have copies of the <document type>?Yes/No
Has Narus Health received a copy of the <document type>?Yes/No
Does the patient have any questions about the <document type>?Yes/No
Do we need to send copies of the <document type> to the medical team?Yes/No
If, no?
Is the patient interested in learning more about a <document type>?Yes/No
Does the patient want to complete a <document type>?
Aleksandra Pavlyshina (Sep 08 2016 at 13:36):
Is this the correct mapping to represent a DNR order in FHIR using the Consent resource?
| FHIR Field | Mapping |
|---|---|
| Consent.status | active |
| Consent.category | advance-directive |
| Consent.dateTime | Resource creation date/time |
| Consent.period | Effective dates from the original document |
| Consent.patient | Reference to Patient |
| Consent.consentor | Reference to Patient or their legal guardian |
| Consent.organization | Attorney's firm, who attested the document |
| Consent.sourceAttachment | If application has a copy of the original document uploaded |
| Consent.sourceIdentifier | If not above, but patient has a copy, document # from the original paper document |
| Consent.sourceReference | If not all above, reference to QuestionnaireResponse |
| Consent.policy | http://hl7.org/fhir/ConsentPolicy/opt-in |
| Consent.except.type | deny |
| Consent.except.action | For resuscitation (finding) SCTID: 304252001 |
| Consent.except.code | Not for resuscitation (finding) SCTID: 304253006 |
John Moehrke (Sep 08 2016 at 14:34):
@Aleksandra Pavlyshina Nicely done. I would like to see this captured in a CP or ballot comment so that the CBCC committee is well informed. Will you do that? My only adjustment is that the Consent.policy would need to be something else. The opt-in policy is a specific Privacy opt-in. That is my perspective. I am not sure I see a reason to have anything in Consent.policy for your use-case.
Aleksandra Pavlyshina (Sep 08 2016 at 19:20):
@John Moehrke Thanks.
I agree, however Consent.policy is 1..1 so I had to put something there, I put 'opt-in' meaning 'allow everything' but 'deny' the action 'For resuscitation (finding) SCTID: 304252001'.
I'm not sure about the Consent.except.code value: should it be Not for resuscitation (finding) SCTID: 304253006?
Also I'm not sure about the Consent.organization(Organization that manages the consent) - is this the organization that owns the application where I'm capturing this information, or is this an attorney's firm, who attested this original document?
I'd love to share this mapping but don't know how. Please advise where to post it, and what is CP?
John Moehrke (Sep 08 2016 at 19:24):
I can submit it as a comment on your behalf. The open issues you bring up are important issues for the workgroup to fix. This is why I ask to get your use-case in front of the committee that owns the Resource. So, coming out of STU3 ballot reconciliation this should be more clear.
John Moehrke (Sep 08 2016 at 19:28):
I made CP tracker item GF#10610
Ioana Singureanu (Sep 08 2016 at 21:04):
Hi @Aleksandra Pavlyshina - I recommend creating a profile that specifies exaclty how you plan to use the Consent resource for DNR (as far as I know you are the first person to apply consent for this purpose)
I have some comments:
Consent.organization would be the organization/provider who will seeks the DNR and later uses is it. I don't think you will have an occasion to specify "Dewey, Cheetham, and Howe, PLC" .
Just to clarify:
If Consent.except.type ='deny' AND Consent.except.action ='For resuscitation (finding) SCTID: 304252001' --> it means "do not resuscitate"
If Consent.except.type ='permit' AND Consent.except.action ='For resuscitation (finding) SCTID: 304252001' --> allow resuscitation (this is the default, anyway)
It may be useful to create some examples.
Tarik Idris (Sep 13 2016 at 09:38):
@Aleksandra Pavlyshina I would have thought that you don't need exceptions, instead the policy should be a URL that points to a description of the actual policy "For resuscitation" or to a description of the actual policy for "do not resuscitate". These policies should describe what is meant by "for resuscitation" and by "do not resuscitate" - what is allowed, what is not allowed (e.g. defibrillation). If the organization collecting it does not have defined clear policies for this, it could just point to a legal statute of their jurisdiction that explains it. If your client deals with multiple jurisdiction and does not want to include any specifics in the consent, you could define a URI and describe the meaning (e.g. simply "DNR, where the details are defined by the applicable jurisdiction").
Aleksandra Pavlyshina (Sep 13 2016 at 13:51):
@Ioana Singureanu @Tarik Idris Thank you very much for your feedback and clarifications.
I removed Consent.except, changed Consent.organizationto 'Reference to Organization representing our care management application where the Consent resource is created', and changed Consent.policy to the fake URI http://hl7.org/fhir/ConsentPolicy/not-for-resuscitation.
Also, since Consent.category is 0..*, does it make sense to add one more category value Not for resuscitation (finding) SCTID: 304253006?
I'm going to create a profile for the Consent resource for DNR later then.
| FHIR Field | Mapping |
|---|---|
| Consent.status | active |
| Consent.category(1) | advance-directive |
| Consent.category(2) | Not for resuscitation (finding) SCTID: 304253006 |
| Consent.dateTime | Resource creation date/time |
| Consent.period | Effective dates from the original document |
| Consent.patient | Reference to Patient |
| Consent.consentor | Reference to Patient or their legal guardian |
| Consent.organization | Reference to Organization representing our care management application where the Consent resource is created |
| Consent.sourceAttachment | If application has a copy of the original document uploaded |
| Consent.sourceIdentifier | If not above, but patient has a copy, document # from the original paper document |
| Consent.sourceReference | If not all above, reference to QuestionnaireResponse |
| Consent.policy | http://hl7.org/fhir/ConsentPolicy/not-for-resuscitation |
Last updated: Apr 12 2022 at 19:14 UTC
