secure computing architecture for medical software system application

Mammoth, Inc. Project Proposal

Prototype System Architecture

In the Prototype system, Doctors’ hand held terminals will be simulated by laptop computers running a web browser and using 802.11b wireless access.

Connection from a doctor’s device to the applications server will be via the Internet. However, we will consider the Internet a hostile communications medium and our architecture protects against exposure from the public Internet by using IPSEC.

The diagram from the Policy section is repeated below as Figure 1 for reference.

Figure 1. Relationships between entities in system.

Only two Medical Groups, each with at least two doctors and 3 patients will be included in the Prototype. No Hospital or Independent Laboratory will be modeled in the Prototype.

All data will be pre-loaded into the Prototype database. The Prototype will include no on-line input of data. The intent of the prototype is to demonstrate that sensitive patient data is only allowed to be accessed by authorized doctors over secure connections.

Doctor

Hospital

Independent Laboratory

Outsources Tests to

Patient

Outpatient at

Inpatient at

Primary Care Provider of

Specialist Care Provider of

Is Tested by

Medical Group

Member of

Practices at

Patient of

Outsources Tests to

Referred to



Figure 2 below shows the logical architecture of the prototype.

Figure 2. Prototype Logical Architecture

Since the equipment in the logical prototype will likely is not available, the prototype physical architecture is shown in Figure 3 below.

Laptops will be used to simulate each of two doctors from two Medical Groups. One host will serve web pages for both Medical Groups.



Figure 3. Prototype Physical Architecture

Data will be stored on disk on the Linux host. Doctors will authenticate themselves using userid and password. Data will only be provided to Doctors who are authorized to access it, based on their login. SSL or other encryption will protect all data transfers from being observed while it traverses the Internet or the wireless Access Point.

Furthermore sensitive patient data will only be transmitted using PGP encryption using the public key of the Doctor who is logged in. Thus, even if an authorized Doctor’s userid and password are compromised, the data will be useless unless the perpetrator alsh has the Doctor’s private key and pass phrase. Appropriate PGP keys will be installed on devices for each doctor. If an unauthorized user acquires the laptop the thief will still need the doctor’s userid, password and pass-phrase.

Exhibit A

Privacy Policy

In the case of medical information, the issue is potential violation of the Doctor-Patient confidence, which is a privilege protected by law. The violation of this privilege can result in loss of a doctor’s or group of doctor’s right to practice medicine as well as damage suits from patients, and possible criminal charges.

Therefore, we make the following assumptions:

• Doctors, Hospitals, Labs and their professional and support personnel are aware of the risks of violating patient privacy. The requirement on Medsoft/Mammoth is to ensure that automated systems developed and marketed by the Medsoft/Mammoth team do not compromise Doctor-Patient Privilege.

• Individual client organizations (Doctors’ Offices) may exercise their own Privacy Policy. Individual users, who are certified by the procedures and mechanisms described in the Concept of Operations and elsewhere in this document, are at liberty to reveal or protect information obtained from automated systems just as they are with existing paper and automated records.

Description of Subjects and Objects

In order to define a Privacy Policy, we first defined Subjects, Objects and Relationships, which were then used to create rules defining cases where it is acceptable for information relating to a specific patient to be revealed to a particular Medical Group/Doctor.

The diagram below is an initial model of the entities involved in transactions involving Medsoft. The principal actors (subjects) are the Doctor and the Patient. The objects to be protected are medical records relating to individual patients. Other entities in the model are Medical Groups, Hospitals and Independent Laboratories. Sensitive patient information is maintained by each of these entities, with all rights to such information being authorized by the Patient and protected by Doctor-Patient Privilege.

A-1

Mammoth, Inc. Proprietary Information

Exhibit A

Privacy Policy

Each Patient has at least (and most often only) one Primary Care Physician. Normally insurance companies require that there be a single Primary Care Physician, although the Patient has the right to create this relationship with more than one Doctor. This model accommodates such a situation, however, in this case the Privacy Policy permits Patient information to be shared only by written consent of the Patient.

Within this model, all doctors are considered to belong to one and only one Medical Group. Doctors who provide service independently from such a group are considered to belong to a group of one, that particular Doctor’s practice.

Other Medical Groups/Doctors may provide specialist care to the patient after a referral from the patient’s Doctor. While a Patient has the right to consul a specialist independently (without being referred by a Primary Care Physician), this case is modeled identically to the case where a Patient independently consults more than one Medical Group/Doctor.

A-2


Doctor

Hospital


Outsources Tests to

Patient

Outpatient at

Inpatient at

Primary Care Provider of

Specialist Care Provider of

Is Tested by

Medical Group

Member of

Practices at

Patient of

Outsources Tests to

Referred to

Exhibit A

Privacy Policy

Hospitals provide inpatient and outpatient care to Patients. The inpatient or outpatient relationship between Patient and Hospital is established by the Doctor’s act of admitting the Patient to the Hospital (as an inpatient), or referring the Patient to the Hospital for outpatient services. The authority to admit Patients to a Hospital is based on the fact that one or more Doctors in a Medical Group Practices at a particular Hospital.

