Stream: implementers
Topic: System to system communications
Josh Lamb (Jan 01 2021 at 18:02):
Hello,
I am looking for some feedback to help clarify my understanding of how access rights can be verified between disconnected systems.
During my research, it seems that a shared understanding of roles (permissions) is the way to go. This can be called role-based awareness.
Need for Role-Based Awareness
Role-based awareness is critical when the requestor's identity does not exist in the fulfilling system, OR if access rights have changed. For example, the system fulfilling an access request may not possess provider identities and must rely on role-based lookups instead. Provider identities are also more complex than member identities since a single provider may have multiple identities (NPI, TIN, Speciality combinations), each with different access rights.
If the fulfilling system cannot locate an identity OR if access rights have changed, the individual fulfilling the data request would need to reference a trusted source to inform what access rights are allowed (role-based awareness). Identities in healthcare are not static (e.g., creation of POA). The historical identity information contained in a health system may not reflect the most recent access rights. Cross-system access requests must have a coordinated understanding of access rights for information to be sent securely.
Thanks!
John Moehrke (Jan 01 2021 at 19:12):
realistically this is too complex to maintain on that scale. This is why the model generally used today is PurposeOfUse. a federated assertion token is issued indicating who is requesting and what roles they have, but this is just used by the responder as informative mostly for audit logs to indicate the triggering agent at the requesting organization. What is more important is the PurposeOfUse(s) within that assertion, and the organization claiming that token. As any request for data will be used not just by that initiating user (which might be a human, but might just as well be an automated process kicked off based on tomorrows schedule). It is this Organization identity and this PurposeOfUse(s) that are fed into the access control decision. Because any release of data will need to be entrusted to that organization and the full set of PurposeOfUse(s) requested.
This is not to say that better can't be achieved, but it is well into the future that will happen.
To this future, the Security WG has provided a standard set of Functional and Structural roles. There are some codeSystems managed by HL7, and others that are managed by ISO. Both are pretty close, mostly differing because of the people/organizations participating in the various standards organizations.
All of this is nicely documented in the FHIR specification http://hl7.org/fhir/secpriv-module.html
- Security Role Vocabulary http://hl7.org/fhir/secpriv-module.html#user
- Authorization/Access Control http://hl7.org/fhir/security.html#binding
If you have improvements, please submit a Change Request
Josh Lamb (Jan 01 2021 at 22:34):
Thanks @John Moehrke, this is great information.
I agree that building and maintaining a repository of "who can access what" is unrealistic.
I have heard a few proposals:
- Carequality (who has role awareness)
- Blockchain (allow shared ledger and trusted updated but not used industry-wide and fragile designs)
- Consent models (seems like another way to build out role awareness to me...)
- Purpose of use (I will need to look into this one, but it seems like a way to "tag" data for an intended purpose, this seems like it will be a maintenance nightmare too, since the role assertions may not be valid forever or only apply to a specific piece of data)
I will dig into this more, seems there is still more to learn.
Thanks again!
Last updated: Apr 12 2022 at 19:14 UTC
