Using cQube for creating Data Dashboards from various Federated datasources (Data generated from Sunbird RC Instances as well as Custom Software)

[parthlawate]

We are creating a packaged Solution for registries, credential issuance , benefits for the Education sector & want to see how cQube can be used as an aggregated dashboard across various Federated Data sources. The attached image shows the high level solution expected.

The above example shows the following different data sources.

A. Sunbird RC based National & State State Student Registries as well as Homegrown Custom Applications for Teacher, Institute Registries
B. A Multi tenant Issuance portal where multiple issuers can issue different type of credentials
C. A Custom Built Issuance Portal where a central issuance authority issuers its credentials
D. A Benefits Portal where various Benefit Schemes can be discovered , applied to & availed

An Aggregated Data Dashboard with State, District level Drill downs needs to be part of the solution. We seek advise as well as help from the cQube community to build this & package this in a 'Starter Pack'.

Please do advise on how this could be achieved.

cc @sukhpreetsamagra @ChakshuGautam @surendrasinghs @rahul101001000 @pramodkvarma @rhwarrier

[rhwarrier]

This also needs to take into account the need for metrics such as count of UUs across Registries - which could involve de-duping records using unique linking keys such as the Aadhaar token, for example.

[parthlawate]

@rhwarrier .. Can you describe what is meant by 'UUs' please ? Do you mean Unique Users ? If so - yes thats right.. The first counts you see of Students Enrolled, Male/Female breakdown is a Union of data across a National & state registry to get the unique total

[rhwarrier]

That's correct - unique users across registries. Say count of unique users who have been awarded benefits across multiple issuers

[parthlawate]

correct the eg - "12,39,000 Credentials Issued To Female Students" is such a metric.. Total Credentials issued across multiple registries, multiple issuers

[surendrasinghs]

Interesting use-case! @parthlawate @rhwarrier

@ananya-jain1 @ChakshuGautam @sukhpreetsamagra @santhoshv - I believe this can be achieved if Sunbird RC APIs emit events in Sunbird telemetry specification. I think RC should aggregate/summarize the raw telemetry events before sending it to cQube, right?

[SanthoshVasabhaktula]

@surendrasinghs - The metrics can be derived out of the underlying transactional data itself. The aggregated metrics then can be published to cQube in a scheduled fashion (daily or weekly).

[rahul101001000]

There are four use cases here, would be great to get your advice @SanthoshVasabhaktula on each of these -

1. Credentials with transaction data accessible by issuer
2. Credentials with transaction data that can't (shouldn't) be accessible by issuer - think of credential issued that a person has A+ blood group. The testing agency shouldn't be to do any analytics on this data of all users. In this case can the data itself be encrypted so that it is accessible by consent of holder but no one else?
3. Credentials part of cloud wallets of holders (like Digilocker) stored in a multi-tenant set up - a program should definitely not be able to access all of these.
4. The event of credential generation published by the issuer, so that others in the system may trigger other events based on that. e.g. when birth certificate is issued by department A, then SMS for vaccination should go out from health department B post 3 months and then from education department C in 3 years.

Running queries on transaction data works for 1, should not work for 2, 3 and doesn't help with 4. Emits on the other hand may actually work to solve for 1, 2, 3, 4 and these would be done by issuer at credential generation time without needing access to credential once that is done. Any downsides on using emits as @surendrasinghs is suggesting?

[SanthoshVasabhaktula]

@rahul101001000 - I was referring to the anonymised aggregated metrics that each RC instance can publish as an exhaust. This exhaust can be ingested into a system like cQube. I am assuming we are only discussing on creating a starter pack for these metrics in cQube.

In my view RC emitting actionable events and providing anonymised aggregates are two different use-cases. We can create a new discussion thread in RC forum on how RC can generate the aggregated metrics.

[rahul101001000]

Got it, makes sense. Thanks @SanthoshVasabhaktula

Will start a different thread on actionable events.

Regards
Rahul

[parthlawate]

@rhwarrier has started a thread on this https://github.com/orgs/Sunbird-RC/discussions/356

@rahul101001000 @SanthoshVasabhaktula Do chip in there