FHIR Chat · Organ Donor Registry records · implementers

Stream: implementers

Topic: Organ Donor Registry records

---

Reuben Daniels (Aug 31 2016 at 01:51):

Anyone have any experience in representing organ donor registry records with FHIR or thoughts on an appropriate FHIR resource(s) to represent these records?

Stephen Royce (Aug 31 2016 at 02:04):

We looked at Questionnaire although we don't feel that comfortable with it. Another option is Basic, but there'd be a lot of work to do with extensions if that was to be used.

Brian Postlethwaite (Aug 31 2016 at 02:16):

Is this the likes of the details on here?
https://www.humanservices.gov.au/customer/forms/nh007df
Or are you just considering the flag that indicates that there is information
http://hl7.org/fhir/extension-patient-cadavericdonor.html

Reuben Daniels (Aug 31 2016 at 02:25):

Thanks Brian and Stephen. Yes, I was thinking either Questionnaire/QuestionnaireResponse or Observation with related Observations.

Reuben Daniels (Aug 31 2016 at 02:26):

Brian: Yip, it's exactly that form and its content.

Reuben Daniels (Aug 31 2016 at 02:26):

The human services one

Brett Esler (Aug 31 2016 at 02:29):

Isn't that a consent statement and some admin? Contract ?

Brett Esler (Aug 31 2016 at 02:30):

i'd like to think my organs deserved their own explicit Contract of use....

Reuben Daniels (Aug 31 2016 at 02:35):

Brett: the focus is representing the content of the registry entry and not the content/contract arrangements around that.

Reuben Daniels (Aug 31 2016 at 02:35):

*content=consent

Grahame Grieve (Aug 31 2016 at 02:36):

Have you looked at the consent resource?

Reuben Daniels (Aug 31 2016 at 02:44):

Grahame: I have, just not sure its appropriate in this case. I agree that an assertion of consent is related, however, I'm inclined to think the organisation that obtained the consent should be responsible for creation of the associated Consent resources. In this case, the organisation providing the register record is not the same as the one that obtained the consent.

Grahame Grieve (Aug 31 2016 at 03:03):

I don't follow that reasoning at all.

Grahame Grieve (Aug 31 2016 at 03:03):

the patient provides the consent

Grahame Grieve (Aug 31 2016 at 03:04):

how can the organization provide information about the consent if they didn't obtain it from somewhere?

Reuben Daniels (Aug 31 2016 at 03:10):

Grahame: Human Services obtains the consent (based on the paper form). Based on a second consent (whereby the patient allows human services to pass the information in the record to the MyHR system), the information held in the register record is represented in a CDA document (without the details of the original consent). The requirement now is to represent what is in the CDA document using FHIR. With that in mind, do you think it makes sense for the MyHR to represent the register record details using a Consent resource?

Grahame Grieve (Aug 31 2016 at 03:13):

sure. the notion of a derivative consent is common in the consent area. You'd populate __Consent.source__ with something that points back to the original consent

Grahame Grieve (Aug 31 2016 at 03:13):

probably an identifier in that context

Brian Postlethwaite (Aug 31 2016 at 04:37):

And maybe flag the patient resource with the extension I mentioned to alert the presence of the censent?

John Moehrke (Aug 31 2016 at 15:13):

Brian, if we have a resource/profile of Consent that indicated organ donor information; then there is no need to put a flag in the Patient. The search within the Patient space for this will uncover it. Just like finding if they have a CBC lab result.

John Moehrke (Aug 31 2016 at 15:14):

The CBCC committee has focused tightly on Privacy use-cases for Consent. They need additional subject matter experts to help them with other forms of Consent. I am not convinced that all of these 'consents' will fit the same data-model, but that is the direction FMG gave to CBCC.

Stephen Royce (Sep 01 2016 at 00:32):

For Australia, would this page be sufficient for the Consent.policy URI: https://www.humanservices.gov.au/customer/services/medicare/australian-organ-donor-register?

Stephen Royce (Sep 01 2016 at 00:33):

Or perhaps this one: http://www.health.gov.au/internet/main/publishing.nsf/Content/health-organ-aodr.htm? (I think the first is "closer to the horses mouth".)

Stephen Royce (Sep 01 2016 at 01:01):

Okay, so I just realised that the policy is the thing they're actually consenting to not the policy that governs how decisions on consent are to be made and recorded. I don't think such a thing exists (explicitly) for Australia. (in particular, what would the policy be that a person explicitly refuses permission for the organs to be used post death?)

Stephen Royce (Sep 01 2016 at 01:03):

Incidentally, why does the thing being consented to have to be a policy? Why can't it be a standard activity (or type of activity) for which no formal policy exists?

Stephen Royce (Sep 01 2016 at 01:05):

Also, incidentally, the Scope and Usage section says, "There are 3 possible uses for consent," and then proceeds to list 4!

