HCG Customer Specification Bob Walton Wed Apr 26 07:36:20 EDT 2000 FIRST DRAFT 1. Introduction HCG, the Hospital Computing Grid, is an operating system with a unique storage system that emphasizes both pri- vacy and availability. Among other things, HCG stores patient records in a way that encrypts them with a patient-specific key and keeps track of where every copy is, so copies can be erased or re-encrypted. HCG uses encryption and tight security to provide privacy when there is no emergency or other need to make patient information widely available, and uses assiduous audit trails and post-usage cleanup to make privacy as strong as possible when there is need to make information widely available, such as during a patient emergency. This document specifies requirements that HCG must meet from the customer point of view. 2. Terminology HCG has three kinds of computing elements: storage units (SUs), computation units (CUs), and terminal units (TUs). Storage units hold information longterm. Compu- tation units are never supposed to hold information longer than necessary to perform a computation. Ter- minal units are not supposed to store information, and are only supposed to be given information that will actually be displayed to a person. HCG stores `information records', or IRs. IRs are like files but may be smaller. For patients, each IR might store the results of a single laboratory test or a single doctors comment. An IR has one or more `owners', who are people or groups of people. The owners of an IR have a vested interest in maintaining the privacy of the IR. There is a group called `public' that owns IRs that are available to the public. There are several types of IRs. A `patient information record', or PIR, stores an item of medical information about a person. A `summary information record', or SIR, stores information about many patients in summary form. It may be appropriate for a SIR to be owned by the `public' even though it was computed from PIRs owned by individuals. An `audit information record', or AIR, records an action involving another information record, called the `sub- ject' of the AIR. Typical audited actions are viewing at a TU or copying to another SU. In order to permit IRs to reference other IRs, each IR shall be assigned a unique ID number, or IRID. This can be a 128 bit random number, which is probabilistically unique. People are identified to the system by pieces of hard- ware called `identification units', or IDUs. An IDU is a badge whose physical proximity can be sensed auto- matically by a TU. Computational units run computer programs called `execu- table programs', or XPs. XPs have to be certified if their output is not owned by all the owners of all their inputs. Two kinds of facility are envisioned. A medical facil- ity, or MF, is responsible for giving care to patients. A research facility, or RF, is responsible for doing medical research in which large numbers of patient rec- ords are analyzed to determine the performance of drugs, hospitals, doctors, etc. 3. Efficacy of Identification Units A TU (terminal unit) shall be able to sense the proxim- ity of an IDU (Identification Unit). Upon entering a MF (medical facility) for non-emergency care, a patient will be issued an IDU. The proximity of the patient IDU shall be sufficient to operate a TU that is displaying IRs (information records) owned by the patient. In addition, certain authorized people (doctors, etc.) shall automatically be granted access to IRs with cer- tain owners by various programmable automatic rules. For example, access to IRs owned by a patient will be granted to doctors who are to review the patient's medical record, including specialists analyzing medical tests done on the patient. Upon entering a MF for emergency care, a doctor or other appropriately authorized person may authorize access to IRs owned by the patient by many appropriately author- ized people (doctors, nurses, technicians) from many appropriately authorized locations. Before information is presented on a TU, a check shall be made that appropriately authorized people (doctors, nurses, technicians) are in proximity to the TU. Whenever information derived from an IR is presented on a TU, an AIR (audit information record) shall be gener- ated to record this presentation. This AIR shall include the IR presented (which is the subject of the AIR), the part of the IR presented, and the IDUs in proximity to the TU. This AIR shall be owned by the owners of the subject IR. The AIRs generated above shall be usable by a billing system to determine or verify in part the time alloca- tion of a doctor, nurse, technician, etc. There shall be backup systems to cover the malfunction of hardware or excessive limitations of normal security. For example, malfunction of an IDU might be overcome by permitting a second existing IDU to function as having the privileges of the malfunctioning IDU, or by issuing a temporary IDU. All such backup actions shall cause appropriate security personal to be notified so that they can check up in person on the action, either before or after the fact, as appropriate. 4. Action of Executable Programs Execution of an XP (executable program) takes IRs (information records) as inputs and produces IRs as out- puts. If the XP has no special certification, then the owners of its outputs shall include the union of all the owners of its inputs. If the XP has special certification, the owners of its outputs may exclude some of the owners of its inputs. For example, an XP might search all patients in an MF (medical facility) to find patients that might be donors for a particular rare type of blood. The output would be a list of these patients. The output should be owned only by the patients listed in the output, but without certification of the XP, the output would have to be owned by all the patients in the MF, since all these were examined as inputs. 5. Location of Information Records IRs (information records) are stored permanently only in SUs (storage units). CUs (computation units) and TUs (terminal units) shall promptly erase IRs they no longer need. It shall be possible to rapidly retrieve a copy of EVERY PIR (patient IR) owned by a particular person. The location of EVERY copy of EVERY IR owned by a parti- cular person shall be rapidly retrievable. It shall be possible to erase ANY of these copies. It shall be possible to change the encryption key on ANY of these copies. Note this prohibits off line backup of IRs. Creation, copying, erasure, and re-encryption of IRs owned by a patient shall be recorded in AIRs (audit Information records). These AIRs will not be owned by the owners of their subjects, however. 6. Indefinite Storage of Information PIRs (patient information records) and AIRs (audit information records) shall never be modified and shall never be completely erased from the system, though re- dundant copies may be erased. It shall be possible, however, to create new PIRs that act as comments on or corrections to previous PIRs, and similarly to create new AIRs that act as comments on or corrections to existing AIRs. Since formatting conventions change with time, IRs may be reformatted from time to time. It shall be possible to treat reformatting the same as re-encrypting, by tracking down and reformatting all copies of an IR.