openreferral / api-specification

This is the working repository for Open Referral's Human Services Data API protocols.
https://openreferral.readthedocs.io/en/latest/hsda/
Other
29 stars 13 forks source link

Approval and feedback #34

Open kinlane opened 7 years ago

kinlane commented 7 years ago

Opening up a thread dedicated to the approval, feedback, and auditing flow for the platform, that allows anyone to update a record in the system, but there is an approval flow that can be applied before the change is accepted.

This area would overlap with the meta data conversation which involves the change log and logging - https://github.com/openreferral/api-specification/issues/28

NeilMcKLogic commented 7 years ago

We already have use cases where this is necessary but I'm wondering if/how this would be integrated into HSDA. When someone submits any change to a record via the API, in some cases the change will need to be held aside temporarily until an authorized human can review and approve it for a lot of very important reasons. Perhaps we need something to indicate the status of any POSTed change requested (e.g. pending, approved, rejected, etc) that could be included both in the initial Response to the Request but also queried later.

kinlane commented 7 years ago

I have an initial draft of how HSDA meta + HSDA management will handle this. The one thing the Human Services community is missing currently is the notion of API service composition, which is a staple of API management in the mainstream space. Where APIs (/paths) + VERBS (GET,POST,PUT, DELETE) (services) can be composed into a variety of tiers that users have access to--who can read, write, rate limiting, etc. I've added a project to help move forward the conversation I"m calling HSDA Management, which borrows from the mainstream.

HSDA Manament will work in conjunction with the HSDA meta which records all API transactions, and HSDA orchestration (webhooks, events) to execute an approval / feedback system. Some examples of this could be a POST of an organization that occurs, and is recorded in meta as transaction, but because user doesn't have access in service composition, it doesn't update. After a webhook, email, or other goes out, the transaction can be approved, declined. This would allow this type of approval to exist at the transaction level for each API call, or for batches of API calls (bulk loading). HSDA meta would allow for auditing, rollbacks, of ALL API activity.

More to come on this, as these system get flushed out.