Stream: implementers
Topic: Patient - cluster confidentiality
Lital Inghel (Jan 05 2022 at 08:20):
hi
regarding patient confidentiality
we are an HIE aggregating data from multiple sources and performing patient cauterization using EMPI
it means 'patient'=cluster (each cluster can have multiple indexes belonging to one same patient cluster)
in case a patient is a cluster of indexes-
currently we will present the demography based on one 'leading' index
BUT-
what to do in case of multiple indexes with different confidentiality codes (for one cluster)-how will we represent that in the patient resource?
John Moehrke (Jan 05 2022 at 14:06):
I am not sure I fully understand. But, in the domain where security-tagging is used there would always be possibilities that some data are more sensitive than others. The sensitivity/confidentiality/integrity/etc tagging is facts about that data element, and these facts are used to filter data out that a use session does not have access to. So multiple sources doesn't seem to be a further complication. Thus I am thinking that I am not fully understanding the situation you are describing.
John Moehrke (Jan 05 2022 at 14:07):
so can you give an example?
Elliot Silver (Jan 05 2022 at 15:40):
I'm not sure I understand either, but it sounds like a situation that might benefit from multiple Patient instances for the same Person. Each Patient, and all resources related to that patient would have a different confidentiality code, but the central demographics are tied together in the Person.
John Moehrke (Jan 05 2022 at 15:44):
I was wondering if it was that kind of a situation. More of a Patient Cross-Reference, than a Merged Patient instance.
David Pyke (Jan 05 2022 at 16:02):
Yep, it sounds like you'd have a master Patient with Patient.link referring to other Patient records that have different confidentiality assigned, possibly with Consent records handling each.
Gino Canessa (Jan 05 2022 at 16:06):
Hmm.. I read the original as (for example):
- 2 Patient records from different facilities for the same person
- Record A does not have any security tagging
- Record B does have security tagging (lets say
Patient.address, again just to have something concrete) - Both records have the patient's address
What should the HIE provide? With both records having the same data, should the security tag 'propagate' across the records (assuming patient intent), should the 'newer' one win, etc.?
I would probably lean towards propagating the security tags myself (e.g., if the patient has tagged their address as sensitive, assume it should be flagged on all records) - if someone really needs the data, there should be a 'break the glass' way of accessing it anyway. But, I will qualify that with noting I am not an expert in the area =).
David Pyke (Jan 05 2022 at 16:08):
In general, the information should be sensitive for all instances and only have exceptions for individual facilities/providers. So, if the patient has marked it sensitive for Facility A and not for Facility B, then requests from Facility B can see it, but not Facility C,D or E.
Lital Inghel (Jan 05 2022 at 16:12):
David Pyke said:
Yep, it sounds like you'd have a master Patient with Patient.link referring to other Patient records that have different confidentiality assigned, possibly with Consent records handling each.
yes, exactly
Gino Canessa (Jan 05 2022 at 16:31):
David Pyke said:
In general, the information should be sensitive for all instances and only have exceptions for individual facilities/providers. So, if the patient has marked it sensitive for Facility A and not for Facility B, then requests from Facility B can see it, but not Facility C,D or E.
I think the issue is that if this is an HIE and they are servicing requests for 'John Q. Patient', the requestor receives all the records - tagged and untagged. To me, that means that if a single facility does not support security tagging, it overrides the patient's desires from all of the facilities that do.
David Pyke (Jan 05 2022 at 16:33):
That's why you'd need to have Consent records filtering per identifier/facility. That way only the information permitted is sent.
John Moehrke (Jan 05 2022 at 16:39):
You two have gone off onto your own use-case analysis, an analysis that could go anywhere given it is an unstated use-case.... That said, yes it is important for some policy to express how one joins domains that have different tagging abilities. Much like one needs to have rules for how to join domains that have different clinical quality of their data. And also, one must have policy for how/if/when data are released to a data recipient that is known to not understand/enforce data level tagging. Often the answer is that the data are withheld because it is known that the recipient can't distinguish well enough and be trusted to enforce fine-grain tagging enforcement... However, that is policy.. and that is driven by use-case... I don't think that Consent is specifically a MUST to resolve that policy, it would certainly be the right thing to do from a Privacy Principles perspective.
John Moehrke (Jan 05 2022 at 16:40):
- example: Where one domain uses LOINC and another uses SNOMED... a join must harmonize these somehow... same is true with security tags.
Gino Canessa (Jan 05 2022 at 17:01):
:shrug: I thought I was restating the original question - e.g., how does an aggregator handle the fact that source records have different security tagging? What can/should the 'master Patient' record contain - only elements that are always untagged, or elements that are untagged in at least one record?
Yes, at the end of the day it will just be that aggregator's policy.. just like most 'decisions' in healthcare (even those informed by common practice/regulation/etc. =). But I think it's an interesting question and am curious if there is guidance/best practice/etc. for that type of scenario already.
To use your example, there is a 'best practice' of actually harmonizing LOINC and SNOMED, and CodeableConcept allows for using both.
John Moehrke (Jan 05 2022 at 17:19):
I am not against having that discussion and coming up with recommendations. i just was unclear that was the problem given that the original author answered YES to Dave's guess.
John Moehrke (Jan 05 2022 at 17:20):
so I was looking to first make sure @Lital Inghel got fully his use-case addressed before we took over his thread on a different (possibly different) topic.
John Moehrke (Jan 05 2022 at 17:23):
I am not sure there is a 'best practice' around harmonizing multiple datasets where one uses LOINC and the other uses SNOMED. Could be that the data are simply left as-is; might be that the aggregator is expected to convert the SNOMED into LOINC, the aggregator is expected to add LOINC to the SNOMED data, respond to queries for the LOINC equivalent but don't change the data, etc... Not clear to me that there is any 'best practice' stated other than 'the aggregator must decide', which is the same thing I said about security tags.
John Moehrke (Jan 05 2022 at 17:29):
if there was a dataset that was marked as higher confidentiality; I would agree with Dave's assertion that 'best case' is that the patient be confronted (sorry for the aggressive word) with what the patient wants done in that case. Lacking the ability to confront the patient, as most aggregators don't involve the patient, some business rule is needed. Some organizations, Betty-Ford-Clinic, are known to really have more sensitive data and thus that data likely does need to be handled highly confidential... However there might be a 'normal' healthcare provider that is more advanced than the rest of the community and has implemented a Security-Labeling-Service (SLS). This more advanced SLS use might not need to impact the data in the aggregator. Business arrangements would be needed.
Last updated: Apr 12 2022 at 19:14 UTC
