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



MedicalRole
MedicalRecord

MemberOf
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
ltltrolegtgt Doctor
1
InChargeOf
Custodian


MedicalRecord

1..
1
read modify
ltltrolegtgt 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
  patients stay.
• Inpatients are assigned a room, nurse team and
  consulting doctors.

12
2. Patient Record
name address patient number
Patient

Outpatient

Inpatient
specialty
Figure 1 Class Diagram for Patient Record
13
2. Patient Record
create
Figure 2 State chart for Treatment(Stay) History
14
3. Consortium Assets

Consortium
name main location
Figure 3 Class Diagram for Consortium Assets
15
4. Asset Assignment
Figure 4 Class Diagram for Asset Assignment
16
5. Patient Treatment
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
ltltextendgtgt
admit a patient
admissions clerk
admit an inpatient
admit an outpatient
patient
nurse
treat a patient
doctor
discharge a patient
ltltincludegtgt
administrative clerk
close a patient
Figure 6 Use Case diagram for roles in Patient
Treatment
19
Patient Treatment with Authorization
TreatmentHistory medications procedures
name main location
MedicalHistory insurance treatmentHistory
1
Consortium

Patient
name patient number
update

Hospital
name address
create update
ltltrolegtgt GovernmentAuditor

name ss number address
Employee
Figure 7 Patient Treatment with RBAC
20
Patient TreatmentAdmit a Patient with
Authorization
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()


Inpatient

Outpatient
- 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)