One of several documents describing an earlier version of the Secure Computing InFrastructure (SCIF) architecture and embodiment for a medical applicaton

1. 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.
Medical Group
Referred to
Member of
Doctor
Hospital
Practices at
Outsources Tests to
Outsources Tests to
Independent Laboratory
Is Tested by
Patient
Outpatient at
Inpatient at
Patient of
Primary Care Provider of
Specialist Care Provider of
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.

2. Mammoth, Inc. Project Proposal
Prototype System Architecture
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.

3. Mammoth, Inc. Project Proposal
Prototype System Architecture
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.

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

5. Exhibit A
Privacy Policy
Practices at
Outsources Tests to
Outsources Tests to
Is Tested by
Medical Group
Referred to
Member of
Patient of
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
Mammoth, Inc. Proprietary Information
Doctor
Hospital
Independent Laboratory
Patient
Outpatient at
Inpatient at
Primary Care Provider of
Specialist Care Provider of

6. 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
Patient
Information Stored by
Patient
Information
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
Mammoth, Inc. Proprietary Information

7. Exhibit A
Privacy Policy
Patient Information Access Policy
Patient
Information Stored by
Patient
Information
Provided to
Access to Patient Information
Permitted Only If
Independent
Laboratory
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
Mammoth, Inc. Proprietary Information

8. 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 1
Clark-Wilson Integrity Model
Definitions
Acronym Expansion Meaning
CDI Constrained
Data Item
A 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
Mammoth, Inc. Proprietary Information

9. Exhibit B
Security Policy
Table 2
Clark-Wilson Integrity Model
The Five Certification Rules
Rule Number Rule
C1 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
Mammoth, Inc. Proprietary Information

10. Exhibit B
Security Policy
Table 3
Clark-Wilson Integrity Model
The Four Enforcement Rules
Rule Number Rule
E1 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
Mammoth, Inc. Proprietary Information