Relationship Based Authorisation

Improving the reliability, observability and accountability of the existing Relationship based authorisation system

image
0 M+

Users

0 K+

req/s

0

Practitioners

Process

Stakeholder Meetings & Gathering Requirements

Very often when developing new features, the product descriptions were fuzzy. It was very common to have to talk to the stakeholders to understand what is that they really wanted and how it would fit into the current solution. The stakeholders ranged from practitioners, product managers, admin staff and other teams.

Observability

Our services were lacking observability to the services we owned. I built extensive dashboards to monitor the system functioning.

Redesigning Practitioner Onboarding

I was responsible to revamp the practitioner onboarding webapp. There was a new content delivery system that had different resources based on which type of practitioner was being onboarded. I was also responsible of co-ordinating the implementation of the webapp with the delivery of the new content. Made sure the UI reflected the new changes, modified the content schema and documented and educated the admin on how to create the new content using the schema. The project was completed well within the deadline.

Back Population Service

Sometimes there was a system outage in one of the main microservices handling the meetings. This would sometimes cause meetings to be created but the relationship building side effects to fail. This meant the practitioners could not see the patients. I built a service that would reconnect the broken links so that the practitioners could access the patients.

Conclusion

During my time in the authorisation team I helped with the reliability of the critical microservice ensuring smooth operation after a system failure. I also helped a lot with the observability and monitoring of the owned services. Also carried out the design revamp of the onboarding webapp and content delivery system.