Stephen Royce (Sep 01 2016 at 01:07):

And, does organ donation count as "treatment consent"? Technically, the patient is no longer being treated, but there doesn't seem to be a better alternative. (And perhaps clinicians still think of it as treatment because the dead person is undergoing a procedure.)

Stephen Royce (Sep 01 2016 at 01:16):

Also, organ donation does not really fall into the opt-in/opt-out model. While it is opt-in in a way, a person can explicitly record their opt-out preference. You cannot capture both in an opt-in/opt-out model with a single policy. (Please don't suggest to me that you capture an opt-in with an exception to the whole policy; that's fundametally flawed because it completely fails to capture what the patient is trying to express. It would would far better to have an explicit type (deny | permit) element at the whole Consent level.)

Grahame Grieve (Sep 01 2016 at 01:18):

so Consent is the nearest thing at the moment. we can use consent, but we have to acknowledge that it's experimental. As John said, the committee is not itself considering use cases like this, and the resource scope explicilty says that when HL7 considers such use cases in depth, the scope may be changed. hence, the scope is provisional, and so must our use be.

Grahame Grieve (Sep 01 2016 at 01:19):

the model here is that the patient consents to an organ donation policy, which is opt-in based. a country could have an opt-out policy, though I don't know of any that do.

Stephen Royce (Sep 01 2016 at 01:19):

Finally (!), all the examples and almost all the example codes relate to privacy consent and the other areas a completely lacking. A wider coverage of examples would be really useful. (I'd be happy to submit some once we work out how to represent organ donation in an Australian context, but sadly that doesn't help me now.)

Grahame Grieve (Sep 01 2016 at 01:19):

then they list, as exceptions, the things they opt-in for.

Grahame Grieve (Sep 01 2016 at 01:20):

of course wider coverage would be useful. but it actually requires work, and no committee has currently taken it on.

Stephen Royce (Sep 01 2016 at 01:20):

Sure. I must have missed that when reading through it.

Grahame Grieve (Sep 01 2016 at 01:21):

as for the other things, welcome to a FMM=1 resource. You can ballot about this stuff, though the committee will likely rule any comments as 'cosnidered for future use'

Grahame Grieve (Sep 01 2016 at 01:21):

or any comments that don't relate to the privacy scope

Stephen Royce (Sep 01 2016 at 01:23):

We have an overall denial or permission for organ donation with the option of a person supplying organ-group level exceptions to that. Typically a person would permit organ donation in general but deny use of their eyes, say. However, they can deny use in general as a whole, or allow use of their kidneys (say).

Grahame Grieve (Sep 01 2016 at 01:24):

well, we could write an IG that said that, and provided to policy URIs, one for opt-in with exceptions, and one for opt-out with exceptions

Grahame Grieve (Sep 01 2016 at 01:24):

though you'd probably not have exceptions in the second case

Grahame Grieve (Sep 01 2016 at 01:25):

that's the anticipation anyway, with the consent resource - implementers will publish IGs that define policy URs and how they work

Stephen Royce (Sep 01 2016 at 02:10):

Right. So we've got some work ahead of us.

John Moehrke (Sep 01 2016 at 02:20):

Yes, welcome aboard.

Richard Townley-O'Neill (Sep 14 2017 at 07:02):

I'm trying to understand how to use Consent for entries in an organ donor register.

Here are a couple of cases I want to represent:
1
Not willing to donate any organs or tissue
2
Willing to donate:

• bone tissue
• eye tissue
• heart

Not willing to donate:

• heart valve
• kidney
• liver

Richard Townley-O'Neill (Sep 14 2017 at 07:10):

In STU3
Where do the tissues (e.g. heart) go?
In except.action?
Maybe except.action gets a value like 'use' and the tissue goes into except.purpose.
In except.data as a Specimen?
in an extension to except?
in an extension outside except?

Richard Townley-O'Neill (Sep 14 2017 at 07:10):

None of these look good.

Eric Haas (Sep 14 2017 at 07:18):

Where do the tissues (e.g. heart) go? - why not use codes?

Bob Milius (Sep 14 2017 at 15:27):

If you're looking for a place in FHIR to describe the transplant material (e.g., heart), we've been having a discussion about a new resource, tentatively called BiologicallyDerivedProduct. It's being fleshed out here: http://wiki.hl7.org/index.php?title=BiologicallyDerivedProduct_FHIR_Resource_Proposal

Richard Townley-O'Neill (Sep 15 2017 at 00:12):

@Eric Haas
Do you mean except.code? Its definition of "If this code is found in an instance, then the exception applies." makes me think that code is a tag used to identify data of interest. I can't see how that is relevant to consent to donate an organ.

Richard Townley-O'Neill (Sep 15 2017 at 00:21):

