Stream: implementers
Topic: Seal/unseal status of a patient account
Kalindu Perera (Jan 04 2022 at 09:10):
Hello everyone, I am working on implementing a function to comply with Swedish law for patients, patients are allowed to fully seal their account from accessing for themselves in case if someone try to forcefully use their login to check their medical information, but care providers can check the medical information of that patient and also unseal the account when they get approval from the patient. What resource will be perfect for keeping this sealed and unsealed status?(I cannot use the active field in patient resource since it’s meant for other use case),I have already checked the provenance and consent profiles but Im not sure which one to use. Else should I add a extension to the patient profile? can you all please help me :smile:
René Spronk (Jan 04 2022 at 09:17):
I'd say Consent or http://build.fhir.org/security-labels.html - if you need to capture data about the process of sealing/unsealing (who did this, and when, etc.) Consent may be the best thing to look at. @John Moehrke ?
Kalindu Perera (Jan 04 2022 at 09:58):
Thanks a lot...!!!! @René Spronk , i just have very small requirement to just send the sealed or unsealed status with patient profile that status is related to so i will check the security-labels as well, Thanks again :smile:
John Moehrke (Jan 04 2022 at 13:44):
Yes a security-label can be applied to the data to indicate that it is under specific restrictions. There is the overall gradient in the ConfidentialityCode vocabulary, where "Restricted" is similar to what you speak of. However the use of security-label is problematic in that the data tagging is at the data level, and this kind of use would then require an update of all the data when the patient chooses to unseal. This presents a problem for medical records integrity, even though the changes can be masked and/or have provenance.
The better solution is to track the status of the sealing with a Consent resource. From your use-case explanation, this sounds like a typical Consent resource use. In this case, there might still be data tagging to indicate that the data are sensitive, but the status of sealed vs not sealed is managed in a Consent resource.
René Spronk (Jan 04 2022 at 13:52):
I agree that might be the better solution - one could go for a security tag just on the Patient, to signify that all of that patient's records should be considered as 'being sealed'. A more ad-hoc solution of course, which uses a more implicit way of sealing the entire record, but one that would work as well (depending, as always, on how the systems that use FHIR resources have implemented their data access controls).
Daniel Venton (Jan 04 2022 at 16:14):
This sounds like it's on the consumer of the data to abide by the sealed status of the medical records. The server is only responsible for stating that it's sealed, not enforcement? If so then don't you have to have a standard (defined by Swedish government), otherwise the server says we put "sealed" in flag X and the consumer says, we looked for "sealed" in flag 42. Effectively meaning that no charts would be recognized as sealed by the consumer.
René Spronk (Jan 05 2022 at 07:47):
We don't know the exact context, but as a rule European infrastructures don't rely on a consumer to enforce access control, it'll be up to a server. Sending data to a consuming system is effectively a disclosure, and a breach of privacy rules (GDPR in this case), regardless of whether the consumer chooses to display (or otherwise process) that data or not.
John Moehrke (Jan 05 2022 at 14:19):
For the most part any B2B communication has either an implied or inline definition of the rules of how data released to the recipient party can be used. Much of the time these rules are applied as a whole to the data released (e.g. This data is released to you for PurposeOfUse of "Treatment". In this case the data is not to be used for anyother purposeOfUse than "Treatment"). I refer to this as rules applied to the whole transaction, I would express these in the Bundle.meta.security but these rules might be implied).
There are further refinements, as expressed in the HL7 DS4P, where data released might have on each data object (i.e. FHIR Resoruce) various tags that might further refine the handling rules within the broad PurposeOfUse at the transaction level. These are either tags on the specific object .meta.security as tags expressing that specific data. Tags on data should not be specific to policies that might change over time, they should be "meta" purely about the data.
Where the refinements might change over time, these refinements might be further expressed in a Consent as a set of .provisions. There is little (some) practical experience with this. The advantage of Consent.provisions is that these expressed rules are independent of any instance of data, and thus have a lifecycle themselves.
There is a Permission resource that we have drafted into the FHIR core that would be able to do the same as Consent, but be less about a patient-giving-consent and more focused purely on the rules. In this case the rules could be expressed in a Permission and the reason the Permission(s) exist is a Consent. -- However this effort has not moved very fast due to lack of engagement from those needing this solution. So if this is what you need, please join the Security WG and help define the use-cases.
Last updated: Apr 12 2022 at 19:14 UTC