Similarly, a Doctor who is a Member of a Medical Group may (through the Medical Group) Outsource Tests to an Independent Laboratory. The term Independent Laboratory is a generic term for all such organizations that do blood work, x-rays, etc. Such organizations may also provide interpretative services (such as a radiologist’s reading of an X-ray or Cat Scan).

Patient Information Access Policy

PatientInformation Stored by

PatientInformation Provided to

Access to Patient Information Permitted Only If

Medical Group Doctor Doctor is currently a Member of Medical Group

AND

Patient is currently a Patient of Medical Group

Hospital Medical Group Patient was admitted as an Inpatient at Hospital by a Doctor who is a Member of the requesting Medical Group which Practices at the Hospital

OR

Patient was referred as an Outpatient at Hospital by a Doctor who is a Member of a Medical Group which Practices at the Hospital

OR

Patient authorizes information release by Hospital to Medical Group (in writing).

A-3


Exhibit A

Privacy Policy

Patient Information Access Policy

PatientInformation Stored by

PatientInformation Provided to

Access to Patient Information Permitted Only If


Medical Group Note: parentheses below denote grouping of logical operations

(The requesting Medical Group Outsources Tests to Independent Laboratory for Patient.

AND

The specific test(s) for the specific Patient for which results are being requested was/were outsourced to the Independent Laboratory by a Doctor who is a Member of the requesting Medical Group)

OR

Patient authorizes information release by Independent Laboratory to Medical Group (in writing).

Medical Group Other Medical Group

Patient was Referred to the other Medical Group by a Doctor who is a Member of the requesting Medical Group

OR

Patient authorizes the other Medical Group to release information to the requesting Medical Group (in writing).

A-4


Exhibit B

Security Policy

All access to and modification to information secured under this Security Policy will:

• Be limited to authorized individuals and procedures protected under the Security Mechanisms, which implement the Privacy Policy defined in Exhibit A, above and this Security Policy.

• Be in accordance with the Clark-Wilson Integrity Model, which is restated (from the referenced document) for clarity in Tables 1, 2 and 3 below.

The Draft System Architecture document, above, explains how trusted Transformation Procedures (TPs) are developed using Mammoth’s development procedures and executed in a secure environment, using the Mammoth Secure Server Card (SSC). More details will be provided in the next draft of this White Paper.

Table 1Clark-Wilson Integrity Model

Definitions

Acronym Expansion MeaningCDI Constrained

Data ItemA set of data items that have been validated (by a TP) and are in accordance with specifications.

IVP Integrity Verification Procedure

An integrity verification procedure is used to demonstrate that CDIs are valid and are in accordance with specifications. IVPs can be computer code or they can be manual procedures. Audit work programs are classic examples of IVPs, as are input validation programs.

TP Transformation Procedure

A transformation procedure transforms a set of valid data items (CDI) into another valid set. It may also transform non-validated data items (UDI) into valid data (CDI). This means that a transformation procedure must itself have the properties of a CDI.

UDI Unconstrained Data Item

A UDI is a set of data items that have not been validated or proved to comply with specifications.

B-1


http://www.chi-publishing.com/isb/backissues/ISB_2001/ISB0601/ISB0601KL.pdf

Exhibit B

Security Policy

Table 2Clark-Wilson Integrity ModelThe Five Certification Rules

Rule Number RuleC1 All IVP’s must properly ensure that all CDI’s are in a valid state at

the time the IVP is run.

C2 All TP’s must be certified to be valid. That is, they must take a CDI to a valid final state, given that it is in a valid state to begin with. For each TP, and each set of CDI’s that it may manipulate, the Security Officer must specify a “relation”, defines that execution. A relation is thus of the form: (TPi, (CDIa, CDIb, CDIc...)), where the list of CDI’s defines a particular set of arguments for which the TP has been certified.

C3 The list of relations in E2 must be certified to meet the separation of duty requirement.

C4 All TP’s must be certified to write to an append-only CDI (the log) all information necessary to permit the nature of the operation to be reconstructed.

C5 Any TP that takes a UDI as an input value must be certified to perform only valid transformation, or else no transformations, for any possible value of the UDI. The transformation should take the input from a UDI to a CDI, or the UDI commercial is rejected.

B-2


Exhibit B

Security Policy

Table 3Clark-Wilson Integrity ModelThe Four Enforcement Rules

Rule Number RuleE1 The system must maintain the list of relations specified in rule C2,

and must ensure that the only manipulation of any CDI is by a TP, where the TP is operating on the CDI as specified in some relation.

E2 The system must maintain a list of relationships of the form: (UserID, TPi, (CDIa, CDIb, CDIc.)), which relates to a user, a TP, and the data objects that TP may reference on behalf of that user. It must ensure that only executions described in one of the relations are performed.

E3 The system must authenticate the identity of each user attempting to execute a TP.

E4 Only the agent permitted to certify entities may change the list of such entities associated with other entities: specifically, the list of TP’s associated with a CDI and the list of users associated with a TP. An agent that can certify an entity may not have any execute rights with respect to that entity.

B-3


secure computing architecture for medical software system application

Engineering