dido:public:s_cli:05_contents:02_prt:medical:03_theory:theory
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:s_cli:05_contents:02_prt:medical:03_theory:theory [2021/08/17 13:58] murphy |
dido:public:s_cli:05_contents:02_prt:medical:03_theory:theory [2022/05/20 15:00] (current) nick |
||
|---|---|---|---|
| Line 30: | Line 30: | ||
| <li>The controller has the right to check your identity before providing you with the data </li></ul></html>| | <li>The controller has the right to check your identity before providing you with the data </li></ul></html>| | ||
| ^ Right to data portability/to transfer your data from one data controller to another | <html><ul> | ^ Right to data portability/to transfer your data from one data controller to another | <html><ul> | ||
| - | <li>When you have consented to provide your health data, and that it is in a machine readable format (e.g. in electronic form), you can request to receive a copy in order to transfer it to another entity or person, and you can also demand that it is transferred directly for you</li> | + | <li>When you have consented to provide your health data, and that it is in a machine-readable format (e.g. in electronic form), you can request to receive a copy in order to transfer it to another entity or person, and you can also demand that it is transferred directly for you</li> |
| <li>It could be positive and encourage controllers | <li>It could be positive and encourage controllers | ||
| (hospitals, doctors) to ensure that data is in a | (hospitals, doctors) to ensure that data is in a | ||
| - | format that can easily be transferredIt could be positive and encourage controllers | + | a format that can easily be transferred could be positive and encourage controllers |
| (hospitals, doctors) to ensure that data is in a | (hospitals, doctors) to ensure that data is in a | ||
| - | format that can easily be transferred | + | a format that can easily be transferred |
| </li></ul></html> | | </li></ul></html> | | ||
| ^ Right to object to the processing of your data | <html>Under the new regulation you can object to the | ^ Right to object to the processing of your data | <html>Under the new regulation you can object to the | ||
| Line 46: | Line 46: | ||
| data (e.g. in your medical record) and incomplete data | data (e.g. in your medical record) and incomplete data | ||
| completed</html> | | completed</html> | | ||
| - | ^ Right to erasure (so called “right to be forgotten”)| <html> | + | ^ Right to erasure (so-called “right to be forgotten”)| <html> |
| You can have your data erased. This is the so-called | You can have your data erased. This is the so-called | ||
| “right to be forgotten”. This is especially the case if:<ul> | “right to be forgotten”. This is especially the case if:<ul> | ||
| <li>you have withdrawn consent and the data | <li>you have withdrawn consent and the data | ||
| - | controller has no other grounds for processing | + | the controller has no other grounds for the processing |
| your data</li> | your data</li> | ||
| <li>if there is no longer a purpose for processing it, | <li>if there is no longer a purpose for processing it, | ||
| in accordance with the principle of limited | in accordance with the principle of limited | ||
| - | storage and data minimisation.</li> | + | storage and data minimization.</li> |
| <li>if the processing is unlawful in the first place</li></ul> | <li>if the processing is unlawful in the first place</li></ul> | ||
| When the controller has made the information public, | When the controller has made the information public, | ||
| Line 67: | Line 67: | ||
| <caption>Potential DIDO Commands for Medical Records.</caption> | <caption>Potential DIDO Commands for Medical Records.</caption> | ||
| ^ Operation ^ Description ^ | ^ Operation ^ Description ^ | ||
| - | ^ CREATE NEW | <WRAP>This creates a new person in the Medical DIDO. For example, a new patient is added to the Medical DIDO. The CREATE NEW command adds the new patient and returns a patient specific couple of AsymmetricKeys (i.e., publicKey and privateKey). The [[dido:public:ra:xapend:xapend.a_glossary:p:public_key|public key]] is used to uniquely identify the patient within the medical DIDO and can be used to encrypt any information for that particular patient. The privateKey is used to decrypt the information in the Medical DIDO for that specific patient. The privateKey NEEDS TO BE KEPT PRIVATE! The ECHO command is used to place information onto the console log. | + | ^ CREATE NEW | <WRAP>This creates a new person in the Medical DIDO. For example, a new patient is added to the Medical DIDO. The CREATE NEW command adds the new patient and returns a patient-specific couple of AsymmetricKeys (i.e., publicKey and privateKey). The [[dido:public:ra:xapend:xapend.a_glossary:p:public_key|public key]] is used to uniquely identify the patient within the medical DIDO and can be used to encrypt any information for that particular patient. The privateKey is used to decrypt the information in the Medical DIDO for that specific patient. The privateKey NEEDS TO BE KEPT PRIVATE! The ECHO command is used to place information onto the console log. |
| Some of the fields used to describe a patient might be ''name'', ''birthday'', ''gender'', ''marital status'', ''address''. There are other fields that are probably not required such as ''insurance id'', ''group id'', ''medicare number'', etc. All of these fields are probably classified as [[dido:public:ra:xapend:xapend.a_glossary:p:pii]]. | Some of the fields used to describe a patient might be ''name'', ''birthday'', ''gender'', ''marital status'', ''address''. There are other fields that are probably not required such as ''insurance id'', ''group id'', ''medicare number'', etc. All of these fields are probably classified as [[dido:public:ra:xapend:xapend.a_glossary:p:pii]]. | ||
| Line 87: | Line 87: | ||
| </code>| | </code>| | ||
| ^ MANAGE ACCESS | Updates or modify the Access Control List data. <WRAP> | ^ MANAGE ACCESS | Updates or modify the Access Control List data. <WRAP> | ||
| - | The Patient [[dido:public:ra:xapend:xapend.a_glossary:d:data_object|Data Object]] (sometimes referred to as a [[dido:public:ra:xapend:xapend.a_glossary:s:smart_contracts|Smart Contract]]) maintains its own internal [[dido:public:ra:xapend:xapend.a_glossary:a:acl]] that contains users, medical roles and access roles (i.e., READ, WRITE, etc). In this example, we add two doctrs to the list: ''primaryPhysician'', and 'cardioVascularMd''. | + | The Patient [[dido:public:ra:xapend:xapend.a_glossary:d:data_object|Data Object]] (sometimes referred to as a [[dido:public:ra:xapend:xapend.a_glossary:s:smart_contract|Smart Contract]]) maintains its own internal [[dido:public:ra:xapend:xapend.a_glossary:a:acl]] that contains users, medical roles and access roles (i.e., READ, WRITE, etc). In this example, we add two doctrs to the list: ''primaryPhysician'', and 'cardioVascularMd''. |
| We also grant them access roles that are traditional such as ''READ'', ''UPDATE'' but also roles like ''UPLOAD'' and ''SEARCH''. At this point, these roles are just conceptual in nature and need to be refined in the future. All the fields within the Patient Data Object (Smart Contract) are considered private and can only be accessed using ''getters'' and ''setters''. The ''by'' field will be filled in by the infrastructure. | We also grant them access roles that are traditional such as ''READ'', ''UPDATE'' but also roles like ''UPLOAD'' and ''SEARCH''. At this point, these roles are just conceptual in nature and need to be refined in the future. All the fields within the Patient Data Object (Smart Contract) are considered private and can only be accessed using ''getters'' and ''setters''. The ''by'' field will be filled in by the infrastructure. | ||
| Line 214: | Line 214: | ||
| </code>| | </code>| | ||
| </WRAP> | </WRAP> | ||
| - | - A DIDO that allows hat uses an ACL to control what kinds of operations that someone else can perform ( see MANAGE ACCESS). Although the Medical DIDO only allows for a single owner, it allows for many participants. For example, each doctor adds information to the the patients Medical DIDO (see: UPDATE CONTENT). | + | - A DIDO allows the use of an ACL to control what kinds of operations someone else can perform ( see MANAGE ACCESS). Although the Medical DIDO only allows for a single owner, it allows for many participants. For example, each doctor adds information to the patient's Medical DIDO (see: UPDATE CONTENT). |
| - The use of an [[dido:public:ra:1.2_views:3_taxonomic:3_node_tax:full:archival | Archival Node]] for the long term storage of Medical DIDO patients. | - The use of an [[dido:public:ra:1.2_views:3_taxonomic:3_node_tax:full:archival | Archival Node]] for the long term storage of Medical DIDO patients. | ||
| - The idea of a [[dido:public:ra:xapend:xapend.a_glossary:s:sidechain|sidechain]] or specialized stream that will be joined back to the main "chain" | - The idea of a [[dido:public:ra:xapend:xapend.a_glossary:s:sidechain|sidechain]] or specialized stream that will be joined back to the main "chain" | ||
dido/public/s_cli/05_contents/02_prt/medical/03_theory/theory.1629223112.txt.gz · Last modified: 2021/08/17 13:58 by murphy
