PDA Design Patterns
Design the system configuration for decentralized self sovereign data
Last updated
Design the system configuration for decentralized self sovereign data
Last updated
In this architecture, your app only needs to read/write into the app’s own namespace with no access to other namespaces. Data is written and read from the app folder only (as a tenant of the data account) and nowhere else. This design has no analytics or data being processed.
This solution pattern can also function as an ”identity-blind” pattern where no data, even those within the PDA, contain any personally identifying information at all.
The app records user information into the PDA. The information in the app namespace goes to your app's back-end, or product server in the diagram, to be analysed and the analysis returns new data to the PDA.
The app records user information into the PDA and the tools compute the information to return something e.g a health score or credit rating back into the app namespace. The information in the app namespace goes to a back-end process to be analysed and the analysis returns new data to the PDA. No personally identifiable information (PII) is in the namespace.
Your app writes sensitive PII data into a PDA that is regulated and needs permission from a guardian PDA (guardian/trustee) in order to accept the data contract. PDAs and apps will feed information into the back-end process that will show product analytics utilising information from the PDAs and app itself. Benefits of this solution include but are not limited to: guardians, trustees not able to monitor PDA content but can approve the contract; ability to optionally include a back-end process that will produce analytics using multiple PDAs and app data without identifying users.
Example use case: Organisations using PDAs for employee or student records
The app writes information into contracted PDAs which simply means the PDA owner cannot cancel the data debit or contract without the organisation's permission. The PDA owner also cannot delete the PDA. The app back-end, described as the "Product Server" in the diagram, is able to access the contracted namespace and produce analytics or simply read and merge information as needed.
In this design, businesses have control of information pertaining to them and the PDA owner together e.g building access control logs that need to be retained. The business is allowed to read and produce analytics regarding the data stored in the PDA and ship to the required enterprise systems.
PDA owners are still private across all other folders in the PDA.
Example use case: The nursing home app
This app gives nurses the ability to store and keep patients records electronically rather than on clipboards. Multiple nurses access these patient records at different times in order to administer medication and track various checklists while the patient is in care.
The architecture below shows a single app that nurses will be able to use/interface with as they record data. All patient data will be kept in regulated PDAs that are HIPAA certified.
Contracted PDAs are given to nurses who will have access to multiple namespaces (regulated PDAs) so they are able to read/write information into these PDAs.
Guardians with default PDAs get permission from the nursing home (who owns the nursing app) to view data within the regulated PDA.
Regulated, contracted and default PDAs will talk to the app back-end or product server, analysing which patients need tending to, need the next round of medicine, etc, alongside confirmation of the guardian providing access to the patients.
Regulated PDAs may have other rules for auditing purposes.
The back-end or product server will produce the necessary analytics and push information back out to the app that the nurses are using. Benefits of this solution include: HIPAA certified back-end, access for nurses to multiple PDAs (namespaces) with access control by the nursing home.
The app will have permission to read and write into the app’s own namespace with no access to the other folders in the PDA. The app will redirect to the PDA for the PDA owner to install the data plug or connector, which will be acquired from elsewhere. The data plug will input information into the user's PDA.
There are two apps in this model, one facing businesses and another facing consumers. The apps feed information into the PDA and use a file storage add-on, as well. The information between the apps goes to the business app's back-end, or product server, which provides further analysis and is able to feed information back out into the two apps or straight to PDA. The back-end process is also able to send further information out to enterprise systems to enrich other systems in that organisation.
There are two apps in this model, one facing businesses and another facing consumers. The apps feed information into the PDA and use a file storage and tools add-on. The information between the apps goes to the business app's back-end, or back-end process, which provides further analysis and is able to feed information back out into the two apps. The back-end process is also able to send further information out to enterprise systems and other systems to enrich other systems in that organisation.
The app stores sensitive PII data within a PDA and uses the data plug to enable the user to get data into their PDAs. The app may feed some of the information into another app's back-end, or product server, to perform further analytics or store non-sensitive user data as needed.
In a strong case study, OneZero-Me provides risk scores for insurers and lenders based on alternative data. They have a client-facing "financial passport" app and a Facebook data plug or connector. The data plug feeds information to the PDA and the back-end process is able to take the information and conduct an analysis on the individual to assess the risk of lending to this user. This is then conveyed back via the app.
