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

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

User

Patient Employee

MedicalRoleMedicalRecord* *

Session AdminRole AdminRight

Right

A Pattern for RBAC in Medical Application

* *

*

*

*

*

MemberOf

MemberOfAuthorizationRule

ActivatedFrom

*

*

1

WorksOn

Subset

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

<<role>>Doctor

<<role>>Patient

readauthorizeUse

MedicalRecord

readmodify

CustodianInChargeOf

MedicalRelation

informPatient

* **

1..*1

1

Right

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

formal 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

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.

An Analysis Pattern for Patient Treatment

insurancetreatment historyinsurancetreatment history

MedicalHistory

1

Figure 1 Class Diagram for Patient Record

medicationsproceduresmedicationsprocedures

TreatmentHistory

*

nameaddresspatient number

nameaddresspatient number

Patient

Outpatient

specialty

Inpatient

2. Patient Record

create

do:updateTreatmentHistory()do:updateMedications()

UnderTreatment

start treatment

Suspend

suspend treatment

return to treatment

Figure 2 State chart for: Treatment(Stay) History

do: closeTreatmentHistory ( )

Discharged

complete treatment

discontinue treatment or death

Created

begin stay

do:updateTreatmentlHistory()

UnderDiagnosis

2. Patient Record

Figure 3 Class Diagram for Consortium Assets

3. Consortium Assets

Consortiumnamemain location

nameaddressnameaddress

*Hospital

numbersizenumbersize

namelocationnamelocation

Building*

Room*

1…*namess numberaddress

namess numberaddress

Employee

Nurse

specialty

Doctor

specialty

*works at

Doctor

specialty

* 1assigned to primaryNurse

specialty

*

*assigned to

*

*assigned toconsultingInpatient

nameaddresspatient number

nameaddresspatient number

Patient

Outpatient

specialty

numbersizenumbersize

Room

1assigned to1...2

Figure 4 Class Diagram for Asset Assignment

4. Asset Assignment

Figure 5 Class Diagram for Patient Treatment

*

*

assigned to

1...2

1assigned to

Asset Assignment

5. Patient Treatment

Patient Record

medicationsproceduresmedicationsprocedures

insurancetreatment historyinsurancetreatment history

MedicalHistory1

TreatmentHistory*

Inpatient

nameaddresspatient number

nameaddresspatient number

Patient

Outpatient

specialty

1

*

assigned to primary

.*

*

assigned toconsulting

*

numbersizenumbersize

namelocationnamelocation

nameaddressnameaddress

namemain locationnamemain location

Consortium

Building

namess numberaddress

namess numberaddress

Employee

Nurse

specialty

Hospital

Room*

*

Doctor

specialty

*

1…*

works at

Consortium Assets

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 HIPAA Security standards

admit an outpatientpatient

admissions clerk

doctor

administrativeclerk

admit a newpatient

admit aninpatient

admit apatient

<<extend>>

treat a patient

close a patient

<<include>>

nurse

Figure 6 Use Case diagram for roles in Patient Treatment

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.

discharge apatient

Patient Treatment with Authorization

nameaddressnameaddress

namemain locationnamemain location

namepatient number

Patient

createupdate

TreatmentHistory

medicationsprocedures

TreatmentHistory

medicationsprocedures

update

*

<<role>>Doctor

specialty

<<role>>HospitalAuditor

<<role>.AdministrativeClerk

MedicalHistoryinsurancetreatmentHistory

MedicalHistoryinsurancetreatmentHistory

1

namess numberaddress

namess numberaddress

Employee

Consortium

*Hospital

*

<<role>>Nurse

specialty

<<role>>GovernmentAuditor

Right

governmentAudit

Right

hospitalAuditRight

closePatientbillPatient

Right

treatPatientdischargePatient

Right

treatPatient

Right

admitPatient

<<role>.AdmissionsClerk

Figure 7 Patient Treatment with RBAC

Patient Treatment with Authorization

- medications-procedures- medications-procedures

- newPatient- openPatient- patientNumber- patientInformation- treatmentHistory- medicalHistory- inpatient- outpatient

- newPatient- openPatient- patientNumber- patientInformation- treatmentHistory- medicalHistory- inpatient- outpatient

- insurance-treatmentHistory- insurance-treatmentHistory

MedicalHistory

1TreatmentHistory

*

Inpatient

- name- address-patient number

- name- address-patient number

Patient

Outpatient

- specialty

*

+ create(patient info)+ update(patient info)+ close( )

+ open ( )+ create( )+ update ( )+ close ( )

+ create ( )+ update ( )+ close ( )

Model

Observer

AdmitPatientController

+ handleEvent( )

+ update( )+admit_patient()

Admit a Patient

New Patient

CreateTreatment History

Medical History

Open PatientPatient Number:

Patient Information:

OutpatientInpatient

<<role>.

AdmissionsClerk1

admit_patient

Right

Patient TreatmentAdmit a Patient with Authorization

AdmitPatientView

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)