I want to use codes, but where do the codes belong?
In action as a code for such things as 'extract and use heart'?
In data using BodySite.code or Specimen.collection.bodySite.code?
Something else?

Richard Townley-O'Neill (Sep 15 2017 at 00:25):

@ Bob Milius
The proposed resource looks much better than BodySite or Specimen .
Do you see it being used in Consent.except.data.reference to indicate consent to donate something?

John Moehrke (Sep 15 2017 at 00:41):

Sorry to just see this now... I would very much invite you to provide input to the CBCC (owning workgroup of Consent). They have NOT had participation from anyone trying to use Consent for anything other than Privacy. So they are very hungry for your input. They expect that very little of what exists today is directly usable, meaning anything you have been able to use is a happy surprise. Thus please provide gForge Change Requests (CR). and join the meetings. Residing co-chair and owner of the resource is @David Pyke

Richard Townley-O'Neill (Sep 15 2017 at 00:48):

@John Moehrke
Thanks. I'm interested, but we need a STU3 solution, preferably this month.

Richard Townley-O'Neill (Sep 15 2017 at 00:51):

Is except.purposea better location than except.action?

David Pyke (Sep 15 2017 at 01:08):

If you can make the next FHIR consent call, next Friday at 2pm Eastern, we can help better than trying here. We haven't considered that use case do it needs some thought

John Moehrke (Sep 15 2017 at 01:13):

I can also help you with your STU3 use.. that can inform the committee updates for R4...

Richard Townley-O'Neill (Sep 15 2017 at 01:34):

Thanks. I can't make Friday 22 September's meeting.
Also, I'm at AEST (UTC +10), you are at EST (UTC -5). So 2PM EST is 4AM for me.Could it be 4PM EST on 29 September?

Richard Townley-O'Neill (Sep 15 2017 at 05:39):

For "agree to donation of heart" I'm looking at using
except.type="permit"
except.action.coding.system="http://snomed.info/sct"
except.action.coding.code="232975000"
except.action.coding.display="Removal of heart from donor"

Richard Townley-O'Neill (Sep 18 2017 at 00:42):

Is Consent.except.code meant to be analogous to such elements as Observation.code, Observation.consent.code, Procedure.code, and Condition.code? They identify with fine granularity the type of observation, procedure or condition. The definition of Consent.except.code suggests something quite different.
If Consent.except.code is meant to be like the others, could its definition be

Identification of a variation to one of the policies.

Richard Townley-O'Neill (Sep 18 2017 at 06:02):

Then the code values could be one of the following SNOMED CT codes:

• 160654005 |Willing to be a donor|
• 444385008 |Willing to be donor of heart|
• 160656007 |Willing to be donor of kidney|
• 444412001 |Willing to be donor of liver|
• 444407002 |Willing to be donor of lung|
• 444378009 |Willing to be donor of pancreas|
• 832571000168103 |Willing to be donor of heart valve|
• 832581000168100 |Willing to be donor of bone tissue|
• 832591000168102 |Willing to be donor of eye tissue|
• 832601000168109 |Willing to be donor of skin tissue|

John Moehrke (Sep 18 2017 at 13:34):

Hi @Richard Townley-O'Neill sorry for the delay, way too busy at the WGM. Given that Consent.except is there to support Privacy Consent, it isn't intended for your use-case. You could use it however you want, or you could create extensions. The best 'modeling' would be to create extensions, and that would best inform us with improvements of the resource for R4.

John Moehrke (Sep 18 2017 at 13:36):

In looking at your valueset, It looks like you could put this at Consent.action. So your Organ Donor Consents would be first differentiated by Consent.category=160654005 (to indicate is organ donor), then Consent.action be the specific codes. Would that work?

Richard Townley-O'Neill (Sep 18 2017 at 23:48):

To use Consent.except.action I'd need to use different code values, maybe the SNOMED CT codes 53958007|Harvesting of donor material| and 232975000|Removal of heart from donor| will do.

Richard Townley-O'Neill (Sep 18 2017 at 23:48):

The trouble with using the 'Willing to be...' codes as value for Consent.except.actionis that these are not actions. In SNOMED CT they are called findings. They are, however, reasonable as values for a coded exception/provision. I cannot use Consent.except.code as that name seems to be used for a tag on resources of interest, and is not available for a code to describe the exception/provision.

John Moehrke (Sep 19 2017 at 00:33):

I am trying to avoid using Consent.except for your use-case... as it is very specifically structured for Privacy policies. Eventually, we will create proper structure once we know what that stucture should be... in R4... Hence why I think it is better to use Consent.action... You will need to define your own ValueSet, so what ever codes you want can be put in there. Creating a valueSet is easy enough as part of an ImplementationGuide. New tools make these easy. I can help once we agree in principle

Richard Townley-O'Neill (Sep 19 2017 at 01:10):

