Release Of Information (aka Client Consent) Requirements and Implementation Considerations
Releases of Information are client authorizations for their information to be shared within and external to a project.
Client consent authorizations are not specifically required by HMIS regulations, but are legally underpinned by HIPAA and 42 CFR Part 2, which can pertain to some HMIS collected information, depending on the program and/or context. Also, HUD Continua of Care often have administrative policies for the collection of client consent.
When a client implicitly (because a sign was overhead stating they are consenting by using the service, etc.) or explicitly (signs a document, or verbal consent), a "release of information" is recorded within the system.
The release of information has a time span (a start and end date), a set of agencies or projects to which the release is granted, and any artifacts recording the client consent (scanned documents, voice recordings, etc.).
The release of information is then enforced by access control to the client recorded information.
"Because Consent-to-Share is now in effect, by default searches will turn up no results -- no Clients will be displayed. However, if the user doing the search has proper authorization ("consent") on the relevant fields (e.g., FirstName, LastName), then matching Clients will be returned, and the only information displayed about those Clients will be information that the Client consented to be shared with the org or CoC of the user who ran the search."
The client's consent to share should be tied to the client's unique global id, not to their HMIS project enrollment or other HMIS or other funding stream construct like Continuum of Care, etc..
The consent will then specify to which entity their information sharing consent is applicable to. That consent must be tied to a funding stream or other construct, whether it is blanket to an organization (an HMIS defined organization or a generic/global business record), an HMIS project, a Continuum of Care, etc.. Consent can also be granted to certain specific projects and certain organizations.
A caseworker or other project/organization affiliate with a user id (submitter id) can request client consent. When that request is made, which type of records are requested, and the state of the client consent is pending. This request is stored as a transaction and persisted. If the client accepts the request for consent, then the consent is approved, and that status is persisted as a transaction as well. Alternatively, if the client accepts the request for consent, then the consent is approved, and that status is persisted as a transaction as well. Regardless of client approval state, any submissions return a consent ID in the response. The state of the consent can change of time, and even be retracted (which would cease accessibility to the retracted client information moving forward).
A client can specify categories and types of information to be shared. Granular client identifiers are not supported, but broad categories of sharing are. They may include:
- client personal identifiers (all or none)
- service records
- funding stream limitations (specify HMIS projects, organizations, CoCs allowed to see records, specify projects not allowed to access)
- anonymized consent (a client approved data use for research and other purposes if their personal identifiers are first deidentified).
Support consent deletion.
We should try to implement this in phases. Access control of records should be the first task, then document storage in S3 a later feature.
Architecture for storage and syncing of the consent docs
Precursor to HSLynk's Client Consent API by @kfogel at: https://github.com/hmis-tools/hmis-api-server/blob/master/docs/API.md
Should there be the ability for a client to grant/release certain personal identifiers and not other identifiers?
/consents/ {consentId} DELETE simply inactivates the consent
The existing implemented Client Consent API must be activated on a project group level, but be careful doing this, because the default is no sharing access, unless there is consent.
"In light of the doc-upload service expansion, I think we'll need to release consent without the supporting doc upload feature initially. And then we can put the consent_id as a property of the consent-doc-upload APIs, so people can retroactively attach consent-docs to a preexisting consent record."