Security models for medical information

1. Security models for medical information Eduardo B. Fernandez and Tami Sorgente

2. 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

3. 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

4. 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

5. 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

6. * MemberOf Group * * AuthorizationRule User * * * MemberOf * MedicalRole MedicalRecord 1 * Patient Employee Right Activated From Subset WorksOn * Session AdminRole AdminRight * A Pattern for RBAC in Medical Application

7. 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

8. MedicalRelation <<role>> Doctor 1 InChargeOf Custodian * * MedicalRecord * 1..* 1 read modify <<role>> Patient Right informPatient read authorizeUse for own Record Medical Record Authorization Model

9. 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 semi-formal intuitive approach, that can be made more formal using OCL

10. 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

11. 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.

12. 2. Patient Record insurance treatment history MedicalHistory 1 * medications procedures TreatmentHistory name address patient number Patient Outpatient Inpatient specialty Figure 1 Class Diagram for Patient Record

13. 2. Patient Record begin stay Created UnderDiagnosis start treatment do:updateTreatmentlHistory() UnderTreatment discontinue treatment or death do:updateTreatmentHistory() do:updateMedications() suspend treatment Discharged return to treatment do: closeTreatmentHistory ( ) Suspend complete treatment create Figure 2 State chart for: Treatment(Stay) History

14. 3. Consortium Assets * Employee name ss number address Hospital name address works at 1…* * * Building name location Doctor Nurse specialty specialty * number size Room Consortium name main location Figure 3 Class Diagram for Consortium Assets

15. 4. Asset Assignment Patient name address patient number * assigned to primary 1 Doctor Nurse specialty specialty * Room number size assigned to Outpatient Inpatient specialty * 1 1...2 assigned to * assigned to consulting * Figure 4 Class Diagram for Asset Assignment

16. 5. Patient Treatment name address patient number Patient Consortium name main location assigned to primary Employee name ss number address * * works at * name address Hospital 1…* Outpatient Inpatient * specialty Doctor Nurse 1...2 * 1 * specialty specialty name location Building .* * MedicalHistory insurance treatment history 1 assigned to consulting * Room number size assigned to * TreatmentHistory medications procedures 1 assigned to Patient Record Consortium Assets Asset Assignment Figure 5 Class Diagram for Patient Treatment

17. Patient Treatment with HIPAA Security standards • General requirements of Health Insurance Portability and Accountability Act (HIPAA) security standards: • Ensure the confidentiality, integrity and availability of all electronic protected health information the hospital creates, receives, maintains or transmits. • Protect against any reasonably anticipated threats or hazards to the security or integrity of such information. • Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under the privacy regulations. • Ensure compliance of this subpart by the hospital workforce.

18. 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 admissions clerk admit an inpatient admit an outpatient patient nurse treat a patient doctor discharge a patient <<include>> administrative clerk close a patient Figure 6 Use Case diagram for roles in Patient Treatment

19. Patient Treatment with Authorization Right governmentAudit Right hospitalAudit Right Right closePatient billPatient treatPatient Right Right admitPatient treatPatient dischargePatient <<role>> Doctor <<role>. AdministrativeClerk <<role>> Nurse <<role>. AdmissionsClerk <<role>> HospitalAuditor specialty specialty TreatmentHistory medications procedures MedicalHistory insurance treatmentHistory 1 Consortium name main location * Patient name patient number update * Hospital name address create update <<role>> GovernmentAuditor * Employee name ss number address Figure 7 Patient Treatment with RBAC

20. Patient TreatmentAdmit a Patient with Authorization <<role>. AdmissionsClerk 1 Right admit_patient Admit a Patient New Patient Patient Number: Open Patient Patient Information: Create Treatment History Medical History Inpatient Outpatient Observer Model AdmitPatientController - newPatient - openPatient - patientNumber - patientInformation - treatmentHistory - medicalHistory - inpatient - outpatient AdmitPatientView • - name • - address • patient number Patient + handleEvent( ) + create(patient info) + update(patient info) + close( ) + update( ) +admit_patient() * Outpatient Inpatient - specialty • - insurance • treatmentHistory MedicalHistory • - medications • procedures TreatmentHistory * 1 + open ( ) + create( ) + update ( ) + close ( ) + create ( ) + update ( ) + close ( )

21. 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

22. 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

23. 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)