Stream: implementers
Topic: Sealing an Encounter
Simone Heckmann (Nov 27 2019 at 14:33):
Is anyone aware of any specifications/ongoing work/planned work around closing/sealing an Encounter?
Roughly, this might be something like an operation a primary system could use to inform all subsystems that all documentation pertaining to a specific encounter has to be "sealed" (aka put into read-only mode).
Internally, this could be implemented by slapping a security-label on the affected resources. Although I couldn't find one that fits this usecase specifically.
Are there other/better options to implement this?
Lloyd McKenzie (Nov 28 2019 at 00:38):
@John Moehrke @Brian Postlethwaite
John Moehrke (Nov 28 2019 at 15:38):
The medical-records lifecycle of a object has usually been the responsibility of the business object status. http://build.fhir.org/codesystem-resource-status.html
John Moehrke (Nov 28 2019 at 15:38):
I was surprised to not find a code that indicated that the object should be frozen.
John Moehrke (Nov 28 2019 at 15:38):
@k connor ??
John Moehrke (Nov 28 2019 at 15:40):
Certainly you can freeze a version with a Provenance, but that is not something that prevents the UPDATE action.
Lloyd McKenzie (Nov 28 2019 at 15:54):
Frozen makes sense to handle as a tag as it's something that's typically server-specific. A Condition record that's 'frozen' on your system might not be frozen on mine.
Simone Heckmann (Nov 28 2019 at 16:25):
Actually we have a regulation/recommendation in Germany, stating that access to patient records should be restricted after certain events occur. Some of these events will only be known to one specific system (e.g. billing system).
So a part of my question is: Do we have a way of communitation from one system to another that certain flags need to be applied to all resources in a patient/encounter compartment to enforce these restrictions?
I'd tend to define an operation for our use case , but I was wondering if there is work happening that we could reuse or build on...
On a related note: wenn scrolling through the existing security flags, I found the BTG (break the glass) option. However, from the definition, it is not clear to me whether a Resource with this Flag can also be accessed ba users without direct permissions by using the break-the-glass-protocol or if a Resource with this Flag can only be accessed through BTG, even if the user does have read permissions.
John Moehrke (Nov 28 2019 at 19:28):
It is possible to have a frozen code, and an operation to communicate at a patient compartment level to freeze..
John Moehrke (Nov 28 2019 at 19:31):
There are many vocabulary in the HCS that should never be used on data, they are to be used on security-context, or on a returned Bundle to indicate the residual obligations. More specifically the BTG vocabulary is not a mature thing. Most of the time, historically, BTG was a completely proprietary thing. Moving into Interop layer has not been well prototyped. I have seen 4 totally different ways to handle the use-case. So don't believe that each vocabulary in there is highly mature.
k connor (Nov 28 2019 at 19:58):
My take: To lock a record, use the confidentiality code "very restricted" to indicate "legal hold" which would only allow highly privileged personnel to do anything with the record. RE use of BTG flag and a legal hold confidentiality code - that' would require a policy that permitted BTG even with VR confidentiality code. Possible solutions: (1) To indicate that an organization has a policy that permitted BTG with VR, then use ActCode_ActPolicyType_ActInformationPolicy.OrgIP with the proposed security label extension for RelatedArtifact to point to the policy url. (2)ActCode_ActPolicyType_ActInformationActionPolicy.INFOREADONLY defined as "Authorization to access information within a specific context for communication purposes only. Storing, manipulating, and further disclosure are prohibited and may be technically disabled." (3) Another approach, that I'll bring forward if others think it makes sense for this use case, is to add a INFOLOCKED code to ActInformationActionPolicy defined as ".Authorization to access information within a specific context for communication purposes only. Storing, manipulating, and further disclosure are prohibited and *has been *technically disabled
k connor (Nov 28 2019 at 20:04):
INFOREADONLY is here http://build.fhir.org/v3/ActCode/cs.html
Mohammad Jafari (Nov 29 2019 at 16:24):
@Simone Heckmann I'm wondering if there is a reason INFOREADONLY won't work in this case. It seems like it matches the use-case.
Simone Heckmann (Dec 04 2019 at 13:42):
@Mohammad Jafari
None, except that INFOREADONLY is currently not a part of the ValueSet bound to mety.security
http://build.fhir.org/valueset-security-labels.html
John Moehrke (Dec 04 2019 at 14:17):
That is not a restriction... the valueset is in Extensible binding. So given there is no appropriate code, you can bring in codes from elsewhere... right?
John Moehrke (Dec 04 2019 at 14:18):
That said, we have recognized that there is a need and a gap... so will be looking at this. Thanks for bringing this to our attention
k connor (Dec 04 2019 at 18:59):
Isn't there a way to ensure that any new codes in certain parts of the v3 code system will automatically be added to the valueset-security-label? New security label codes/descriptions and only security label codes generally land in the following places: ActCode_ActPolicyType, ActReason_ActInformationManagementReason (POU), and Confidentiality. Infrequently, there are changes in security/privacy related codes at ActCode_Observation.SECOBS, ObservationValue_SecurityObservationValue, ActCode_ActConsentType, Act_ActInformationAccessCode, ActCode_ActInformationAccessContextCode and DataOperation. These are not currently used for FHIR security labels. So generally, changes to ActCode_ActPolicyType, ActReason_ActInformationManagementReason (POU), and Confidentiality v3 code systems should (automatically if possible) be added to the FHIR valueset-security-labels.
John Moehrke (Dec 04 2019 at 19:01):
I think this is simply the definition of what the ValueSet is made up of. If the FHIR definition of the ValueSet is wrong, then we can fix it.. however if the HCS definition is not incusive enough, then the HCS needs to be fixed.
k connor (Jun 24 2020 at 22:47):
There are definitely problems with getting approved v3 vocabulary into FHIR. Not an issue with HCS. Now more of the missing codes are showing up in UTG as they are structured in v3. But unfortunately, the IG tooling doesn't support pulling in the UTG valuesets. This is blocking work that Mohammad and I are doing on the FHIR Data Segmentation for Privacy IG.
Last updated: Apr 12 2022 at 19:14 UTC
