Stream: implementers
Topic: Patient -- sexual orientation
Daniel Tam (Jan 27 2022 at 04:56):
Have any providers encountered the need to record sexual orientation of their patients? We would like to at One Medical. We found this extension, but it looks like it is a workgroup extension, and may not be fully worked out.
https://build.fhir.org/ig/HL7/cdmh/StructureDefinition-cdmh-patient-sexualOrientation.html
Any recommendations on how far along this extension is? What have others done?
Cooper Thompson (Jan 27 2022 at 13:52):
We (Gender Harmony Group) are having some discussions on whether this will land in an extension or as a profile on Observation (since sexual orientation is often part of sexual history which is similar to social history).
René Spronk (Jan 27 2022 at 15:50):
Extension on Patient? That'll easily run afoul of GDPR-like requirements around 'need to know'. Observation would seem to be the safe way to go from that perspective.
Cooper Thompson (Jan 27 2022 at 16:58):
Patient vs. Observation doesn't solve any GDPR problems. If there is a "need to know" limit, that needs to be handled in the auth layer. Just moving stuff around onto different resources just moves the problem - it doesn't solve it.
John Moehrke (Jan 27 2022 at 17:00):
well, in an Observation the senstivity of that data can be more easily controlled than having highly sensitive elements in the Patient resource, a resoruce that needs to be highly shared.
Cooper Thompson (Jan 27 2022 at 17:01):
Maybe. But if your system only has resource-level granularity for data access control, then you are already probably failing any "need to know" limitations.
John Moehrke (Jan 27 2022 at 17:01):
Please do NOT put it in Patient.. not as an element, not as an extension...
Cooper Thompson (Jan 27 2022 at 17:55):
I also don't want it in Patient - my preference is an Observation. But for different reasons than yours I think.
Cooper Thompson (Jan 27 2022 at 17:57):
But part of me is horrified that some systems might depend on Resource-level controls for GDPR compliance. That seems like a sin almost as serious as some of the stuff in the Alissa Knight paper.
John Moehrke (Jan 27 2022 at 18:00):
resource-level controls are very appropriate. but it does require that resources are designed to be "appropriate" size.
Cooper Thompson (Jan 27 2022 at 18:02):
Like Observation? For you to get the right level of control at the resource level, it seems like we'd need to move everything into Observation. Basically every other resource (or at least every other administrative resource) has property-level data that could have different access rules based on the user or role.
René Spronk (Jan 27 2022 at 18:03):
The aim of the Patient resource is solely "The data in the Resource covers the "who" information about the patient: its attributes are focused on the demographic information necessary to support the administrative, financial and logistic procedures." - most jurisdictions will define a national profile that details a subset of that resource, potentially with extensions, which can be more or less freely shared between healthcare providers. IMHO sexual orientation is not about 'who' or patient identity matching.
John Moehrke (Jan 27 2022 at 18:03):
I have tried to express this potential modeling problem as a principle, but lost that argument. Yes, there are some huge resources. Mostly the normative resources are okay sized.,
Cooper Thompson (Jan 27 2022 at 18:05):
I mean Patient seems like it already poses a major problem for your proposed approach. Each identifier in the Patient.identifiers list might have different access restrictions. Some might need to be masked based on the user, some might be "relatively" public, and some might have jurisdictional limits.
John Moehrke (Jan 27 2022 at 18:07):
yup, some implementations walk themselves into that brick-wall.
René Spronk (Jan 27 2022 at 18:07):
@John Moehrke That takes the discussion in another direction: some of the resources (mostly with a low maturity) have way too many data elements, the "80%" principle doesn't really hold. One can only hope the data elements are trimmed before the resource goes normative.
John Moehrke (Jan 27 2022 at 18:08):
that will only happen with public comments. There is no internal rules that will drive that.. I lost that fight.
Cooper Thompson (Jan 27 2022 at 18:08):
But I don't think the 80% principle has anything to do with what content needs user or role level access restrictions.
John Moehrke (Jan 27 2022 at 18:08):
correct. 80% is not the same thing.. but too-big.
René Spronk (Jan 27 2022 at 18:09):
@Cooper Thompson depends on the jurisdiction, of course. If one has a reliable citizen number at the national level, this is a non issue. But of course, there could be clients where the server will have to apply additional data filtering to the contents of a Patient resource.
Cooper Thompson (Jan 27 2022 at 18:12):
It depends on how public the citizen number is. If those numbers are 100% publicly known, then yeah, I guess. But you won't have any sort of "need to know" limitations if the data is publicly known anyway.
John Moehrke (Jan 27 2022 at 18:17):
the Patient resource is not published on a billboard. It is shared with trusted cohort, so the content can have details that one would share with that cohort.
John Moehrke (Jan 27 2022 at 18:17):
yes, one does expect that that cohort is about as broad as possible. Including the cafeteria. so, yes it is a broadly accessible resource
John Moehrke (Jan 27 2022 at 18:19):
that said, there is nothing against filtering out elements given a specific user. And the DS4P IG speaks to even this fine-grain filtering. However the ability to do this does not justify putting sexual orientation data into Patient.
Daniel Venton (Jan 27 2022 at 18:19):
We're at the point where Resource Level controls are not enough to meet every level of access required. If I am allowed access to the Condition resource, that doesn't mean I'm allowed access to all Condition resources on the server. Limitation #1, I might only be allowed access to the conditions of 1 patient. Limitation #2 As a guardian I might be allowed access to my child's Conditions, but not if they have to do with sexual activity if the child is > 16 years, in some jurisdictions. Limitation #3 due to "need to know". ..
Access is a many factored thing. FHIR says access to a resource. Government says access to a data point. In some cases this means an attribute (an extension), in some cases all attributes of an instance of a Resource. Ultimately, at least in the US and probably the EU, you are going to have to know Who the user is, What role the user is in and Why the request is being processed (treatment, research, chart review,...) Once you have those three factors you'll be able to determine, Can this person, as a guardian, doing chart review, see this attribute/resource? And in the US with Information Blocking, if any piece of information is denied, prepare to show under what law/rule/etc allowed you to deny that piece of information.
John Moehrke (Jan 27 2022 at 18:23):
right. the scopes supported by SMART-on-FHIR does not recognize this more resource level access control. It only addresses types of resource, not types of data within a type of resource. A rather meta discussion, but to state that it is easier to have access rules around a Observation of type sexual-orientation, than it is to protect an element holding sexual-orientation within a broadly used resource like Patient.
John Moehrke (Jan 27 2022 at 18:23):
see this discussion in the security section of the FHIR core spec - https://hl7.org/fhir/security.html#binding
Daniel Venton (Jan 27 2022 at 18:30):
Implementation wise there is not much difference between a scope that says patient/Patient.read(not sex-orientation attribute) and a patient/Observation.read(not sex-orientation code). But how far do you take that and is it positive, negative or both?
patient/Observation(code=123 but not .value[x])
patient/Observation(code=567 but not .interpretation)
patient/Observation(code=*)
patient/Observation(code!=986)
If you expand the FHIR scopes to allow all the above, then the scopes become a programming language. (Yes this is an extreme hypothetical situation where the expectation is that the FHIR scopes completely define every attribute and every resource based on a condition(s) that the token allows access to.)
Cooper Thompson (Jan 27 2022 at 18:32):
I think scopes are orthogonal to user-based access. The scenario I think is more relevant is when you have a single resource (observation or patient, doesn't matter) but have different users (teen child = patient, parent = authorized rep, nurse, doctor, billing user). You would not use scopes to grant different accesses to those user types, since the specific user is not included anywhere in the scope structure.
John Moehrke (Jan 27 2022 at 18:32):
focusing on SMART-on-FHIR scopes will not get you to where you are trying to get. Those scopes are not designed to support fine grain control
John Moehrke (Jan 27 2022 at 18:34):
note this is not to say those scopes are not useful. they are... it is just that more fine-grain is handled at the Resource Server, not in OAuth authorization token issuing
John Moehrke (Jan 27 2022 at 18:36):
so, where SMART scope says you want Observations, and you get that scope.... does not mean you will get "all" Observations. Those that you get are based on more fine grain "enforcement" done at the Resource Server... typically all of Privacy rules are done at the Resource Server, not usually represented in OAuth scopes (Yes, I know about HEART profile of OAuth which does...).
Daniel Venton (Jan 27 2022 at 18:37):
I agree, FHIR scopes in the token are unlikely to be able to ever specify the very fine grained of data access that is required across across multiple legal zones. Not that the authorization server couldn't do the same calculation as the resource server, but the resource server will likely have native access to the data with which the determination will be based on.
Daniel Tam (Feb 09 2022 at 21:27):
@Cooper Thompson I just finished talking to the providers at my company, as well as the developers that I work with. I'm recommending that we build sexual orientation as a profile on an Observation resource, and that we avoid including this as a data element in Patient resource. I was wondering if it'd be helpful if I were to hop on a Gender Harmony call, and talk this through?
The clinicians I work with were most concerned with privacy. There could be a real danger in accidentally exposing sexual orientation (for example, in the case of a teenager who has not revealed sexual orientation to his / her parents). In contrast, that danger does not nececessarily exist with other items in the Patient resource. To them this was like a PHI+ type of information -- it's PHI but we should be particularly sensitive around these.
I do understand that FHIR does not currently have standards in place for filtering out specific data elements, but I think this is something we will want to consider in the future, and I suspect that it will be easier to filter out sexual orientation if it is given its own Observation profile, as opposed to having to filter out a specific data element from the Patient resource.
I am in agreement with @John Moehrke on this -- I do feel that sensitive data will be more easily controlled as an isolated profile in Observation -- even if this is something that we have not agreed on yet at present.
Could you share more on how the Gender Harmony discussions are going? Or could I listen in on a call the next time you discuss this topic?
Cooper Thompson (Feb 09 2022 at 23:10):
We are de-scoping sexual orientation for now. Sexual orientation was never in scope for the Gender Harmony project, and was an "optional" tag on for the workgroups if we wanted to work on it at the same time as we incorporated the Gender Harmony data classes. There are folks who have strong opinions that sexual orientation NOT be in Observation. So we are just not going to deal with it for now, since it is controversial and we have timelines we need to meet for the other core Gender Harmony data.
Cooper Thompson (Feb 09 2022 at 23:12):
Regarding the privacy concern - I'm not convinced by that at all. There might be reasons for using Observation, but if putting something in Observation vs. Patient impacts privacy, then the FHIR server is already busted from a privacy and data security perspective.
Bret H (Feb 09 2022 at 23:15):
pardon the moonlighting, but where's 'pro-noun' choice going?
Cooper Thompson (Feb 09 2022 at 23:16):
The current plan is to put pronouns in an extension on the "person" resources (Patient, Practitioner, RelatedPerson, Person). Details here (at the bottom): https://confluence.hl7.org/pages/viewpage.action?pageId=130483090
Bret H (Feb 09 2022 at 23:18):
thanks!
Eric Haas (Feb 09 2022 at 23:56):
re sexual orientation in Observation see latest USCore to meet USCDI v2: http://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-observation-sexual-orientation.html
Daniel Venton (Feb 10 2022 at 13:32):
Cooper Thompson said:
Regarding the privacy concern - I'm not convinced by that at all. There might be reasons for using Observation, but if putting something in Observation vs. Patient impacts privacy, then the FHIR server is already busted from a privacy and data security perspective.
I agree with this, no matter where the information is recorded, if the information is prohibited from being disclosed to the user then it's prohibited from being disclosed. It's one thing for a Dr. sitting in the office reading the screen and talking to the parent and not saying "sexual orientation", it's another for automation to not say it. That needs to have some explicit (machine processable) location for the sensitive data and that sensitive data can only be recorded in that one place (it could be many, but the more locations, the harder to implement). If the expected location is Observation XY for sexual orientation it's one thing to code the server "If the subject is a minor and the user is the guardian then skip this resource." However, if the rule is, "XY might be in patient.extension, might be in Observation, might be in the ClinicalNote.narrative....." Then it's a lot harder to ensure all references to XY are skipped.
Cooper Thompson (Feb 10 2022 at 13:55):
@Daniel Venton - but you need a bunch of property level controls anyway. I just don't think resource-level controls will ever cut it.
For example, for patient-facing contexts, you probably don't want to show the full name of nurses (to protect the privacy of the nurse). So any time you have a reference to the Practitioner for the nurse, you need to screen the display name on the reference property (and possibly only show the first name, rather than the full name). Where for provider context use cases you'd likely show the full name.
Cooper Thompson (Feb 10 2022 at 13:57):
Again, I'm not arguing against sexual orientation in Observation, I just don't think privacy / data security considerations are one of the primary factors for determining where we put it.
Cooper Thompson (Feb 10 2022 at 13:59):
The nurse scenario is just one example of many. If we weren't doing property level controls in our FHIR server, we'd consider most of our FHIR APIs to have massive data security problems.
Daniel Venton (Feb 10 2022 at 14:40):
Absolutely, there is going to have to be a data filter between the data store and the output of the server that can consider things like user, subject, purpose of use, location of data, location of user while using that information to limit resources and attributes of resources that are returned to the consumer. AND for purposes of information blocking be very clear why the information was blocked.
Daniel Tam (Feb 10 2022 at 18:00):
Thanks all. Sounds like we are tabling discussion on this topic for now? My company is planning to include sexual orientation to meet USCDI v2 -- we are going to include in an observation or observation profile for now. If a standard is ever decided on in the future I think it'll be easy to identify these data elements and move them to another appropriate resource / profile, if needed.
Overall, I just think we need to figure out where we want to record this particular data, and how we address the privacy concerns in the future.
It may be that FHIR doesn't need to change, and we ensure that patients understand that when they authorize access to a FHIR server, the FHIR server may return particularly sensitive info (including sexual orientation, drug use status, STD status, etc). In America there are state laws that also vary from state to state.
Daniel Venton (Feb 10 2022 at 19:26):
We have to remember that in some situations the actual subject isn't doing the authorizing. A guardian is authorized to get the minor child's health data, they are not authorized to self authorize access to sensitive information. The minor child may not even know the electronic exchange of information is happening.
Daniel Tam (Feb 10 2022 at 21:23):
Thanks Daniel. Agreed and this is the type of scenario I was thinking about. Like say a minor / tennager is in the ER and the parent authorizes access -- is there a concern the parent may see something that would be damaging to the minor? I think this is a broader privacy item we'll want to think about in the FHIR community.
Eric Haas (Feb 10 2022 at 23:27):
Thanks all. Sounds like we are tabling discussion on this topic for now? My company is planning to include sexual orientation to meet USCDI v2 -- we are going to include in an observation or observation profile for now. If a standard is ever decided on in the future I think it'll be easy to identify these data elements and move them to another appropriate resource / profile, if needed.
US Core is the USCDI v2 FHIR standard being decided. check it out here: http://build.fhir.org/ig/HL7/US-Core/general-guidance.html#us-core-data-for-interoperability
Grahame Grieve (Feb 11 2022 at 01:04):
I think this is a broader privacy item we'll want to think about in the FHIR community.
Generally we assume that there are such policy choices in multiple places, and we provide the infrastructure to interoperate around the choices, but we do not make them or dictate them. Certainly the API should make it possible to implement them.
Jose Costa Teixeira (Feb 12 2022 at 20:40):
I hope we can work out the scenarios for the Permission resource which is intended to cover these aspects - which parts of the data can be shared/stored by whom, with whom, for what purpose
Jose Costa Teixeira (Feb 12 2022 at 20:46):
IMO whatever solution works for sexual orientation would work also for more challenging cases - like sharing certain drugs in a medication list (disulfiram, naltrexone) or certain treatments
Daniel Tam (Feb 14 2022 at 18:15):
@Eric Haas Thanks for that profile -- we are going to use that at One Medical for now. Will be interested to see what the long term decision is w/ US Core
Last updated: Apr 12 2022 at 19:14 UTC
