1 / 36

Security models for medical and genetic information

Security models for medical and genetic information. Eduardo B. Fernandez, Mar í a M. Larrondo Petrie, Tami Sorgente, Alvaro Escobar, and Andrei Bretan. Medical information. Patient information is very sensitive; its misuse could seriously affect the life of the patient

sorley
Download Presentation

Security models for medical and genetic information

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security models for medical and genetic information Eduardo B. Fernandez, María M. Larrondo Petrie, Tami Sorgente, Alvaro Escobar, and Andrei Bretan

  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 • We need new access control models

  4. General policies for the model • Need-to-know, provide only information needed to perform their job • Users are defined by their roles but individual access is also needed • Emphasis on privacy • Closed system

  5. Specific policies • Specific access constraints for each role • Patients consent to use of their records and and are notified of their use • A record custodian is responsible for use of record • Records must be accessible for specific time periods • Need to override rights in exceptional situations

  6. Specific Policies II • Records of patients with genetic or infectious diseases need to be linked to other medical records e.g. relatives • Each patient has one or more medical records seen as one Logical Record • Need for aggregate types of access which do not reveal the individuals’ medical data

  7. Requirements for model • Administration of security—Custodians and traditional administrators • Attribute and credential-based authorization—Users unknown in advance • Exceptional access modes—need to override predefined authorization • Delegation of rights—Provisions for delegation

  8. More requirements • Temporal restrictions—Time-dependent access • Use of XML—Need to control access to XML documents • Multimedia objects—Units of access can be text, images, audio • Inference—Control of basic inferencial associations

  9. Even more requirements • Expression encryption needs—When Transferring documents • Coordinated authentication and authorization • Coordination of architectural levels • Consideration of web standards • Compliance with health records laws

  10. Medical information • Medical information is collected from the moment a person is born until her death • Presently there is not one medical record for each individual kept in a central registry • Each clinician or consortium keeps their own records • Information is passed through referrals and discharge letters

  11. Privacy of Patients • Since 400 B.C., and the Hippocratic oath, patient privacy has been an important part of physician’s code of conduct • Now, many insurers, attorneys and government agencies employ individuals not subject to medical ethics codes

  12. Medical information Protection • The use of medical information of each individual is complex and fragmented • Several countries have provided guidelines for medical information protection

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

  14. HIPAA in the United States • Healthcare providers must ensure the integrity, confidentiality, and availability of electronic protected health information (PHI) is protected • PHI is broad and includes any identifiable health or mental information related to an individual

  15. Bioinformatics • Application of computer technology to the management of biological information. • Science of developing computer databases and algorithms to facilitate and expedite biological research. • Genomics is a perfect example. • Biological information must be protected from misuse.

  16. Bioinformatics & Security Approaches • Use alias to replace the individual’s true identity. • Use passwords and encryption for access to or transfer of files, using a secure shell protocol. • Chemical encoding into the genetic material. • Digital Certificate and Public Key Infrastructure for individual user’s identification.

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

  18. Some XML Security Standards • Signed Document Markup Language (SDML) • Key Management Specification (XKMS) • Security Assertion Markup Language (SAML) • Extensible Access Control Markup Language (XACML)

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

  20. An Analysis Pattern for Patient Treatment • 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.

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

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

  23. Patient Treatment with Authorization 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

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

  25. Outline of Proposed Research • The main objective of this project is to develop security models for specialized applications requiring a high level of security with an emphasis on privacy • Specifically, we propose to develop an authorization model for medical and genetic information

  26. Research Approach • Analyze interactions of systems and users with a patient record system • Interview healthcare professionals • Define threats and incorporate countermeasures • Develop patterns to define the complete model and subsets of the model

  27. Research Approach (cont.) • Develop a protection profile that could help to develop secure access systems • Validate the model by testing in real health environment • Develop a secure methodology to build and configure system used for this type of application

  28. Extensions of the Model • Financial systems require investor consent before disclosing his investments • Eduacation, law enforcement, and banking have several similar requirements • Pharmaceutical companies in search of experimental drug testing subjects inviting a patient to participate without accessing their identity until the patient accepts

  29. Evaluation Plan • 8 measures of success for evaluation of the model • Common Criteria Protection Profile for systems that access, store, or interact with medical data Sources for Common Criteria: [NIST, 2003] “Common Criteria for IT Security Evaluation: Common Language to Express Common Needs”, Computer Security Resource Center (CSRC), National Institute of Standards and Technology, created 12 November 2002, last updated 19 May 2003, http://csrc.nist.gov/cc/ “Common Criteria for Information Technology Security Evaluation, User Guide, CESG, UK and NIST, USA, Syntegra, October 2999. [Towns and Britton, 1999] Towns, M. and K. BrittonProterction Profile Development Workshop: Student Handbook, Ver. 2.0, NIAP/NIST, 2000. [Grainger 2000] Granger, G. Common Criteria Tools, Mitretek Systems, May 25, 2000.

  30. Developers Product Vendors Accreditors Common Criteria Certifiers Approvers Consumers Evaluators Common Criteria: What is it? • Common Criteria (CC) – catalog of criteria and a framework for organizing a subset of the criteria into security specification • Who uses it:

  31. Orange Book (TCSEC) 1985 Canadian Criteria CTCPEC) 1993 Federal Criteria (FC) Draft 1993 UK Confidence Levels 1989 Common Criteria V 1.0 1996 V 2.0 1998 V 2.1 1999 ITSEC 1991 German Criteria French Criteria ISO International Standard 15408 1999 Common Criteria • International Standard

  32. Common Criteria Protection Profile • Common Criteria Protection Profile (CC PP) – an implementation independent statement of security requirements that is shown to address threats that exist in a specified environment • A PP is appropiate when • Consumer group wishes to specify security requirements for an application type (e.g., electronic funds transfer) • Government wishes to specify security requirements for a class of security products (e.g., firewalls) • An organization wishes to purchase an IT system to address its security requirements (e.g., patient records for a hospital)

  33. PP Introduction PP Identification PP Overview Target of Evalustion (TOE) TOE Security Environment Assumptions Threats Organizational security policies Security Objectives Security objectives for the TOE Security objectives for the environment IT Security Requirements TOE Security Requirements Security functional req. Security assurance req. Sec. reqs. for IT environment PP Application Notes Rationales Security objectives rationale Security requirements rational Contents of a Protection Profile

  34. Registered Protection Profiles • Sets of registered Protection Profiles exist at the following locations: • http://www.radium.ncsc.mil/tpep/protection_profiles/index.html • http://www.cesg.gov.uk/cchtml/ippr/list_by_type.html • http://csrc.nist.gov/cc/pp/pplist.htm – (currently being updated so I could not look up the list to see if it including what we are trying to propose) • http://www.scssi.gouv.fr/present/si/ccsti/pp.html

More Related