Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Security models for medical information Eduardo B. Fernandez and Tami Sorgente Medical information • Patient information is very sensitive; its misuse could seriously affect the life of the patient • In the past this information was kept in paper in doctors’ offices and hospitals • Most medical information now is being put online and accessible from the Internet • There is more information available, e.g., genetic information Security problems • There are many benefits by having information online but also new threats • Access to patients’ records is now possible from remote locations, illegal access also! • Access to many patients’ records makes blackmail, spam, and theft identity more lucrative Patient data protection laws • The UK had a law in 1996 • Germany, France, Iceland, and others already have laws • In the US we have now HIPAA, not as effective as the British laws Access control models • There are several models for access control to information • The most common are: multilevel, Access matrix, and Role-Based Access Control • These are general models, independent of the application • However, the model must fit the application or it will not be used Group * MemberOf * * User * MemberOf * * AuthorizationRule MedicalRole * MedicalRecord 1 * Patient Employee Right Activated From Subset WorksOn * * Session AdminRole A Pattern for RBAC in Medical Application AdminRight Policies for medical information • Patients can see their records, consent to their use, must be informed of their use • A doctor or other medical employee is responsible for use of record (custodian) • Records of patients with genetic or infectious diseases must be related • One or more medical records per patient MedicalRelation <<role>> Doctor 1 Custodian InChargeOf * * MedicalRecord * 1..* read modify 1 <<role>> Patient Right read authorizeUse informPatient for own Record Medical Record Authorization Model Level of formalism • Models can be formal, semi-formal, and descriptive • Purely formal models are hard to use, cannot describe well structural properties, and hard to extend • Descriptive models are not precise enough • Object-oriented design and UML are a semiformal intuitive approach, that can be made more formal using OCL New model Proposal to NSF: • E. Fernandez, PI • M. Larrondo-Petrie, Co-PI • Tami Sorgente, Grad student • Others later • Cooperation with College of Nursing • Based on RBAC, represented using UML and OCL An Analysis Pattern for Patient Treatment 1. Requirements • A Patient Treatment Pattern describes the treatment or stay history of a patient in a hospital. • The hospital may be a member of a medical consortium. • Each patient has a medical history which contains insurance information and a record of all treatments within the medical consortium. • Each patient has a primary physician, an employee of the hospital. • Upon admission the patient is created as new or information is updated from previous visit(s). • A treatment history is created for each patient admitted and updated throughout the patient’s stay. • Inpatients are assigned a room, nurse team and consulting doctors. 2. Patient Record Patient MedicalHistory name address patient number 1 insurance treatment history * Outpatient specialty Inpatient TreatmentHistory medications procedures Figure 1 Class Diagram for Patient Record 2. Patient Record create begin stay Created UnderDiagnosis start treatment do:updateTreatmentlHistory() UnderTreatment discontinue treatment or death do:updateTreatmentHistory() do:updateMedications() Discharged do: closeTreatmentHistory ( ) return to treatment complete treatment suspend treatment Suspend Figure 2 State chart for: Treatment(Stay) History 3. Consortium Assets Consortium name main location * Employee name ss number address works at * Hospital 1…* name address * Building name location Doctor Nurse specialty specialty * Room number size Figure 3 Class Diagram for Consortium Assets 4. Asset Assignment Patient name address patient number * assigned to primary 1 Doctor Nurse specialty specialty * * Outpatient Inpatient specialty * assigned to consulting Room assigned to number size * 1...2 assigned to Figure 4 Class Diagram for Asset Assignment 1 5. Patient Treatment Patient Consortium assigned to primary name main location Employee name address * patient number name ss number address * works at * Hospital 1…* Outpatient Inpatient * name address specialty 1...2 * 1 Doctor Nurse specialty specialty .* * Building * name location MedicalHistory 1 insurance treatment history assigned to consulting * Room assigned to number size * TreatmentHistory assigned to medications procedures Patient Record Asset Assignment 1 Consortium Assets Figure 5 Class Diagram for Patient Treatment Patient Treatment with HIPAA Security standards General requirements of Health Insurance Portability and Accountability Act (HIPAA) security standards: 1. Ensure the confidentiality, integrity and availability of all electronic protected health information the hospital creates, receives, maintains or transmits. 2. Protect against any reasonably anticipated threats or hazards to the security or integrity of such information. 3. Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under the privacy regulations. 4. Ensure compliance of this subpart by the hospital workforce. Patient Treatment with Authorization A variation of the Role Based Access Control model will be used to assign rights to the users according to their roles in patient treatment. admit a new patient <<extend>> admit a patient patient admit an inpatient admissions clerk admit an outpatient nurse treat a patient doctor discharge a patient <<include>> close a patient administrative clerk Figure 6 Use Case diagram for roles in Patient Treatment Patient Treatment with Authorization * TreatmentHistory MedicalHistory Consortium 1 insurance treatmentHistory medications procedures name main location Patient update name patient number * Hospital create update <<role>> GovernmentAuditor name address Right governmentAudit * Employee name ss number address Right hospitalAudit Right Right treatPatient closePatient billPatient Right Right admitPatient treatPatient dischargePatient <<role>> HospitalAuditor <<role>. AdministrativeClerk <<role>> Doctor specialty <<role>> Nurse specialty Figure 7 Patient Treatment with RBAC <<role>. AdmissionsClerk Patient Treatment Admit a Patient with Authorization Observer Model <<role>. AdmissionsClerk 1 AdmitPatientView Patient - name - address -patient number Right admit_patient + create(patient info) + update(patient info) + close( ) - newPatient - openPatient - patientNumber - patientInformation - treatmentHistory - medicalHistory - inpatient - outpatient AdmitPatientController + handleEvent( ) + update( ) +admit_patient() * Outpatient Inpatient - specialty New Patient Open Patient MedicalHistory 1 - insurance -treatmentHistory + open ( ) + create( ) + update ( ) + close ( ) * TreatmentHistory - medications -procedures + create ( ) + update ( ) + close ( ) Create Treatment History Admit a Patient Patient Number: Patient Information: Medical History Inpatient Outpatient Applicability • Most security models attempt to protect the assets of an institution • Medical models are centered on the rights of the patient • Other applications have similar objectives: financial systems, student records, banking,… • Model can be extended to those cases Secure software development • Specialize methodology to apply in medical systems • Specialized use cases • Specialized application (analysis) patterns • Enforced through distributed system architecture • Use of web services Future work • • • • • • Complete the proposal Define typical roles and use cases Select policies to be covered Develop specific patterns Extend RBAC to cover policies Test in real system (hospital or medical lab)