I did not notice that you said Consent.action and not Consent.except.action.
I avoided using Consent.action as it is not in the build.fhir.org version of Consent.

Richard Townley-O'Neill (Sep 19 2017 at 01:11):

I know that except becomes provision.

Richard Townley-O'Neill (Sep 19 2017 at 01:18):

How would it be to add an extension Consent.code with definition "Identification of what is consented to." and values like "Willing to be donor of heart"? That makes the model a little more like Observation and Procedure and lets us keep using the code values listed above.

Richard Townley-O'Neill (Sep 19 2017 at 01:59):

Using Consent.action makes saying "may take heart, may not take kidney" hard.
Using Consent.except.action is much easier. For example: the policy is "take only with explicit consent", one except has (allow, extraction of heart) and another has (deny, extraction of kidney).

Richard Townley-O'Neill (Sep 19 2017 at 02:02):

We will avoid using an extension for the key information.
So we will use Consent.except.action for our STU 3 solution.

John Moehrke (Sep 19 2017 at 12:50):

The move from except to provision was to move all the duplicate elements that were at the root into the first level provision. It was an effort in making the model more pretty. There are many more issues the committee is working on, many problems with examples, etc. What ends up in the R4 ballot will likely be very different than current build. So I would not recommend looking to the current build as anything useful.

John Moehrke (Sep 19 2017 at 12:51):

I understood you were using STU3, not current build.

John Moehrke (Sep 19 2017 at 12:52):

If using current build, then lets get some changes into the current build. We can do that in a few weeks. (Could be one week, but committees take the week after a WGM off)

Richard Townley-O'Neill (Sep 20 2017 at 00:32):

We are using STU3. We chose to avoid those parts of STU3 that are not in current build, so as to improve the chances that future interactions with STU4 resources will be easy. We chose to not put the key information (what is agreed to) in an extension, as that would make resource instances unsafe for systems that were not configured for the our profile.
I'm happy to contribute to STU4.

Lloyd McKenzie (Sep 20 2017 at 14:40):

Technically core elements aren't any safer than extensions as implementers are free to ignore core elements as freely as they can ignore non-modifier-extensions. There's a lower probability of this happening, but it will absolutely happen. If you need receivers to process specific elements to ensure safety, the only way to ensure that is through site-specific agreement. (The general fall-back for safety in the face of variable element support for FHIR is human-readable narrative.)

Richard Townley-O'Neill (Oct 19 2017 at 07:34):

@John Moehrke
We decided to use extensions for the interesting part of consent to donate organs.
There is one extension-donationDecision which says whether or not the person consents to donate at all and
there are several extension-donationProvisions, one with the decision for each type of organ (heart, skin, etc.)
Attached is an example of an instance.
aodr-example-willingtodonatesome.json

Richard Townley-O'Neill (Oct 19 2017 at 07:34):

Any thoughts.

Richard Townley-O'Neill (Oct 19 2017 at 07:37):

The new meeting time for CBCC is 3AM for me.
I'll try for 26 October

Vadim Peretokin (Oct 19 2017 at 10:57):

I like the indenting.

John Moehrke (Oct 19 2017 at 12:59):

I can't make the calls this week either due to vacation. I think they are looking at this kind of use-case right now. And I think what we worked on last week is along these lines. We are starting with making valuesets that are type-of-consent specific. So we would need help making an organ donor valueSet. Then we are creating different valuesets to be used in the provisions, looks like you have a good list here. Can you make your structure definition available? @David Pyke might be able to help here, he is the co-chair on this topic.

Richard Townley-O'Neill (Oct 19 2017 at 23:33):

@Vadim Peretokin :laughing: oXygen default.

Richard Townley-O'Neill (Oct 20 2017 at 05:01):

@John Moehrke @David Pyke
Here are some instances
aodr-example-notwillingtodonate.xml
aodr-example-willingtodonate.xml
aodr-example-willingtodonatesome.xml

Richard Townley-O'Neill (Oct 20 2017 at 05:03):

And here are the structure definitions
consent-aodr.xml
extension-dateregistered.xml
extension-donationdecision.xml
extension-donationprovision.xml

Richard Townley-O'Neill (Nov 13 2017 at 07:10):

I've put a new draft design in the Australia topic at Australian Organ Donor Register

Richard Townley-O'Neill (Nov 13 2017 at 23:38):

@John Moehrke @David Pyke I'd welcome any comments on the thread Australian Organ Donor Register

Abbie Watson (Dec 05 2017 at 13:58):

Happy news: I just signed a contract with a major University and we have some grant funding to work on Organ Donations and other Advanced Directives. We have a website related to the Organ Donation process, and will probably be able to put up some Consent and Contract endpoints. More details to follow.

---

Last updated: Apr 12 2022 at 19:14 UTC