Transcript Security models for medical information

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)