KORDEUS - Data retention and deletion concept: Difference between revisions
Jump to navigation
Jump to search
Stefanseiler (talk | contribs) |
Stefanseiler (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
B-op enables: | |||
* '''data pools are freely movable (physically)''' between realms. This enables: | |||
* '''data pools are freely movable (physically)''' between realms | |||
** hosting the data in the legeslative region where they belong without breaking the system (e.g. EU patients cloud, CH patients cloud, US patients cloud) | ** hosting the data in the legeslative region where they belong without breaking the system (e.g. EU patients cloud, CH patients cloud, US patients cloud) | ||
** adhering to all possible regional data retention and deletion plans at the same time - no decisions or compromises has to be done | ** adhering to all possible regional data retention and deletion plans at the same time - no decisions or compromises has to be done | ||
** protect data owners and their data from laws which dont apply to them | ** protect data owners and their data from laws which dont apply to them | ||
* '''differentiation of possession and ownership''' | * '''decoupling of data and applications''' - Applications can use data of remote digitals according to trust levels defined by the data owner. This enables: | ||
** ''' | ** applications may read, access and even write data owned by a using digital or its user. This even works, if the application is hosted at another physical location | ||
** ''' | ** applications may reside in another legal region than the data owners. This delivers true data sovereignty as the application may adhere to other legal regions then the data owner. | ||
** '''data appropriation | * '''differentiation of possession and ownership''' - to enable all of this, b-op has invented data models, which support this differentiation natively. This differentiates | ||
** '''data ownership''' - the owner of data has full ownership and may manipulate and keep/delete data as desired. | |||
** '''volatile data 🔥''' - whever the owner of data shares data with another digital, this is done temporarily. The owner can define on field level which data to make available to the other digital. The future possessor can define on field level, which data he is interested. Although the data is shared, it is still volatile (🔥) and can be physically removed by the data owner at any time. As this is pretransactional, there is no reason and way for the owner to keep the information. | |||
** '''transactional data appropriation''' - whenever the possessor and owner are with mutual consent entering into any transaction, the possessor will typically have to document the transaction in his data-pool and therefore this data becomes [[Dev:B-Op data appropriation|appropriated]]. This means only the specific data required for this transaction (not all shared data) now becomes shared ownership (minimal data principle). These transactions do need to become documented for legal reasons and have a period of time, when this data will be deleted entirely again. At this moment appropriation is reversed and all information is removed and inaccessible to the possessor of information. | |||
===== Data retention and deletion in healthcare with KORDEUS ===== | ===== Example: Data retention and deletion in healthcare with KORDEUS ===== | ||
With thiese new conceptual options, generally all regional data protection laws come with the same requirements on data retention and deletion (see table below): | With thiese new conceptual options, generally all regional data protection laws come with the same requirements on data retention and deletion (see table below): | ||
{| class="wikitable" | {| class="wikitable" | ||
| Line 37: | Line 38: | ||
! colspan="2" |Service Delivery Information | ! colspan="2" |Service Delivery Information | ||
|- | |- | ||
|Policy by | |Policy by | ||
'''EU DS-GVO''' | '''EU DS-GVO''' | ||
| rowspan="3" |'''Owner''' | | rowspan="3" |'''Owner''' | ||
(Never automatically, | (Never automatically, | ||
| Line 45: | Line 46: | ||
| rowspan="3" |10 years | | rowspan="3" |10 years | ||
| rowspan="3" |purpose-limited | | rowspan="3" |purpose-limited | ||
| rowspan="3" |'''Owner''' | | rowspan="3" |'''Owner''' | ||
(Never automatically, | (Never automatically, | ||
| Line 57: | Line 58: | ||
|'''CH nDSG''' | |'''CH nDSG''' | ||
|} | |} | ||
Revision as of 15:45, 6 February 2026
B-op enables:
- data pools are freely movable (physically) between realms. This enables:
- hosting the data in the legeslative region where they belong without breaking the system (e.g. EU patients cloud, CH patients cloud, US patients cloud)
- adhering to all possible regional data retention and deletion plans at the same time - no decisions or compromises has to be done
- protect data owners and their data from laws which dont apply to them
- decoupling of data and applications - Applications can use data of remote digitals according to trust levels defined by the data owner. This enables:
- applications may read, access and even write data owned by a using digital or its user. This even works, if the application is hosted at another physical location
- applications may reside in another legal region than the data owners. This delivers true data sovereignty as the application may adhere to other legal regions then the data owner.
- differentiation of possession and ownership - to enable all of this, b-op has invented data models, which support this differentiation natively. This differentiates
- data ownership - the owner of data has full ownership and may manipulate and keep/delete data as desired.
- volatile data 🔥 - whever the owner of data shares data with another digital, this is done temporarily. The owner can define on field level which data to make available to the other digital. The future possessor can define on field level, which data he is interested. Although the data is shared, it is still volatile (🔥) and can be physically removed by the data owner at any time. As this is pretransactional, there is no reason and way for the owner to keep the information.
- transactional data appropriation - whenever the possessor and owner are with mutual consent entering into any transaction, the possessor will typically have to document the transaction in his data-pool and therefore this data becomes appropriated. This means only the specific data required for this transaction (not all shared data) now becomes shared ownership (minimal data principle). These transactions do need to become documented for legal reasons and have a period of time, when this data will be deleted entirely again. At this moment appropriation is reversed and all information is removed and inaccessible to the possessor of information.
Example: Data retention and deletion in healthcare with KORDEUS
With thiese new conceptual options, generally all regional data protection laws come with the same requirements on data retention and deletion (see table below):
| Owner | Patient | Medical Service Provider | ||||||
|---|---|---|---|---|---|---|---|---|
| Possesor | Patients | Medical Service Provider | Patients | Medical Service Provider | Medical Service Provider | Non-medical service provider | ||
| treating | non-treating | treating | non-treating | |||||
| Data Category | (Medical) Patient-Data | (Regular Patient-Data) | Service Delivery Information | |||||
| Policy by
EU DS-GVO |
Owner
(Never automatically, Self-Service anytime) |
10 years | purpose-limited | Owner
(Never automatically, Self-Service anytime) |
purpose-limited | 6 years | 6 years | |
| HIPAA / US Cloud Act | ||||||||
| CH nDSG | ||||||||