====== 3.2 Theoretical Issues ====== [[dido:public:s_cli:05_contents:02_prt:medical:03_theory:start | Return to Theoretical Simplified System using DIDO]] - The concept of medical data ownership. Does the data belong to the patient, the medical provider or both? This is a controversial subject in the USA and every state seems to have different rules(( George Washington University, Health Information and the Law, 20 August 2015, Accessed: 6 May 2021, [[http://www.healthinfolaw.org/comparative-analysis/who-owns-medical-records-50-state-comparison]] ))
{{ :dido:public:s_cli:05_contents:02_prt:screen_shot_2021-05-06_at_9.57.50_am.png?500 |}} Map of Patients rights in the USA
Europe on the other hand has a single unified approach to patient data under the [[dido:public:ra:xapend:xapend.a_glossary:g:dgpr]] (( European Patients Forum, __The new EU Regulation on the protection of personal data: what does it mean for patients?__ Accessed: 6 May 2021, [[https://www.eu-patient.eu/globalassets/policy/data-protection/data-protection-guide-for-patients-organisations.pdf]] )) ^ What RIght? ^ What does it mean for Patients? ^ ^ To access one’s own personal data | | ^ Right to data portability/to transfer your data from one data controller to another | | ^ Right to object to the processing of your data | Under the new regulation you can object to the processing of your data by a controller under these circumstances: | ^ Right to rectification or erasure of data | You can ask for the rectification of inaccurate personal data (e.g. in your medical record) and incomplete data completed | ^ Right to erasure (so-called “right to be forgotten”)| You can have your data erased. This is the so-called “right to be forgotten”. This is especially the case if: When the controller has made the information public, e.g. online, he has to take reasonable step to ensure other controllers also remove links etc. in order to implement your rights. |
Summary of patient rights within the EU.
 - While the patient remains constant, the providers might change. For example, a patient moves and can no longer use the same doctor or the patient changes insurance companies requiring a change in provider of the medical provider. This implies an [[dido:public:ra:xapend:xapend.a_glossary:a:acl]] arrangement where the patient can authorize others to add new content, make updates, mark for deletion.

Note: The contents of a DIDO are [[dido:public:ra:xapend:xapend.a_glossary:i:immutable|immutable]], therefore, traditional ACL permissions such as Write and Delete have no meaning. However, it is possible for older content to be replaced by newer content requiring the new content to point to the previous content. It is also possible to mark content as deleted.

^ Operation ^ Description ^ ^ CREATE NEW | 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]]. The following is a proof of concept for creating a new patient in the Medical DIDO. patientKeys AsymmetricKeys = CREATE NEW { "patient" : { "name": "Lilly McSmythe", "birthdate": "11/25/1931", "gender" : "F", "maritalSatus" : "married" "address": "123 Avocado Way, San Diego, CA, USA, 92101" } }; ECHO patientKeys.publicKey; "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E" | ^ MANAGE ACCESS | Updates or modify the Access Control List data. 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. ^ Privilege Type ^ Description ^ | READ | Granting READ privilege allows the access to all the Read attributes or operations associated with the patient | | UPDATE | Granting UPDATE privilege allows the access to all the writable attributes or operations associated with the patient | | UPLOAD | Granting UPLOAD privilege allows for new content to be added to the patient record (i.e., images, lab results, vitals, etc. | | SEARCH | Granting SEARCH privilege allows for the Read attributes or operations to be searched for particular strings. It only returns a TRUE or FALSE. All [[dido:public:ra:xapend:xapend.a_glossary:p:pii]] can be hidden from the search. | | DELETE | Granting DELETE privilege allows for the content of the patient record to be marked as deleted OR optionally for the content to be burned by destroying the [[dido:public:ra:xapend:xapend.a_glossary:p:private_key|private key]] | For example: primaryPhysician MedicalDoctor { "id" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D55555", "name" : "Dr. Jane Lee Gupta", "phone" : "1-619-555-1212", "email" : "j.l.gupta@medics.com" } MANAGE ADD { patient : { "id" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "by" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D55555" "primaryPhysician" : primaryPhysician.id } } MANAGE REPLACE { patient : { "id" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "by" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "cardioVascularMd" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2DDDDD" } } MANAGE GRANT { patient : { "id" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "by" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "cardioVascularMd" : "READ, UPDATE, UPLOAD" } } MANAGE GRANT { patient : { "id" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "by" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "primaryPhysician" : "SEARCH" } } | ^ MARK AS DELETED | Mark a person as deleted in the Medical DIDO. For Example: DELETE { "patient" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "by" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D55555" } | ^ UPDATE CONTENT | Update a person's information in the Medical DIDO. For example: UPDATE { "patient" : { "id" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E",, "by" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D5555" "maritalStatus" : "Widowed", "maritalStatusChangeDate" : "11/25/2021" } } UPDATE { "patient" : { "id" : userKeys.publicKey, "by" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D5555" "DateOfDeath" : "11/25/2031" } } | ^ UPLOAD ANCILLARY DATA | This allows for Ancillary data to be uploaded to the Patients Medical DIDO. Ancillary data is data that is associated with the patient such as vitals, images, lab result, etc. UPLOAD { "patient" : { "id" : patientKeys.publicKey, "by" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D5555" "ancillaryData" : { "image": { "type": "xray", "view": "posteroanterior", "date": "5/7/2021" }, "image": { "type": "xray", "view": "Decubitus", "date": "5/7/2021" } } } } | ^ ERASE | Removes the [[dido:public:ra:xapend:xapend.a_glossary:p:pii]] information from the patient in the Medical DIDO allowing the patient to be forgotten in compliance with [[dido:public:ra:xapend:xapend.a_glossary:g:dgpr]] ERASE { "patient" : patientKeys.publicKey } |
Potential DIDO Commands for Medical Records.
 - The [[dido:public:ra:xapend:xapend.a_glossary:g:dgpr]], [[dido:public:ra:xapend:xapend.a_glossary:d:dpa]] and the [[dido:public:ra:xapend:xapend.a_glossary:c:ccpa]] prohibit information from being //"kept for no longer than is necessary"//. How long should a medical record be kept by a medical provider? An insurance provider? Within the USA, its state-by-state, see: [[https://www.healthit.gov/sites/default/files/appa7-1.pdf]] ^ State ^ Medical Doctors ^ Hospitals ^ ^ California | California: Indefinitely, if possible. See CMA ON-CALL: The California Medical Association’s Information-On-Demand Service, available at [[http://www.thedocuteam.com/docs/retention_medicalrecords.pdf | HealthIT.gov(accessed August 14, 2008)]]. | Adult patients 7 years following discharge of the patient.
Minor patients 7 years following discharge or 1 year after the patient reaches the age of 18 (i.e., until patient turns 19) whichever is longer. Cal. Code Regs. tit. 22, § 70751(c) (2008). | ^ Connecticut | 7 years from the last date of treatment, or, upon the death of the patient, for 3 years. Conn. Agencies Regs. § 19a-14-42 (2008). | 10 years after the patient has been discharged.
Conn. Agencies Regs. §§ 19-13-D3(d)(6) (2008). |
Example of minimum medical records retention for California and Connecticut.
^ EXPIRE | The Medical Record expires after a certain amount of time, after a certain date, or when an event occursMedical DIDO. For Example: EXPIRE { "patient" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "onDate" : "20210508" } EXPIRE { "patient" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "after" : "128 hours" } EXPIRE { "patient" : "0xDC25EF3F5B8A186998338A2ADA83795FBA2D695E", "when" : "DEATH_OF_PATIENT" } | - 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 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" /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- /* To add a discussion page to this page, comment out the line that says ~~DISCUSSION:off~~ */ ~~DISCUSSION:on|Outstanding Issues~~ ~~DISCUSSION:off~~