Health Level Seven Security Services Framework

Health Level Seven Security Services Framework

Mary Kratz, University of Michigan

Polar Humenn, Blackwatch Technologies

Mark Tucker, Riegenstrief Institute

Michael Nolte, University of Michigan

Steve Wagner, Department of Veterans Affairs

Gregg Seppala, Department of Veterans Affairs

Gunther Shadrow, HL7 Germany

Wayne Wilson, University of Michigan

Sean Auton, University of Michigan

Introduction

Overview

The demand for secure electronic healthcare systems is growing exponentially. The need for secure transactions, driven by public emphasis on patient privacy issues, provided the impetus for the development of ad-hoc security solutions. Increased automation of labor-intensive administrative tasks has revealed the need for further security in order to protect clinical patient information gathered during the delivery of healthcare services as well as the financial transactions generated by the delivery process. At the same time, it has become clear that a balance must be struck between protecting patient confidentiality and the need to access patient information in the delivery of healthcare services.

The advent of the Internet has focused security concerns on individual machines, applications and users, rather than on systems as a whole, as was past practice. As it stands today, healthcare and financial institutions secure information by building private networks. Access is restricted to ‘trusted’ parties, and it is assumed that malicious parties do not have access to the network. The people who administer and use systems represent the greatest security vulnerability. Most real threats are internal, from employees who have access to the information that is being protected. Users, operators, and other employees with access to healthcare information can be bribed or coerced into giving away passwords, opening doors, or otherwise jeopardizing security in a healthcare system. The most common threats are internal, from within a healthcare organization’s intranet. Security requirements are roughly analogous across the intranet,

extranet and the internet, but it has been the widespread public attention given to the internet which has both raised concerns and accelerated the rate of security technology deployment.

Purpose

This paper is intended to familiarize the reader with the current state of electronic systems and security in health care today, and to make recommendations to HL7. The general field of security is very broad. In this paper, we briefly investigate the issues pertaining to security in healthcare by describing an overall security framework, then focus on security at the link level as it applies to HL7 secure transactions. The goal of Security SIG is to address the practical implementation of secure transactions between systems in healthcare environments today. This includes the possibility that someone will "snoop" on the wire, or that messages may be misdirected, or that an impostor will send you a message.

Our expectation with respect to this investigation is that HL7 can and should apply one of several emerging security standards. One outcome of this investigation should be a sense of what problems are solved by the straightforward adoption of existing standards, and what problems are still unresolved. We expect that the outstanding problems are in fact, the very hard ones. Security SIG may try to tackle some of these outstanding problems, if it thinks it can make progress and other groups are not already actively dealing with them.

Scope

The Scope of Security SIG is network and internet security of HL7 transactions at the application level independent of underlying transport. Within this scope Security SIG will identify: user requirements; the services needed to meet those requirements; the mechanisms for providing those services; and specific implementations for those mechanisms. Security SIG will identify related work in other Standards Developing Organizations as well as Publicly Available Specifications (PAS) and will leverage that work to the extent possible. Security SIG will report to HL7 on available options and recommend actions that the organization may take to address those needs.

Objectives of SIG Secure

Provide near term recommendations for security based on the 2.X model for HL7.

Provide longer term recommendations for security for HL7 3.X

Time constraints for getting security mechanisms into 3.0 by December 1996.

Leverage existing standards to maximum extent possible with a priority of International, National (ANSI), and Publicly Available Specifications

Coordinate with other SDO’s to avoid duplication and to promote harmonization

Referenced Documents

Abdelhak M (Ed.), 1996 Health Information: Management of a Strategic Resource. Philadelphia: W.B. Saunders Company.

AHA, 1993. Toward a National Health Information Infrastructure: Report of the Work Group on Computerization of Patient Records to the Secretary of the U.S. Department of Health and Human Services. AHA Work Group on Computerization of Patient Records. Chicago: American Hospital Association, April.

AHCPR, 1991. Report to Congress: The Feasibility of Linking Research-Related Data Bases to Federal and Non- Federal Medical Administrative Data Bases. Agency for Health Care Policy and Research Pub. No. 91-0003. Rockville: MD: AHCPR, PHS, U.S. DHHS, April.

AHIMA, 1994a. Guidelines on Maintenance, Disclosure, and Redisclosure of Health Information. Chicago: American Health Information Management Association.

AHIMA, 1994b. Retention of Health Information. Chicago: American Health Information Management Association, March.

AHIMA, 1996a. Electronic Signatures. Chicago: American Health Information Management Association, March.

AHIMA, 1996b. Disaster Planning for Health Information. Chicago: American Health Information Management Association, April.

AHIMA, 1996c. Information Security – An Overview. Chicago: American Health Information Management Association, June.

ASTM E1384. Standard Guide for Description for Content and Structure of the Computer-Based patient Record. ASTM Committee E-31 on Computerized Systems, Subcommittee E31.19 on Vocabulary for Computer-Based Patient Records Content and Structure. West Conshohocken, PA: ASTM, Jan. 10, 1996.

ASTM E1714. Guide for the Properties of a Universal Healthcare Identifier. Committee E-31 on Computerized Systems, Subcommittee E31.12 on Medical Records. West Conshohocken, PA: ASTM, Aug. 15, 1995.

ASTM 1762. Guide for Electronic Authentication of Health Care Information. Committee E-31 on Computerized Systems, Subcommittee E31.20 on Authentication. West Conshohocken, PA: ASTM, Oct. 10, 1995.

ASTM E1769. Guide for Properties of Electronic Health Records and Record Systems. Committee E-31 on Computerized Systems,

Subcommittee E31.12 on Medical Records. West Conshohocken, PA: ASTM, Dec. 10, 1995.

Amatayakul M, 1996. Privacy protections afforded by computer-based patient record systems. Topics in Health Information Management. Gaithersburg, MD: Aspen Publishers, Inc., 16(4), May.

Ball MJ, Collen MF, 1992 (Eds.). Aspects of the Computer-based Patient Record. New York: Springer-Verlag.

Cheswick WR, Bellovin SM, 1994 Firewalls and Internet Security. Reading, MA: Addison-Wesley

CPRI, 1996a. Action Plan for Implementing a Universal Patient Identifier, Draft Version 1.0. Schaumburg, IL: Computer-based Patient Record Institute, May.

CPRI, 1996b. Computer-based Patient Record Description of Content. Work Group on CPR Description, Schaumburg, IL: Computer-based Patient Record Institute, April.

CPRI, 1996c. Guidelines for Managing Information Security Programs at Organizations Using Computer-based Patient Records. Work Group on Confidentiality, Privacy & Security, Schaumburg, IL: Computer-based Patient Record Institute, January.

CPRI, 1996d. CPR Project Evaluation Criteria, Version 2.1. Work Group on CPR Systems Evaluation, Schaumburg, IL: Computer-based Patient Record Institute, March.

CPRI, 1995a. Description of the Computer-based Patient Record and Computer-based Patient Record System. Work Group on CPR

Description, High Level Description Project Team, Ver. 1.0. Schaumburg, IL: Computer- based Patient Record Institute, April.

CPRI, 1995b. Guidelines for Establishing Information Security Policies at Organizations Using Computer-based Patient Records. Work Group on Confidentiality, Privacy & Security, Schaumburg, IL: Computer-based Patient Record Institute, February.

CPRI, 1995c. Guidelines for Information Security Education Programs at Organizations Using Computer-based Patient Records. Work Group on Confidentiality, Privacy & Security, Schaumburg, IL: Computer-based Patient Record Institute, June.

CPRI, 1994. Position Paper: Access to Patient Data. Schaumburg, IL: Computer-based Patient Record Institute, April.

Dick RS, Steen EB (Eds.), 1991. The Computer-based Patient Record: An Essential Technology for Health Care. Washington, DC: National Academy Press.

Fites PE, Kratz MPJ, 1993. Information Systems Security: A Practitioner's Reference. New York: Van Nostrand Reinhold.

The Object Management Group, "CORBAservices", OMG Publications, 1996, Chapter 15.

ISO 7498-2, "Information Processing systems -Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture", International Standards Organization, 1989.

DOD Standard 5200 28 - STD, "Department of Defense Trusted Computer System Evaluation Criteria", Department of Defense, 1985.

Crisis Emergency Response Team: http://www.cert.org/

R. Anderson, "Clinical Systems Security: Interim Guidelines," BrMJ 1996;312:109-111.

Secure Environment for Information Systems in Medicine: http://www.semper.org/sirene/projects/seismed/

A Model EDI Audit Program, A Set of Guidelines for Evaluating Electronic Data Interchange (EDI) Control Issues, DISA Publications, 1995.

National Research Council, "For the Record: Protecting Electronic Health Information", Computer Science and Telecommunications Board, National Academy Press, Washington, DC, 1997.

W. Stallings, "Network and Internetwork Security Principles and Practice", The Institute of Electrical and Electronic Engineers, Inc.,, New York, 1995. ISBN 0-02-415483-0.

D. Russell and G.T. Gangemi Sr., "Computer Security Basics", O’Reilly & Associates, Inc., CA, 1996. ISBN 0-937175-71-4.

PT 6-012 and CEN/TC 251/WG6, EUROPEAN PRESTANDARD Draft, prENV xxxx, 1996-10-26, UDC, "Medical Informatics: Security Categorization and Protection for Healthcare Information Systems", European Committee for Standardization, Central Secretariat: rue de Stassart 36, B-1050 Brussels, 1997.

Applied Cryptography, 2nd edition by Bruce Schneier, John Wiley and Sons, New York, 1996.

ECMA TR/46 "Security in Open Systems: A Security Framework", European Computer Manufacturers Association, 1988.

ITSEC "Information Technology Security Evaluation Criteria" European Commission, 1991.

DOD Standard 5200.28-STD "Department of Defense Trusted Computer System Evaluation Criteria", US Department of Defense, 1985.

X/Open Snapshot: "Distributed Security Framework: Company Review Draft", X/Open Company Ltd.,U.K. 1994.

Computer Related Risks: Peter G. Neuman, The ACM Press, 1995

Mitre "Taxonomy of Threats and Security Services for Information Systems", Working Paper WP 93B0000323, 1994

Terminology

Glossary

A comprehensive glossary of terms related to the security of health care information is provided as Appendix A to this document.

Acronyms and abbreviations

ANSI American National Standards Institute

ASTM American Society for Testing and Materials

CAP College of American Pathologists

CDC Center for Disease Control

CEN Central European Nations

CERT Computer Emergency Response Team

CORBA Common Object Request Broker

CPRI Computerized Patient Record Institute

CRC Cyclic Redundancy Check

DAC Discretionary Access Control

DES Data Encryption Standard

EDI Electronic Data Interchange

HL7 Health Level Seven Application Protocol for Electronic Data Exchange in Healthcare

HMO Health Maintenance Organization

IETF Internet Engineering Task Force

JCAHCO Joint Commission on Accreditation of Healthcare Organizations

MAC Mandatory Access Control

MPI Master Patient Index

OMG Object Management Group

PCP Primary care physician

PDU Protocol Data Unit

PIN Personal Identification Number

SDO Standards Development Organization

SEISMED Secure Environment for Information Systems in Medicine

TCB Trusted Computing Base

TCSEC Trusted Computer System Evaluation Criteria

Security Framework

Security Reference Model

A unified analytic approach that defines the overall security requirements for a particular architecture is necessary for assessing security support features. A security reference model provides the starting point for defining and analyzing security requirements. Concentrating solely on the architecture's security requirements, the reference model defines the portions of system that should be trusted to enforce security policy, and the environmental dependencies necessary for preservation of that policy.

A security reference model provides guidance in system design and configuration., gives vendors guidelines for conforming to the security requirements of the architecture, and lays the groundwork for security planning.

The usual topics covered in the security reference model include:

Classes of model components (communication mediums, databases, services)

Classes of active system entities (e.g., users, roles, applications, organizations)

Classes of passive system entities (e.g., messages, mailboxes)

Overall security properties preserved by the system (invariants)

Security interactions between the components (i.e. relating to authentication, encryption, access control)

Security properties describing how and why each component is trusted

Environmental assumptions required by each component to preserve security(e.g. locked rooms, camera surveillance, etc.)

Requirements for authentication of model entities (i.e. digital certificates, biometrics, etc.)

Requirements for trusted path (i.e., non-spoofable communication between user and executing program)

Security of communications (e.g. encryption )

Accountability requirements (e.g. audit, non-repudiation)

Threats, vulnerabilities, attacks and countermeasures

The multiple components of the health care delivery system -- hospitals, academic health centers, health care networks, home health agencies, health care group practices, ambulatory care facilities, mental health facilities, dental practices, transcription services, pharmacies, chain drug stores, research facilities, insurance companies, caregivers and operators of health care information systems, networks and government agencies -- are beginning to address the necessity for security throughout the health care domain. If and when a standard architecture for health care information processing is proposed, security requirements for that architecture can be produced in the form of a security policy reference model. Having a standard architecture and its security reference model will give vendors and existing medical system operators a common set of requirements to conform to in creating an open and interoperable system meeting the needs of security within the healthcare community.

Security Exposures

In developing the model, particular attention should be paid to security exposures (threats, vulnerabilities, attacks and appropriate countermeasures). Instances of these can include such problems as [Ref: Mitre Document]:

Disclosure

Exposure

Interception

Inference

Intrusion

Deception

Masquerade

Falsification

Repudiation

Disruption

Incapacitation

Corruption

Obstruction

Usurpation

Misappropriation

Misuse

Specific instances of some of these security failures can be found in the Crisis Emergency Response Team (CERT) repository of alerts. [Ref: http://www.cert.org/].

The National Research Council, Computer Science and Telecommunications Board recommended that Congress should provide initial funding for the establishment of an organization for the health care industry to promote greater sharing of information about security threats, incidents, and solutions throughout the industry. The establishment of this organization might be modeled after the computer emergency response team established at Carnegie Mellon University of Internet security (the CET Coordination Center) and be called Med-CERT.

Security Services

Electronic data security has been a heavily researched field. Government organizations, such as the National Security Agency (NSA), the military, and many computer corporations and academic institutions have spent millions of dollars researching all aspects of security. Over the years, a generalized definition of security and security services has emerged that is centered on critical areas of electronic systems design.

The following is a list of security services that one would expect an overall security framework to encompass:

Identification and Authentication: This service supports the definition of entities (such as a person or system) and the corroboration that an entity is the one claimed.

Authorization and Access Control: This service supports the granting of rights, which includes the granting of access based on access rights and the prevention of unauthorized use of a resource.

Integrity: This service ensures that data or system software have not been undetectably altered or destroyed in an unauthorized manner or by unauthorized users.

Confidentiality: This service ensures that information is not made available or disclosed to unauthorized individuals, entities or processes.

Accountability: This service ensures that the actions of an entity can be traced.

Availability: This service ensures that information is accessible and useable upon demand by an authorized entity.

Non-repudiation: This service supports the provision of evidence which will prevent a participant in an action from convincingly denying his/her responsibility for the action.

Administration: Security policy must be managed.

The basic information system service types required for all forms of electronic commerce exist within the healthcare domain. Healthcare enterprises have the need to communicate within the enterprise as well as externally. In addition, current healthcare applications have many services embedded within the application or operating system levels. However, efforts underway to define an architecture that can be adopted for the healthcare domain are slowed by the fact that there is no consistent definition for a "typical" healthcare enterprise. It is therefore proposed, based on the CommerceNet’s Architectural Framework for Internet Commerce, the Care Data Consortium, and the Andover Group’s Functional Model for an Enterprise Information System Architecture design, that every healthcare enterprise support the following basic services:

Network Services: All information systems in a healthcare enterprise must use network services. Network services are defined as services that enhance the performance, reliability and security of the network to accommodate mission-critical business needs. Examples include QOS management, IP-multicast, delivery receipts, authenticated packets, and smart firewalls (that pass packets from authorized business partners).

Commerce Services: Basic electronic commerce services, such as digital identifiers and electronic cash, that allow individuals and companies to authenticate themselves, make payments, link catalogs, share services. Advanced next generation services include secure multimedia mail, smart card-based security and payment, digital content delivery, application billing and accounting, transaction management, and agent management.

Business Processes and Applications: Generic business services common to multiple markets. These include procurement, invoices, payments, inventory management, supply-chain management, logistics.

Healthcare as a Vertical Market: Services specific to the health care market include clinical practice management, eligibility and enrollment processes, health care claims and remittances. The health care claim transaction is one of the most complex transactions ever defined. This is due to inconsistent definitions throughout the entire domain of healthcare. Each unique circumstance, whether based on employer, payer, or provider requirements, causes a chasm of complexity in the health care domain.

Security in Healthcare Standards Today

At present, most healthcare systems have severe security shortcomings. Impending legislation and market pressures are forcing the redesign of healthcare systems in order to include security features. Standards development organizations (SDOs), such as the American Society for Testing and Materials (ASTM), Health Level Seven (HL7), The Object Management Group (OMG), the Computer-based Patient Records Institute (CPRI), Central European Nations (CEN), and the US Congress are currently addressing security aspects of health care with special projects and sub-committees.

The underlying framework of this effort includes:

an overall security framework (ASTM has developed a draft document)

an access matrix (currently underway, with CPRI and ASTM coordinating)

back-up and data integrity standards (a draft will be discussed at the ASTM E31.20 meeting in Nashville at the end of the month)

secure messaging (X12 has a standard , although it is weak, and non-compliant with the general industry. IETF has a draft standard for MIME-based secure EDI)

The ASTM is an ANSI accredited SDO that creates standards in the US. For health care, the Security Division is currently working on several technical standards specific to health care, such as authentication, the use of digital signatures, access control, as well as general guidelines on confidentiality, privacy, and data security principles within health care.

The HL7 group is an organization that specializes in a messaging standard for exchanging information between applications within a health care organization. It has currently conscripted a working group to address the security of these transactions within the organization.

CPRI is an organization committed to facilitating development and implementation of computer-based patient records. A CPRI working group on Confidentiality, Privacy, and Security is developing a series of security policy guidelines for vendors implementing computer-based patient record systems.

The OMG, the organization that standardizes distributed objects in the CORBA environment, has created two working groups, CORBAsec and CORBAmed. These address standards for security and health care applications, respectively, within OMG's standard architecture. CORBAmed and CORBAsec recently joined hands to address security in health care.

Standards Development Organizations (SDOs) and governmental entities in the United States, Europe, Japan, Singapore, Australia, and New Zealand are currently developing standards to insure the security, confidentiality, and privacy of health care data as it resides in systems or as it is being passed in message transactions between systems. The focus of these groups is to develop security policies and procedures related to threats to system security and also to define security services. Threats to system security include disclosure, deception, disruption, and usurpation. Security services include confidentiality, integrity, availability, authenticity, and digital signatures.

Confusion has often arisen due different methods of addressing security issues within various domains. The health care community has developed domain-specific standards for security services, while technical communities have developed standards that cross-domains and advocate the use of non health care-specific solutions. Accordingly, no single SDO is addressing all aspects of health care information security and confidentiality.

The most comprehensive health care security standards development is currently being carried out by CEN TC251 in Europe and by the ASTM in the United States. Health care organizations that are not accredited SDOs, such as the Computer-based Patient Record Institute (CPRI) and CORBAMed are active in assisting and promoting the standards development process through their participation in ANSI HISB and through the development of policy documents (CPRI) and standards certification (CORBAMed).

What follows is a comprehensive, although not exhaustive, overview of work being done by SDOs and other entities in the United States and Europe to develop health care security standards.

Health Level Seven (HL-7)

Health Level Seven (HL-7) formed the Secure Transactions Special Interest Group (SIGSecure) to address the development of secure HL7 transactions at its August 1996 meeting. This SIG will focus on the use of HL7 in communications environments where there is a need for authentication, encryption, non-repudiation, and digital signature. This group will direct its efforts on insuring the mechanisms are available for implementing a secure HL7 transactions and not on standardizing security policies. The HL7 organization is also interested in participating with the efforts of the Internet Engineering Task Force. A CommerceNet trial using email protocols (S-MIME) to encapsulate HL7 messages is being explored for feasibility.

SIGSecure will identify user requirements, the services needed to meet those requirements, the mechanisms for providing those services, and the specific implementations for those mechanisms. The scope will be limited to providing network and Internet security mechanisms for HL7 transactions at the application level, independent of underlying transport. SIGSecure has a stated goal of leveraging existing standards to the maximum extent possible with a priority given to International, National (ANSI), and Publicly Available Specifications. It addition it will coordinate with other SDOs to avoid duplication and to promote harmonization.

American Standards Committee (ASC)

the American Standards Committee - X12, electronic Data Interchange - has a number of security standards under development, primarily targeted at messaging. Z12’s work in message security takes a non-health care-specific approach and is managed by the data security task group of X12 Subcommittee C, co-chaired by Don Petry. Current X12C efforts include:

X12.42 Cryptographic Service Message (815) (usually referred to as the 815) which has been published, and has a Reference Model in development - used to provide the data format required for cryptographic key management, including automated distribution and exchange of keys, in support of authentication and encryption.

X12.376 Secure Authentication & Acknowledgment (993) (usually referred to as the 993), which is in development - used by the recipient of a transaction set to authenticate and acknowledge the origin, content, or sequence of data received with the originator of the transactions.

EDIFACT

Security for messaging within EDIFACT, through the UN/EDIFACT Security Joint working Group, chaired by Terry Dosdale of the United Kingdom, is being built into Version 4 of the EDIFACT syntax (IS) 9735). The security aspects of ISO 9735 are targeted for finalization by March of 1997, and will be forwarded to ISO for final approval through the ISO Fast Track process.

IEEE

The Institute of electrical and Electronic Engineers (IEEE), MEDIX - Medical Data Interchange, does not currently have an active group in security and confidentiality. This, according to Bob Kennelly of MEDIX, is due to the focused domain, which is essentially the sub-nets between bedside monitoring devices and monitors in Intensive Care, Operating Room, and inpatient settings. IEEE/MEDIX is interested in participating in cooperative efforts in the development of secure messaging standards.

National Council for Prescription Drug Programs (NCPDP)

The National Council for Prescription Drug Programs (NCPDP), as with IEEE, does not currently have an active group in security and confidentiality. This is also due to the focused domain under which they are currently working. The NCPDP, is, however, interested in participating in cooperative efforts in the development of secure messaging standards

ACR NEMA / DICOM

Working Group VI of the ACR NEMA / DICOM Committee has formed an Ad Hoc Committee on Security which is considering additions to the DICOM standard to support the secure exchange of medical images and related information between two entities communicating over a public network (e.g. the Internet). The Ad Hoc Committee has been coordinating its work through a series of meetings and teleconferences with a similar Ad Hoc committee set up by CEN TC 251 WG 4 in Europe, as well as with groups affiliated with JIRA and MEDIS-DC in Japan who are developing demonstrations of secur3 image data transmissions to meet the needs of the Japanese health care institutions.

The Ad Hoc Committee is working with CEN TC 251 WG 4 in developing usage scenarios which will direct long term panning towards comprehensive security within the health care field, and in particular within medical imaging. Realizing that a comprehensive secure environment may be many years off, the Ad Hoc decided to pursue a short term goal of providing limited security using existing technology. It is hoped to incorporate such solutions in the technology demonstrations being done by the Japanese through MEDIIS-DC and JIRA. The short term goal of the Ad Hoc is to draft extensions to DICOM which embedded digital signature in DICOM data objects for data source authentication and as data integrity checks. In addition, the extensions would provide an option to layer DICOM message exchange services on top of a secure transport protocol in order to provide confidentiality during data transfers and to authenticate the parties involve din the information exchange. When practical, these extensions would use existing technology in order to expedite implementation. The Ad Hoc Committee hopes to finalize a draft of these extensions in 1997.

A proposal is being presented at the next meeting of the DICOM committee to transform the Ad Hoc Committee on Security into a full DICOM Working Group. The Working Group would be charged with continuing the Ad Hoc’s work on short term solutions using existing technology. In addition, the working group would develop long term strategies based on anticipated clinical and regulatory needs for utilizing DICOM within a secure environment.

European committee for standardization Technical Committee 251 - Medical Informatics (CEN TC 251)

Working Group 6 on Security, Privacy, Quality and Safety

CEN TC251 Working Group 6 (WG6), under the Chairmanship of Dr. Gunnar Klein of Sweden, is charged with managing the development of security and confidentiality standards for the European Commission. CEN TC 251 WG6 represents a consolidated effort to develop comprehensive standards in security and confidentiality for health information. CEN TC251 WG6 has completed a pre-standard, Security Categorization and Protection of Healthcare information Systems (COMPUSEC), and a digital signature standard. The digital signature standard mandates the use of RSA’s digital signature and authentication algorithm. Additional standards work is currently underway in CEN TC251 WG6 in trusted systems, in conjunction with TrustHealth a project within the Telematics Applications Program, supported by the European Commission. TrustHealth is a project to build and test technical security services to support data confidentiality, document origin authentication, time stamps, access authentication, and professional authorization access controls.

Computer-based Patient Record Institute (CPRI)

The Computer-based patient Record Institute (CPRI) through its Work Group on Confidentiality, Privacy and Security, under co-chairs Kathleen Frawley, JD and Dale Miller, has developed a set of security-related guidelines, a set of sample confidentiality agreements, a glossary of security terms, and a security features document for developing a functional requirements checklist for secure systems. The guidelines currently available are: Guidelines for Establishing Information Security Policies, Guidelines for Information Security Education Programs and Guidelines for Managing an Information Security Program.

American Society for Testing and Materials (ASTM)

The American Society for Testing and Materials (ASTM) Committee E31 On Computerized Systems established a Division on Security and Confidentiality in early 1996 to facilitate the acceleration of health care security and confidentiality standards development within the ASTM, and to coordinate security standards development efforts with other SDOs. The Division on Security and Confidentiality primarily coordinates the efforts of three sub-committees: E31:17, Privacy, Confidentiality, and Access; E31:20, Data and System Security for Health Information; and , E31.22, Medical Transcription and Documentation. These three sub-committees within ASTM currently have seventeen (17) standards under ballot, or in draft our outline, targeted for completion by Spring and Summer 1997. The standards are as follows:

E 1762 Standard Guide for Authentication of Healthcare Information

Standard Specification for Authentication of Healthcare Information Using Digital Signatures Authentication and Authorization to Access Healthcare Information, Internet and Intranet Security for Healthcare Information

Secure Timestamps for Healthcare Information

Data Security, Reliability, Integrity and Availability for Healthcare Information

Distributed Authentication and Authorization to Access Healthcare Information

Standard Guide for Confidentiality, Privacy, Access and Data Security Principles for Health Information Including Computer Based Patient Records; Documentation of access for Individually-Identifiable Health information; Standard Guide for Confidentiality and Security Training of Persons Who Have Access to Health Information; Standard Guide for Amendments/Additions to Health Information by Health Care Providers, Administrative Personnel, and by the Subjects of Health Information; Standard Guide to the Transfer/Disclosure of Health Information in an Emergency Treatment Event; Standard Guide for the Use and Disclosure of Health Information; Policy Guide for the Transfer/Re-disclosure of Health Information Between Health Plans; rights of the Individual in Health Information; Standard Guide to the Use of Audit Trials, and for Access and Disclosure Logging/Tracking in the Management of Health Information; Security and Confidentiality of Dictated and Transcribed Health Information.

Object Management Group

The OMG, the organization that standardizes distributed objects in the CORBA environment, has created two working groups, CORBAsec and CORBAmed. These address standards for security and health care applications, respectively, within the OMG's standard architecture. CORBAmed and CORBAsec recently joined hands to address security in health care.

Government

The U.S. Congress has created and is creating legislation mandating the preservation of privacy of personal medical data. The Health Care Reform Act of 1996, otherwise known as Kennedy-Kassenbaum (PL104-191), has mandated development of security and privacy standards for financial transactions containing medical data. However, the legislation only pertains to transactions that leave the trust boundary of the health care provider's organization. An example of this kind is a claim transaction from a hospital to Medicare that must contain sensitive medical data to support the claim, such as a prescription for drugs that usually treat sexually transmitted diseases.

Congress has not yet mandated security and privacy policy within the operation of a health care provider's electronic systems. However, it is generally assumed by health care providers that if the providers do not implement appropriate and adequate security and privacy of personal medical data themselves from within their own organization in the near future, Congress will intervene by extending the legislation to internal operation of healthcare provider data systems.

HL7 Security Needs

The focus of HL7 security needs analysis is on how systems communicate information using HL7 messages. We will not address data element level security, or access control lists (except for the ability to communicate this information in a message). We will address how ‘message routers’ or EDI gateways (interface engines) affect the problem. Messages may be insecure on the message router, or the message router may make it appear as if all messages came from it, and not the original source.

HL7 must address the following levels or layers of communication: link, subnetwork, end-to-end and application (session-oriented and store-and-forward). For each of these levels of communication, HL7 must address the following security services: authentication, authorization and access control, integrity (system and data), confidentiality, accountability and non-repudiation. The following matrix summarizes the security needs of HL7:

Level	Sub-network	End-to-end	Application (Session oriented)	Application (store and forward)
Authentication
Authorization/Access Control
Integrity
Confidentiality
Accountability
Non-repudiation

HL7 Security Use Case Scenarios

The "straw-man" use case scenarios that follow are an initial attempt to present the current state of affairs pertaining to security services within a heath care enterprise. Collaboration efforts are being initiated between the CORBAmed Security SIG and HL7 Security SIG to define use case scenarios. The HL7 Security SIG plans to replace these "straw-man" use case scenarios with the use case scenarios that are being developed by HL7 technical committees as part of the HL7 Version 3 development process.

Authenticity

An example of an authenticity use case within a healthcare enterprise is the need for a user to be identified to multiple healthcare applications within one organization. For example, a physician must be authenticated to the laboratory information system, the pharmacy information system, and the radiology information system, since information from all three systems is required to accomplish the business process of delivering care to a patient (order a laboratory test, get results of radiology examination to see if an arm is broken, order medication from the Pharmacy). The practitioner must log into several information systems to gain access to needed information. Unfortunately, since the authentication mechanism is not coordinated across various platforms or applications, the information retrieval process may involve multiple ID and password combinations. In addition to authentication mechanisms of passphrase/PIN and biometrics not being coordinated across various platforms or applications, identification of users is not coordinated across healthcare enterprises. The current state of reality finds users’ IDs and passwords being passed in transactions from one information system to another. Even worse, notes containing login IDs and passwords posted on terminals are a common sight in many departments. Vendors offer solutions, such as single sign-on, that provide expedite the login process. However this does not address the underlying need for an enterprise-wide authentication service that provides authentication across multi-vendor applications and operating platforms.

Authorization

An example of an authorization use case relates to an Access Control matrix that regulates access to data within healthcare applications within an enterprise. It is essential that IT systems be protected by comprehensive logical access controls. Access should be guaranteed for legitimate users and denied to all others. All classes of user must be identified and authenticated before any access is granted and further mechanisms must control subsequent reading, writing, modification and deletion of applications and data. There should be no method for bypassing any authentication or access controls. In creating an access control matrix, it is important to realize that health care enterprise users are unlikely to be satisfied with controls that intrude upon working practices and chosen schemes should be transparent and convenient in order to gain acceptance.

Access control based on the role of a participant (user of an information system) in a healthcare organization might be possible, except for the fact that the various roles in healthcare have no current consistent definition. Authorization of access based on role is limited by the extent to which certain confidential information is controlled by the law or policy definitions. Other types of access limitation come into play when a patient wishes to view her/his medical record. Although hospitals have a duty to provide patients and their representatives with facilities to inspect and copy their medical record, the hospital may establish a policy under which a patient’s access rights are limited to viewing the medical record during normal business hours, and which does not interfere with the normal operations of the health care provider. Examples of cases where access might be restricted include records of minors, patients with mental illness, and deceased patients.

Most healthcare organizations have policy guidebooks that address both privacy (law) and confidentiality (policy) definitions within the health care enterprise. The Freedom of Information Act defines the regulations related to healthcare authorization. Specific policy must be defined for:

Worker’s compensation claims

Toxicology Screens

Litigation

Subpoena or Court Order

Legal Counsel for a Minor

Prisoners

Wound by Deadly Weapon

Privacy and Confidentiality

An example of a Privacy and Confidentiality use case is where the security issues turn into heated debates amongst health care privacy advocates. The current debate is ‘who owns the medical record?’ Privacy advocates on one side of the issue believe in the European paradigm; where the patient owns the medical record. In the absence of agreement to the contrary, 125 years of case law stipulates that the hospital (provider of healthcare services) owns the patient record generated and maintained as part of the service provided to a patient. Federal law explicitly states that medical records should only be released by the hospital in accordance with federal and state law, court order, or subpoena (42 C.F.R. 482.24(b)(3) (1995)).

Certain patient information is regarded as so private that several federal and state statutes prohibit or restrict disclosure of such data, except in the specific situations provided by law. Examples of these include:

Drug or Alcohol Abuse

Mental Illness

HIV status

Adoption

Abortion.

A patient also has the right to receive anonymous healthcare services from a provider. The physician-patient relationship should not be intruded upon by computerization of the process of health care.

Audit

An example of an Audit use case scenario can be defined within the scope of non-repudiation, i.e., certifying that services have been performed and monitoring transmission/receipt of claim transactions. For example, a hospital (or provider) daily sends a batch of claims to a payer. A payer is an insurance provider, third party administrator or HMO. The insurance provider must return payment or remittance advice to the hospital after receipt and processing of the claim transaction. An interesting phenomenon that arises in defining the claim transaction process is the concept of "float", a commonly accepted concept in the healthcare domain. Float is an agreed-upon delay in days before a payer must remit payment for healthcare services to a healthcare provider. In an electronic data interchange environment, what value is there in returning the remittance advice sooner? If the process is done manually instead of via EDI, the insurance payer benefits because the delayed payment earns interest. Conversely, EDI benefits the healthcare provider by speeding up the payment process.

Another interesting phenomenon in the healthcare domain is the complex set of parameters that govern claim transaction processing. Perhaps a brief summation of the healthcare payment process in the United States would be useful to readers of this paper who are not familiar with this particular healthcare domain. With the exception of special segments of society (i.e., the military) employers provide healthcare coverage for their employees by insuring them against illness or injury. The contract negotiated between the employer and the healthcare payer defines the limits of employee coverage. Although a healthcare provider is allowed to perform clinical practice to the best of his abilities, the services rendered may not be reimbursed due to the contract the employer has negotiated with the insurer. The provider must then bill the patient for services that are not covered. The rules about what services are under which circumstances are extremely complex; in practice, each employer-insurer contract gives rise to a separate set of rules. As a result, rules for claim transaction processing must take into account multiple contract-based rule superimposed on the already complex structure presented by the health care process.

Many of the mechanisms that enable audit trails in healthcare enterprises today are realized via manual methods. Transaction logs, batch totals and other various and sundry paper reports are used to verify the trail of transactions internal and external to the organization. Since time synchronization is not done across various application and operating systems, a date/time stamp is only an approximation of when an event actually occurred. Audit mechanisms to determine which information system, organization and/or user is responsible for a particular healthcare transaction do not have a consistent representation. The role of the responsible party for a transaction needs to be clearly defined by policy. For example, as result transactions move from the Laboratory Information System to the Clinical Data Repository responsibility for each transaction needs to be defined before auditing mechanisms can be implemented. Audit mechanisms include, but are not limited to:

How each data file is identified.

Controls to ensure that data transmissions are properly routed.

Mechanisms to ensure that all transmissions are received.

Transmission queue processing.

Mechanisms that identify skipped or duplicated transmissions and notify the entity responsible for the transaction.

When a transmission is rejected there must be a communication mechanism that notifies appropriate personnel. There are a number of issues and questions that arise at this juncture:

There usually exists an application log (or queue) for rejected transmissions. How long is the log maintained? (If a log is not maintained for an adequate amount of time, the queue wraps and the audit trail is lost).

Are error messages clear and easily understood?

Are action steps defined and documented for each type of error?

Are controls in place to prevent duplicate processing? (Fraudulent claims).

Are there procedures in place to monitor recurring errors?

Are error logs retained and reviewed to detect and correct problem trends?

Are procedures in place to review sensitive events, pattern and trend analysis, out of tolerance conditions?

Secure Communications (Encryption)

NOTE: This section is organized as several scenarios. The commentary on each scenario talks about the applicability of each already known solution. The solution space is described below.

An example of a Secure Communication use case is defined by recent changes in the College of American Pathologists (CAP) regulatory policies that make use of unencrypted data over the Internet a Class II violation.

"If the facility uses a public network, such as the Internet as a data exchange medium, are there adequate network security measures in place to ensure confidentiality of patient data? Commentary: Information sent over a public domain such as the Internet is considered in the public domain. Thus it is potentially accessible to all parties on that network. Systems must be in place to protect network traffic, such as "fire walls" and data encryption schemes. A documented protocol must be in place."

A specific example of this might be a reference laboratory receiving order entry transactions and sending pathology result reports back to their trading partner. There are essentially two options: one is to encrypt the entire message (which would be handled by the application programs) and the other would be to encrypt the patient sensitive fields only (Patient identifiers, Doctor identifiers, etc.) Hardware encryption is another possible solution, however this is not implemented on health care applications today.

The next use case for Secure Communication is the exchange of HL7 messages between two trusted partners, or well-known sites. The most common scenario is when two systems communicate constantly. For example, the LAB systems is in constant communication with the Clinical Repository. In this case, each connection is planned months ahead, and each system knows the TCP address and any other information about its communications partner.

DES would work quite well here. Only a system knowing the secret password would be able to communicate. Because the connection ~~are so~~ is stable, the logistical problems of conventional key exchange would not be a practical problem.

SSL can be used, too. Each sender would know the certificate of who was supposed to send the message, and could check that the senders certificate agreed with what the MSH segment claimed.

Secure EDI would be used just like SSL. Both parties would know the certificates that they would honor, and could check that the certificate corresponds to the HL7 message.

Another use case scenario for Secure Communication is the flow of HL7 messages from multiple Providers to the Centers for Disease Control. In this scenario, each hospital is required to send reporting data to the CDC upon patient discharge. Certain epidemiologic conditions are defined by diagnosis definition within the clinical applications at the provider. Regulatory agency requires reporting of these disease states to the CDC for epidemiology studies and control of the spread of infectious diseases. These reports will be transmitted intermittently from thousands of sites, resulting in a high level of transaction processing. If CDC doesn't recognize a sender, it doesn't have to do anything right away. CDC can define a retroactive process to determine the identity of a sender.

DES is clearly inappropriate. Managing the secret keys would be a problem.

Secure EDI seems to be the natural candidate. Each report would be secure from tampering. The identity of the sending institution is clear. Any site can send email and CDC doesn't need to respond to incoming EDI email.

SSL should also work in this instance. When a clinical site needs to transmit a report to CDC, an SSL connection is made to the pre-designated SSL port at CDC and the message is sent.

The final use case scenario for Secure Communication is dial up services from a primary care physician (PCP) to a health system for any number of business processes (referral services, eligibility, finance, etc.). In this scenario, doctors and hospitals/clinics exchange data. There are many doctors, and the pool of players changes constantly. Not all senders will be known in advance. One of the important requirements is that these types of communication will be 'bursty'. The dial-up interchange may be a one shot informative message (discharge summary or referral message a flurry of query/response data, or a stream of data for extended periods (i.e., laboratory report data on admitted patients). This scenario mixes the two previously defined scenarios of Well Known Sites and CDC scenarios. Unlike Well Known Sites, we cannot afford a long set up time (with much human interaction) to establish the right to communicate.

DES won't work -- Like CDC, we cannot keep track of all these private keys.

Availability

An example of an Availability use case is the ability to access an application. Information Systems in Healthcare environments must be available at all times. Physicians use Information Systems to make decisions that affect the outcomes of patient care; treatment choices, diagnosis or care plans. For example, if a physician does not know that a patient has diabetes, treatment may be delayed adversely affecting the care a patient receives.

Another possible use case related to Availability involves financial transactions. Information Systems must be continuously available to support the commerce components of health care. For example, if a finance system is not available to transmit claim transactions to a payer by 3:00pm, the revenue stream for that day will not be realized until the next day. In the case of large institutions that receive hundreds of thousands of dollars in remittance activity, the interest lost can be substantial.

Use Case scenarios need to be defined that address the unique healthcare requirements for Data Retention, Persistence, and Archivists. Healthcare information needs to be protected for many years to ensure accessibility and maintain confidentiality. The value of such information, at least to the patient, can be very high, a circumstance reflected in recent legal decisions. Therefore security measures must be able to protect healthcare information in a way that will withstand brute force attacks 50 years into the future. This is perhaps an impossibility today, but certainly a requirement for the healthcare domain tomorrow. For example, a 14-year old patient has a tumor removed. A benign diagnosis is made based on the anatomical pathology report. Twenty years pass and the patient develops a similar tumor; this time the anatomical pathology report states the tumor is malignant. The pathologist will retrieve the twenty year old slides and reports from the history file for comparison with current information. It is possible that the twenty year old report will now be appended to current information and become part of the current record.

Data Integrity

For an example of a use case related to Data Integrity let us refocus on the discussion of unique identifiers. The need to uniquely identify patients and physicians across the healthcare domain would enable database synchronization across healthcare enterprises. Currently unique identification within enterprises is being enabled with the implementation of Master Patient Index (MPI) products. Here is a basic scenario without a mechanism to uniquely identify a patient, within just one healthcare organization: A patient is seen by a physician and a laboratory test is ordered, to be performed prior to next month’s visit. The patient goes to the laboratory one week prior to his next visit and has the lab work performed. When the patient arrives at the laboratory, there is no registration record in the laboratory database. The laboratory registers the patient and sends an HL7 message off to the patient management system with a request for demographic update. If an MPI process is not implemented, the laboratory work may be performed under a unique identifier generated by, and known only to the Laboratory Information System.

Another type of data integrity problem occurs in the case where data becomes corrupted. The data has the potential to be either incorrect, non-accessible (i.e., garbled text), or incorrectly linked (incorrect or missing patient identifier). This could negatively affect the decisions that are made about the care of a patient. Examples of this might include the wrong patient demographic information being associated with a piece of clinical data, fraudulent claims for services that are not rendered, lack of charges for services that are provided.

While a properly implemented MPI can ensure correct record linking, a mechanism to insure that a health care record is intact is also necessary. Hashing and checksum procedures can be used to flag records corrupted in transit. Digital signature procedures, currently in limited use in healthcare systems, can also be used to authenticate the ‘correctness’ of records before transmission.

If a piece of clinical data within a healthcare application is suspected of being corrupted, the standard procedure is to halt any activity on that application until the issue is resolved. Giving out inaccurate clinical data has the potential for misinterpretation; possibly resulting in a care provider (doctor) improperly treating a patient. This could cause irreparable damage to the life of a patient, up to and including death. JAHCO, CAP, and other regulatory agencies define policy for the enforcement of data integrity constraints for healthcare enterprises.

Summary

These are only a few possible use case scenarios related to a healthcare environment. The HL7 Security SIG is looking for and gathering (from HL7 technical committees and other sources) use case scenarios that address the exchange of information within a provider organization. These use cases will be used to determine where security mechanisms are required in support of HL7 needs.

HL7 Security Mechanisms

The following table lists the security services that HL7 needs to support and the security mechanisms that can be used to support them:

Security Service Security Mechanism(s)

Authentication (Peer and Data Origin)	Digital Signature
Authorization and Access Control	Digital Signature, Access Control Lists
Integrity	Encryption, Digital Signature, Check Values
Confidentiality	Encryption, Key Escrow
Accountability	Audit Trails, Logs, Receipts
Non-repudiation	Encryption, Digital Signature

Healthcare Security Policy

Some practical rules governing medical record use were published in the British Medical Journal ["clinical systems security: interim guidelines," BMLJ 1996;312:109-111, by R. Anderson]

Nine rules of clinical system security:

Access control: Each identifiable clinical record shall be marked with an access control list naming the people or groups of people who may read it and append data to it. The system shall prevent anyone not on the list from accessing the record in any way.

Record opening: A clinician may open a record with herself and the patient on the access control list. When a patient has been referred she may open a record with herself and the patient, and the referring clinician(s)

Control: One of the clinicians on the access control list must b marked as being responsible. Only she may change the access control list and she may add only other health care professionals to it.

Consent and Notification: The responsible clinician must notify the patient of the names on his record’s access control list when it is opened, of all subsequent additions, and whenever responsibility is transferred. His consent must also be obtained, except in emergency or in the case of statutory exemptions.

Persistence: No one shall have the ability to delete clinical information until the appropriate time has expired.

Attribution: All accesses to clinical records shall be marked on the record with the name of the persons accessing the record as well as the date and time. An audit trail must be kept of all deletions.

Information Flow: Information derived from record A may be appended to record B if and only if B’s access control list is contained in A’s.

Aggregation Control: Effective measures should exist to prevent the aggregation of personal health information. In particular, patients must receive special notification if any person whom it is proposed to add to their access control list already has access to personal health information on a large number of people.

Trusted Computing Base: Computer systems that handle personal health information shall have a subsystem that enforces the above principles in an effective way. Its effectiveness shall be evaluated by independent experts.

The Secure Environment for Information Systems in Medicine (SEISMED) [http://www.semper.org/sirene/projects/seismed/] guidelines are based on various European healthcare establishments and identify key system security topics important to the healthcare domain. Their valuable enterprise-wide perspective focuses on information technology systems, human resources and management practices at a variety of organizational levels.

Security Policy and Administration

Physical and Environmental Security

Disaster Planning and Recovery

Personnel Security

Training and Awareness

Information Technology Facilities Management

Authentication and Access Control

Database security

System maintenance

Legislation compliance

***Cross reference the NRC report, based on Beth Israel article; "A WWW Implementation of

National Recommendations for Protecting Electronic Health Information"

by John D. Halamka MD, Peter Szolovits Ph.D, David Rind MD, Charles Safran

MD,MS

For Immediate Adoption:

Individual Authentication of Users. Every individual should have a unique username/password for access. Such a policy allows individuals to be held accountable for all actions taken while logged on.

Access controls. Healthcare providers should be allowed to view clinical information on a need to know basis. An example would be access control based on job role established at authentication.

Audit trails. Retrievable audit trails that log all accesses to information should be kept. These logs should include time, date, information accessed or function requested (with parameters), and user Audit trails should be available for patient and clinician review on demand.

Physical Security and Disaster Recovery. Computer terminals should be positioned where unauthorized users cannot view their displays. Unauthorized personnel must be denied access to paper printouts and electronic storage. Backup tapes should be made frequently and tapes should be housed off-site in the case of a physical disaster.

Protections of remote access points. Firewalls should be implemented to provide strong, centralized security and to allow outside access to only those systems critical to outside users. All remote accesses should be protected by single session or encrypted passwords.

Protection of External Electronic Communications. All patient-identifiable data transmitted over public networks should be encrypted.

Software Discipline. Virus checking programs should be installed on all servers and downloads from the Internet to servers should be limited.

System Assessment. Audits should be performed on a monthly basis to examine vulnerability to password cracking programs and to verify procedures implemented to detect system vulnerabilities.

For Future Adoption:

Strong Authentication. Reusable passwords and id's are known to be weak and easily compromised in most organizations. Authentication can be strengthened by requiring that logon be paired with physical possession of "hardware tokens" such as smartcards, magnetic strip IDs or devices with constantly changing passwords.

Enterprise-wide Authentication. Healthcare environments typically have many heterogeneous computing systems. Users should authenticate once and then have access to all relevant systems.

Access Validation. Both system function and content detail should be controlled by role.

Expanded Audit Trails. A consolidated audit facility should be available for the entire suite of software used within a healthcare organization.

Electronic Authentication of Records. Electronic signature should be used to "sign" submitted medical records and cryptographic digital signature should be used when retrieving records to insure that records are not modified during the transmission process

HL7 Secure Transaction Implementations

Although standards organizations currently provide security guidelines for vendors of health care system products, these guidelines are not sufficiently fine grained. The SDOs do not specify the security needs within health care provider's systems. An example is that the HL7 standards organization only wants to secure its transactions. For example, it does not address confidentially of lab results stored in the clinical data repository. Clearly a more comprehensive approach is needed.

Healthcare product vendors along with infrastructure vendors, such as RSA, Verisign, and PGP, are providing better security tools, including those for digital signatures and encryption. However, the mere use of these tools is not comprehensive enough. S-MIME is a secure Internet electronic mail standard which uses RSA encryption and digital signatures. One proposal is for the HL7 organization to specify the use of the S-MIME standard to secure its transactions. This solution secures the communication between two applications, but does not address the problem of unauthorized access to the clinical data repository. This is outside the scope of HL7. However, ASTM has proposed content modeling of healthcare data elements to address security requirements.

There are several reasonable solutions to link level security which are discussed below.

Point to Point link level encryption

Point to Point link level encryption accomplishes the goal of securing the transaction between two known entities (using DES) or two or more trusted entities using SSL. SSL can be used programmatically or

as part of the HTTPS Web application protocol.

Point to Point Profile implementation:

HTTPS (SSL) could be used as a java/javascript/vbscripted web browser talking to a web server to exchange HL7 information. The profile would be something like this:

Use only 128 bit servers and browsers.

Enable RC4 with 128bit key and MD5 MAC

Enable Triple DES with 168bit key and SHA-1 MAC

Disable DES with 56 bit key and SHA-1 MAC

Disable RC4 with 40 bit key and MD5 MAC

Disable RC2 with 40 bit key and MD5 MAC

Disable No encryption with MD5 MAC.

Store and Forward schemes

Store and Forward schemes - S/MIME and PGP/MIME (with EDIINT being an example of how to profile both S/MIME and PGP/MIME). Both S/MIME and PGP/MIME are available as applications within e-mail. A similar application is available using SHTTP on the web.

The discussion on how to use e-mail without a store and forward component as two SMTP server's talking to one another in a point to point fashion is a good argument for not recommending any point to point schemes except for built in SSL as part of a HTTPS scheme.

Store and Forward Implementation Profile:

use S/MIME or PGP/MIME.

Either use standard scriptable e-mail clients or use dedicated SMTP servers.

Consider the use of the EDI profiles or for S/MIME use the following profile:

Enable DES EDE3 in CBC mode with 168bit key

Enable RC2 in CBC mode with 128 bit key

Disable DES in CBC with 56 bit key

Disable RC2 in CBC with 64 bit key

Disable RC2 in CBC with 40 bit key

Enable encryption

Enable digital signature

Enable return receipt

Place HL/7 message in it's own MIME type.

Secure end machines and carefully monitor them with a

standard security tool such as SATAN or ISS.

Implementation Definitions

Data Encryption Standard (DES)

DES is a mathematical algorithm used for the cryptographic protection of computer data. A DES connection between systems means that they share a static key that is used as the basis for encryption of all traffic. This process assumes that the two sites first exchange the static key through some independent communication session.

One small technical detail is how to handle "record marking" over TCP. Some conventional ciphers require that the length of the data be known, and so user data needs to broken into known size chunks which are then encrypted. In this case, the data cannot be decoded as a pure byte stream (one byte at a time.) Instead, chunks of data must be decrypted together. The obvious solution is to use the TCP record marking protocol in which the TCP stream looks like a byte count followed by that many bytes of data.

For example:

[nr_bytes : long]

<'nr_bytes' of data.>

The main drawback of the DES approach is exchanging keys and keeping keys secure. This makes DES most useful for stable communications relationships, such as between the LAB and the Order Entry system, or between two fixed hospitals. DES is unsuitable for communicating with unidentified, untrusted parties.

Secure Socket Layer (SSL)

SSL is available as a programming interface on top of (or augmenting ) the sockets programming interface which in turn is an interface to TCP. One can think of SSL as a layer between the application and TCP, not as a replacement for TCP. SSL offers the following benefits:

Eavesdroppers cannot read the data.

Either side can verify the identity of the other side. One side presenting a "Certificate" to the other accomplishes this.

Data integrity is assured. Any change to a byte will invalidate the checksum on each SSL chunk.

SSL is useful for standard HL7 connections that use TCP today. It is also useful for the 'HL7 over HTTP' profile. A crucial piece of technology is the digital certificate. The digital certificate proves that you know a per-user secret key. Because this secret key is never transmitted, it is operationally easier to actually keep the secret key secret. Thus, a recipient can place high reliance on the assumption that the holder of the certificate (and the secret key) is who the certificate says it is. It is difficult to forge certificates, or steal meaningful private keys, therefore we allocate trust to the certificate authority. SSL appears to be a good choice to solve the problem of authentication and privacy between two sites using TCP. However, SSL is unsuitable for "store and forward" environments. Once the data is read off the wire, all knowledge/proof of its origin is lost. When message routers are involved, SSL authentication only has the ability to authenticate the last link. Without changes on the Hub, it is not possible to verify that the sender is who the HL7 message says it is. (The message router would have to check the MSH segment against the SSL certificate.)

Secure Electronic Data Interchange (EDI) over Multi-purpose Internet Mail Extensions (MIME)

Secure MIME refers to the set of Internet protocols for performing Electronic Data Transfer over MIME. Documents describing these standards are rfc1721 (EDI MIME Objects), the requirements for interoperable Internet EDI, [draft-ietf-ediint-as1-02.txt] "MIME-based Secure EDI".

Secure EDI provides the following benefits:

Packaging a "payload" into MIME. The advantage is that any payload oriented protocol can be sent by Secure EDI.

Encryption of the payload.

Payloads can be encrypted with PGP, or with S/MIME.

Signing of Payload (and data integrity). Payloads can be 'signed' (given a digital signature), this provides a mechanism to prove who sent the payload. The signature ensures the integrity of the data being sent. The sender signs the data sent, and the signature must match the data as received.

Receipts for Messages can be Returned The receipt is a non-repudiated statement that the (signed) receiver actually got the message. This prevents the receiver from saying: "I never got this!"

With Secure EDI, we know who sent the message, and only we will be able to decrypt it, thus we can prove that you got it!

How might we use Secure EDI for HL7 transactions?

First, to exchange HL7 messages, we simply encrypt each payload (between the BeginningOfMessage and EndOfMessage characters that we use in TCP), and send it off. The ACK will come back as a new mail message. It would seem that Secure EDI is less ``real time'' than SSL. Enabling technologies would allow for automatic reading and processing EDI over EMAIL. For HL7 purposes, secure EDI would really be as efficient as SSL. Each site could make a direct SMTP connection, and transport the payload directly to the destination. Implementation-wise, EDI over EMAIL takes more sophistication than TCP or SSL to set up.

Second, secure EDI is particularly suited to reporting. Data not requiring rapid response time can be sent off through the public store and forward mail network. For example, reference labs can send out results and providers can send reports to the CDC using this technique

Standards Relating to EDI over EMAIL.

Requirements for Inter-operable Internet EDI

outlines the problem space for EDI via email

http://www.internic.net/internet-drafts/draft-ietf-ediint-req-00.txt

rfc1767.txt -- MIME encapsulation of EDI objects

broad-stroke definition of the EDI MIME Objects

http://ds.internic.net/rfc/rfc1767.txt

rfc1847.txt -- Security Multiparts

MIME oriented details of secure MIME

http://ds.internic.net/rfc/rfc1847.txt

smimemsg.txt -- S/MIME Message Specficiation

Cryptographic details of Secure MIME documents from a "PKCS" point of view. S/MIME is the preferred technique for sending encrypted messages in the US. PGP is an alternative.

http://www.internic.net/internet-drafts/draft-dusse-mime-msg-spec-00.txt

S-MIME Home Page

Hosted by RSA, it provides an overview of security issues and compares S/MIME with PGP and

PEM.

http://www.rsa.com/rsa/S-MIME/home.html

S/MIME implementation -- Guidelines can be found in:

http://www.rsa.com/pub/S-MIME/smimeimp.txt

ftp://ftp.rsa.com/pub/S-MIME/IMPGV2.ZIP

elkpgp.txt -- MIME Security with PGP

Details on how to use PGP with MIME messages.

http://www.internic.net/internet-drafts/draft-elkins-pem-pgp-04.txt

This has recently become an RFC

http://ds.internic.net/rfc/rfc2015.txt

rcptmdn.txt - Message Disposition Notifications

Explains how senders can be notified of message delivery and provides for "non-repudiation" of

messages.

http://www.internic.net/internet-drafts/draft-ietf-receipt-mdn-01.txt

Pretty Good Privacy (PGP)

PGP (Pretty Good Privacy) is "…a high-security cryptographic software application that allows people to exchange messages with both privacy and authentication. Privacy means that only those intended to receive a message can read it… Authentication ensures that a message appearing to be from a particular person can have originated from that person only, and that the message has not been altered." (Ref.: MIT distribution site for PGP (Pretty Good Privacy) [http://web.mit.edu/network/pgp.html], June 30, 1997). The commercial and shareware implementations of PGP provide methods for file encryption, creation of public and private keys, key management and key escrow, and use of digital signatures. The flow of HL7 messages from multiple Providers to the Centers for Disease Control is use case example in which PGP might provide a secure communications solution. The exchange of public and private keys would allow authentication of both parties in the transaction. The transmitted data would be protected through encryption; typically the public-private key handshake would be used to transmit a one-time static key to be used for encryption of the main message. (Ref.: Simson Garfinkel, PGP: Pretty Good Privacy, Sebastopol, CA: O’Reilly & Associates, 1995)

Recommendations

The profiles suggested here enable security mechanisms for today’s healthcare environment. Technology mechanisms are dynamic. These profiles, no doubt, will be obsolete shortly after publication. The security profiles for healthcare environments will need to be adjusted to incorporate new technology mechanisms. Security requirements need to be defined for healthcare provider institutions. Having the security requirements definitively laid out for healthcare systems gives the product vendors guidelines to conform their products to a more secure environment. Before security requirements can be laid out in a coherent manner, there needs to be a consensus on the architecture of a health care provider system. The health care community is lacking such a standard. Having a standard architecture for health care provider systems could give other existing standards consortia (HL7, ASTM, etc.) a common defined basis on which their particular interests can be founded.

Placement of Security Services form ASTM proposed Framework

	Confidentiality	Integrity	Entity Authentication	Data Origin Authentication	Non-Repudiation	Access Control and Authorization
Link	SILS	SILS	No standards	SILS	N/A	N/A
Subnetwork	IPSEC	IPSEC	IPSEC	IPSEC	N/A	IPSEC
End-to-end	IPSEC	IPSEC	IPSEC	IPSEC	N/A	IPSEC
Application (session-oriented)	SSL, SPKM	SSL, SPKM	FIPS 196, SPKM	SSL, SPKM	E 1762 and digital signature draft; S-HTTP	Draft authorization standard
Application (store-and-forward)	PKCS-7	PKCS-7	PKCS-7	PKCS-7	E 1762, and digital signature draft	Draft authorization standard

Profiles

If it is all so easy, then we should begin to write down the specification for using SSL and Secure EDI with HL7 in "specification-ease"' language. An implementation workshop will be held at the HL7 January meeting to review secure HL7 transaction implementations.

Lessons So Far

***We need to work on this section. Lesson 1 and 3 are content specific. For the content part of a HL/7 document we should just defer to something like the ASTM digital signature guidelines. Should we include content specific discussions here?? Should we save this for the workshop and delete from the white paper altogether??

1. The application needs to look at the MSH to see if the sender is authorized to send that message! The link level support itself just verifies that the sender is known. You might worry about

an authorized site sending messages it isn't authorized to send.

2. Message routers and certificate handling using SSL. SSL can only verify who sent the last leg. This is also the tip of an iceberg. HL7 likes to store messages in queues for reprocessing. We should be able to store some of the authentication information in the HL7 message itself, so that even in the clear, we know something about its origin. A point to point scheme can't be used in a multi-point store and

forward world.

3. Secure Fragments We would like to be able to sign and encrypt pieces of HL7 messages. We may want the MSH segment to be in the clear (but signed), while the payload would be encrypted. We could use this to represent a signed and encrypted result which would be a fragment of an HL7 message. As the data element security work progresses, the notion of secure fragment could be applied at the field level.

APPENDIX A

GLOSSARY OF TERMS RELATED TO INFORMATION SECURITY IN HEALTH CARE INFORMATON SYSTEMS

Objective/Scope

This appendix was prepared in an effort to provide the Standard Development Organization (SDO) membership, work group participants, as well as the public at large with a consistent set of definitions for terms related to the security of health care information. As many of the terms are integrally related, an introduction has been prepared to provide context to the terms in the glossary, to demonstrate the interrelationships among certain key terms, and to guide the user in interpreting terms used in the definitions. As in all language which is contextually rich and complex, there may be several terms which technically may carry variations in meanings but which are often used synonymously. Every effort has also been made to being sensitive to the politically correct usage of terms.

While there are annotations provided for all terms in the glossary, the actual definitions provided are not necessarily reported verbatim from the references annotated, but rather some have been interpreted for the context of health information. Experts involved in the project performed the editing based on personal experience and usage of the terms. In this way, the definitions of the terms both "fit" the purpose intended and are readable by both technically knowledgeable as well as lay individuals who may chose to refer to this work. Where several references differed on the semantic meaning of terms, both references have been included for completeness and clarity.

The Clinical Patient Record Institute (CPRI) Work Group has committed to continuously add, update, and revise this document as appropriate. Comments and/or suggestions for inclusions, deletions, and revisions of definitions should be submitted to CPRI for consideration.

Acknowledgments

ASTM, CPRI, HL7, CEN, OMG

Introduction

Security mechanisms are important in any environment where confidential health information is maintained. Security becomes even more important as electronic systems are implemented and components of Clinical Patient Records and Clinical Data Repository and Warehouses become connected for exchanging information across locations and contribute to continuity of patient care.

For example, a patient may have been born in one hospital, transferred to a neonatal intensive care unit of another hospital, returned home with home care and telemedicine consultations, and later moved to a new location and another provider who needs to understand the nature of the patient's chronic condition. A CPR system would contain the functionality to identify the various locations of health information, and, with the patient's consent, permit access to specific information to authorized users. The locations and nature of information contained in the respective CPRs must never be accessible to anyone without patient authorization and legitimate need for the information.

In order for specific health information to be available when needed, there must be both provisions for access and security measures to control that only authorized individuals or entities obtain the information. A primary function of a CPR system is to provide the security which ensures confidentiality of private health information which has been disclosed to a caregiver. Security systems also protect the integrity of that data.

Privacy, confidentiality, and security are integrally related concepts. Privacy refers to the right of individuals to keep information about themselves from being disclosed to anyone. However, once information is disclosed, such as for the purpose of obtaining health care, the obligation of the second party not to permit access to the information without proper authorization and authentication is referred to as confidentiality. When private information is maintained in (paper or computer) files, security is the means to control access and protect information from accidental or intentional disclosure to unauthorized persons and from alteration, destruction, or loss.

Terms Used in Context of Glossary

Many terms are associated with health information (e.g., data, information, and knowledge) and their compilation and use in an electronic environment (e.g., computer-based patient record, automated record of care). Many terms are also associated with those who both receive health care (e.g., consumer, patient, client, person) and provide health care (e.g., provider, caregiver, clinician, doctor, nurse, hospital). While there are differences among these terms, some terms are used synonymously and some terms have more politically correct usage. Finally, there are many new concepts associated with computer-based patient records for which terms may not have been agreed upon. This is especially true in discussing data which can be identified with a patient ("personally identified data") and data which have been stripped of information which can provide information about a patient's identity ("disidentified data") but may still identify a patient for linkage purposes.

Data, information, and knowledge form a continuum. Technically, "data" refers to a sequence of symbols to which meaning may be assigned. Data are raw facts. When data are processed to provide greater meaning or usefulness, the processed data are referred to as "information." An individual data element (such as results of a blood test) may not provide information because it is not associated with other data that makes the data useful (e.g., the results of the blood test combined with other data may yield the interpretation that the patient has hyponatremia). Practically, the term data is often used synonymously with the term information. Though defined separately, data and information will be used as synonyms in defining other terms in this glossary. "Knowledge" generally means the understanding imparted from a sum of information. (The conclusion that the patient has hyponatremia results from knowledge gleaned from textbooks and experts' summary of findings that hyponatremia is associated with a worsening prognosis in patients with small cell lung cancer.)

Every person has an associated health status at all times, but information about such health status is generally not recorded continuously except for the purpose of providing care. The nature of the computer-based patient record described in this document refers to information about a person's health status and health care as related to specific services designed to diagnose and treat illness and injury as well as maintain health and promote wellness. When a person receives such health care services they may be considered "patients" (of hospitals or doctors), "clients" (of health care programs), "residents" (of long term care facilities), etc. While every effort is made in this glossary to refer to "health care recipient," individual receiving health care, or person, the more familiar term "patient" may also be used to refer to all who may be receiving any health care services.

Health care services are provided collectively by organizations and individually by physicians, nurses, therapists and others. Sometimes the term "provider" is used in a restricted sense to refer to an organization or individual receiving direct reimbursement for health care services. As this is generally limited to hospitals, other health care organizations, and physicians, it does not include an entire cadre of others who provide health care services such as nurses and therapists. "Caregiver" is a term that may be more encompassing when referring to people who provide health care services and may have access to confidential health information about an individual. Health care services associated with diagnosing and treating illness and injury, maintaining health, and promoting wellness may collectively be referred to as "health care" or "clinical" services; the term "medical" generally considered to be restricted to care provided by physicians.

Finally, "identity" and "identification" are important concepts when considering the many uses of health information. Standard dictionaries define identification as evidence of identity, and define identity as the distinguishing characteristics of an individual. There is a subtle but very important difference between these two concepts. When direct patient care is provided, the caregiver generally knows the identity of the individual and identifying information such as name, address, birth date, etc. serve to identify the identity of the individual. (If the individual assumes a disguise, an alias will identify the person without revealing the identity of the person.) In health care research it is often important to know that disparate information belongs to the same individual without needing to know the identity of the individual. A common identifier may be assigned to information to ensure that one set of information can be linked with another set of information, but neither set of information can necessarily be linked to the individual.

Glossary

access: The ability of a subject to view, change, or communicate with an object in a computer system. Typically, access involves a flow of information between the subject and the object (for example, a user reads a file, a program creates a directory).[O’Reilly,1992]

The provision of an opportunity to approach, inspect, review, make use of data or information. Refers to such actions by the individual receiving health care as well as providers of health care services and any other individual or entity who has appropriate authorisation for such actions. [CPRI, 1995b]

access control: The prevention of unauthorised use of a resource. [ISO 7498-2]

Information-use policy to determine who can have access to what data/ information (both within and external to the organisation adopting the access control policy); policies and procedures preventing access by those who are not authorised to have it. [Institute of Medicine, 1994].

access level: A level associated with an individual who may be accessing information (e.g., a clearance level) or with the information which may be accessed (e.g., a classification level). [National Research Council, 1991]

access control list: A list of entities, together with their access rights, which are authorised to have access to a resource. [CORBA Security Services, 1997]

Access mode: A distinct operation recognised by protection mechanisms as a possible operation on data/information. Read and write are possible modes of access to a computer file; execute is an additional mode of access to a program; and create and delete are access modes for directory objects. [MTR-8201; National Research Council, 1991]

accountability: The property that ensures that the actions of an entity can be traced. [ISO 7498 - 2]

The concept that individual persons or entities can be held responsible for specified actions, such as obtaining informed consent or breaching confidentiality. [National Research Council, 1991]

accuracy: Magnitude of errors in data resulting from miscoding or misrepresenting facts, maintaining out-of-date findings, or commingling of data from more than one person. [Institute of Medicine, 1994]

A security principle that keeps information from being modified or otherwise corrupted either maliciously or accidentally. Accuracy protects against forgery or tampering. Synonymous with integrity. [O’Reilly, 1992]

active threat: A type of threat that involves the alteration, not simply the interception, of information. For example, an active tap is a type of wiretapping that accesses and compromises data, usually by generating false messages or control signals, or by altering communications between legitimate users. The danger of an active threat is primarily the authenticity of the information being transmitted. Contract with passive threat. [O’Reilly, 1992]

assurance: A measure of confidence that a system’s security features have been implemented and work property. [O’Reilly]

Justified confidence in the security of a system.

Development, documentation, testing, procedural, and operational activities carried out to ensure that a system’s security services do in fact provide the claimed level of protection. [CORBA Security Services, 1997]

algorithm: A procedure for solving a mathematical problem in a finite number of steps that frequently involves repetition of an operation. In 1972 the National Bureau of Standards (NBS; now the National Institute of Standards and Technology) identified the need for a data encryption standard for use in unclassified applications. The Data Encryption Standard (DES) represents the first cryptographic algorithm openly developed by the US government and has become an American National Standards Institute (ANSI) standard (number X3.92-1981/R1987). [National Research Council, 1991]

architecture: An arrangement of components intended to fulfil some need. [Tuttle, 1994]

asymmetric encryption: A form of cryptosystem in which encryption and decryption are performed using two different keys, one of which is referred to as the public key and one of which is referred to as the private key. Also known as public-key encryption. [ Stallings, ]

asymmetric key: One half of a key pair used in an asymmetric ("public-key") encryption system. Asymmetric encryption systems have two important properties: (i) the key used for encryption is different from the one used for decryption (ii) neither key can feasibly be derived from the other. [CORBA Security Services, 1997]

attack: The act of aggressively trying to bypass security controls. The fact that an attack is made does not necessarily mean that it will succeed. The degree of success depends on the vulnerability of the system and the effectiveness of existing countermeasures. [Fites and Kratz, 1993]

An attempt to bypass security controls on a system. An active attack alters data. A passive attack releases data. Whether or not an attack will succeed depends on the vulnerability of the system and the effectiveness of existing countermeasures. [O’Reilly, 1992]

audit: To record independently and later examine system activity (e.g., logins and logouts, file accesses, security violations). See security audit. [O’Reilly, 1992]

audit event: The data collected about a system event for inclusion in the system audit log. [CORBA Security Services, 1997]

audit trail: Data collected and potentially used to facilitate a security audit. [ISO 7498-2].

The chronological set of records that provides evidence of system activity. These records can be used to reconstruct, review, and examine transactions from inception to output of final results. The records can also be used to track system usage and detect and identify intruders. [O’Reilly, 1992]

Documentary evidence of monitoring each operation of individuals on health information. [National Research Council, 1991] Audit trails may be comprehensive or specific to the individual and information. For example, an audit trail may be a record of all actions taken by anyone on a particularly sensitive file. [OTA, 1993]

authentication: The corroboration that an entity is the one claimed. [ISO 7498 - 2].

The process of proving that a subject (e.g., a user or a system) is what the subject claims to be. Authentication is a measure used to verify the eligibility of a subject and the ability of that subject to access certain information. It protects against the fraudulent use of a system or the fraudulent transmission of information. There are three classic ways to authenticate oneself: something you know, something you have, and something you are. [O’Reilly, 1992]

Providing assurance regarding the identity of subject (author) or object (information). [ASTM 1762] Authentication of data origin is corroboration that the source of data is received as is claimed [ASTM E1762] Authentication of user is the provision of assurance of the claimed identity of an individual or entity [ASTM E1762]

authenticity: A security principle that ensures that a message is received in exactly the form in which it was sent. See also message authentication and message authentication code. [O’Reilly, 1992]

authorise: Granting of rights, which includes granting of access based on access rights. [ISO 7498-2]

authorisation: The granting of rights, which includes the granting of access based on access rights. [ISO 7498 - 2]

The mechanism for obtaining consent for the use and disclosure of health information. The American Health Information Management Association has recommended requirements for valid authorisation. Within the context of a computer-based patient record system, these requirements would include that the authorisation: be documented (electronically), be addressed to a specific health care provider, specifically identify the patient, identify the individual or entity authorised to receive the information, identify the information that is to be released, specify the purpose for the disclosure, specify under what conditions the authorisation will expire unless revoked earlier, indicate that the authorisation is subject to revocation, be (electronically) signed by the patient or patient's legal representative, and be dated sometime after the information has been collected. [AHIMA, 1994a]

authorised disclosure: The release of personally identifiable information to a third party upon authorisation. [Abdelhak, 1996]

availability: The property of being accessible and useable upon demand by an authorised entity. [ISO 7498 - 2].

biometrics: The statistical study of biological data. In computer security, the use of unique, quantifiable physiological, behavioural, and morphological characteristics to provide positive personal identification. Examples of such characteristics are fingerprints, retina patterns, and signatures. [O’Reilly]

A biometric identification system identifies a human from a measurement of a physical feature or repeatable action of the individual (e.g., hand geometry, retinal scan, iris scan, fingerprint patterns, facial characteristics, DNA sequence characteristics, voice prints, and hand written signature). [ASTM E1762]

breach of confidentiality: Breach of contract as applied to confidentiality refers to an action by an individual which reveals a confidence entrusted to that individual by another without the other's consent. For example, courts have demonstrated a willingness to apply the ethical standards of the medical profession to compel physicians to maintain the confidentiality of information they obtain in the course of treating their patients. [OTA, 1993]

breach of security: Any action by an authorized or unauthorized user which results in a negative impact upon the data in the system or the system itself, or which causes data or services within a system to suffer unauthorized disclosure, modification, destruction, or denial of service. [CPRI, 1995c]

certification: The technical evaluation performed as part of, and in support of, the accreditation process that establishes the extent to which a particular computer system or network design and implementation meet a pre-specified set of security requirements. [O’Reilly, 1992]

The administrative act of approving a system for use in a particular application. [National Research Council, 1991]

certification authority: A party trusted to vouch for the binding between names or identities and public keys. In some systems, certification authorities generate public keys.[CORBA Security Services, 1997]

A trusted issuer of certification. [National Research Council, 1991] (Public key) certificate An agreement that binds a user's name to a public key, signed by a trusted issuer. A framework for the use of public key certificates was defined in Consultative Committee on International Telephony and Telegraphy (CCITT) standard X.509. [National Research Council, 1991] The certificate contains the user's name and public key, the certification authority's name, a serial number, and a validity period. [ASTM E1762]

cipher: An algorithm for encryption and decryption. A cipher replaces a piece of information (an element in cleartext) with another object, with the intent to conceal meaning. Typically, the replacement rule is governed by a secret key. [Stallings, 1995]

ciphertext: The result of applying encryption to input data; encrypted text. [CORBA Security Services, 1997]

checksum: Numbers summed according to a particular set of rules and used to verify that transmitted data has not been modified during transmission. [O’Reilly, 1992]

Digits or bits summed according to arbitrary rules and used to verify the integrity of data. [National Research Council, 1991]

check digit: The resultant representation of a checksum operation. [Verhoeff, 1969]

classification: The hierarchical portion of a sensitivity label. (The non-hierarchical portion is called the "category set" or the "compartments.") A classification is a single level in a stratified set of levels. For example, in a military environment, each of the levels UNCLASSIFIED, CONFIDENTIAL, SECRET and TOP SECRET is more trusted than the level beneath it. When included in a sensitivity label in a system supporting mandatory access controls, a classification is used to limit access to those cleared at that level. [O’Reilly, 1992]

classification level: The security level of information. [National Security Council, 1991] See also sensitivity label.

clearance: A representation of the sensitivity level (the classification and the categories) associated with a user in a system supporting mandatory access controls. A user with a particular clearance can typically access only information with a sensitivity label equal to or lower than the user’s clearance. [O’Reilly, 1992]

clearance level: The security level of an individual who may access information. [National Research Council, 1991]

clinical data/information: Data/information related to the health and health care of an individual collected from or about an individual receiving health care services. Includes a caregiver's objective measurement or subjective evaluation of a patient's physical or mental state of health; descriptions of an individual's health history and family health history; diagnostic studies; decision rationale; descriptions of procedures performed; findings; therapeutic interventions; medications prescribed; description of responses to treatment; prognostic statements; and descriptions of socio-economic and environmental factors related to the patient's health. [CPRI, 1996b; ASTM 1769]

cleartext: Intelligible data; text which has not been encrypted or which has been decrypted using the correct key. Also known as plaintext. [CORBA Security Services, 1997]

closed security environment: An environment in which both of the following conditions are true:

Application developers have sufficient clearances and authorisations to provide an acceptable presumption that they have not introduced malicious logic.

Configuration control provides sufficient assurance that applications and equipment are protected against the introduction of malicious logic prior to and during the operation of system applications. [O’Reilly, 1992]

confidential: That which is not freely disclosed; private information which is entrusted to another with the confidence that unauthorised disclosure which would be prejudicial to the individual will not occur. [CPRI, 1994]

confidentiality: A condition in which information is shared or released in a controlled manner. [National Research Council, 1997].

The property that information is not made available or disclosed to unauthorised individuals, entities or processes. [ISO 7498 - 2].

A security principle that keeps information from being disclosed to any one not authorised to access it. [O’Reilly]

The act of limiting disclosure of private matters; maintaining the trust that an individual has placed in one which has been entrusted with private matters. [CPRI, 1995b]

The status accorded to data or information indicating that it is sensitive for some reason, and that therefore it needs to be protected against theft or improper use and must be disseminated only to individuals or organisations authorised to have it. [Ball and Collen, 1992; OTA, 1993]

communications security: Protection of information while it’s being transmitted, particularly via telecommunications. A particular focus of communications security is message authenticity. [Stallings, 1995]

computer-based patient record system: The people, data, rules and procedures, processing and storage devices, and communication and support facilities that provide the capture, storage, processing, communication, security, and presentation of computer-based patient record information. [CPRI, 1995a]

connectivity: The potential (of a computer-based patient record system) to establish links to or interact effectively (with another computer system). [Institute of Medicine, 1994]

consent: The agreement of an individual for a given action relative to the individual. [Huffman, 1985] In health care, consent refers to a communication process between the caregiver and the patient, and may refer to consent for treatment, special procedures, release of information, and advanced directives (which give instructions regarding the patient's wishes in special medical situations {Patient Self-Determination Act, December 1991}). [Abdelhak, 1996] Expressed consent Oral or written agreement. Because it is difficult to prove that oral consent was given, most expressed consent is expected to be recorded with a signature. [Huffman, 1985]

Implied consent An action other than an expressed consent on the part of a patient that demonstrates consent. [Huffman, 1985] For example, the presentation of a person to a caregiver implies to a certain extent consent to at least basic consent. [Abdelhak, 1996]

Informed consent The Veteran's Administration defines that for a consent to be valid, the patient must be informed, which is "a freely given consent that follows a careful explanation by a caregiver to a patient or patient's representative of the proposed diagnostic or therapeutic procedure or course of treatment...the patient should be given the opportunity to ask questions, to indicate comprehension of the information provided, and to grant permission freely and without any coercion for performance of a procedure or course of treatment, as well as the opportunity to withhold or revoke such permission at any time without prejudice." [Huffman, 1985] Regulations promulgated by the Department of Health and Human Services for consent by human subjects in medical treatment (4 CFR Section 46.116) provides that informed consent to release of information should include the elements of disclosure, voluntariness, comprehension, and competence to consent. [OTA, 1993]

contingency plan: A plan for responding to a system emergency. The plan includes performing backups, preparing critical facilities that can be used to facilitate continuity of operations in the event of an emergency, and recovering from a disaster. Synonymous with disaster recovery plan. [O’Reilly, 1992]

countermeasure: An action, device, procedure, technique, or other measure that reduces the vulnerability of a system or a threat to that system. [O’Reilly, 1992]

covert channel: A communications channel that allows a process to transfer information in a way that violates a system’s security policy. [O’Reilly, 1992]

credentials: Information describing the security attributes (identity and/or privileges) of a user or other principal. Credentials are claimed through authentication or delegation and used by access control. [CORBA Security Services, 1997]

cryptanalysis: The branch of cryptology dealing with the breaking of a cipher to recover information, or forging encrypted information that will be accepted as authentic. [Stallings, 1995]

cryptography: The branch of cryptology dealing with the design of algorithms for encryption and decryption, intended to ensure the secrecy and/or authenticity of messages. [Stallings, 1995]

The study of encryption and decryption. From the Greek "kryptos" meaning "hidden" and "graphia" meaning "writing". [O’Reilly, 1992]

The art of keeping data secret, primarily through the use of mathematical or logical functions that transform intelligible data into seemingly unintelligible data and back again. [National Research Council, 1991]

cryptology: The study of secure communications, which encompasses both cryptography and cryptanalysis. [Stallings, 1995]

cyclic redundancy checks (CRC): A mathematical (polynomial division) means to digitally fingerprint or perform an error check on a block of data. [Prosise, 1996]

data: A sequence of symbols to which meaning may be assigned. [National Research Council, 1991]

data dictionary: Information describing the specifications and location of all data contained in a system. [WEDI, 1992] It provides the central resource for ensuring that standard definitions for data elements and data structures are used throughout the computer system. [Abdelhak, 1996]

data integrity: The property that data has not been undetectably altered or destroyed in an unauthorised manner or by unauthorised users. [CORBA Security Services, 1997]

Data Encryption Standard (DES): A private key encryption algorithm adopted as the federal standard for the protection of sensitive unclassified information and used extensively for the protection of commercial data as well. [O’Reilly, 1992]

decryption: The translation of encrypted text or data (called ciphertext) into original text or data (called cleartext). [Kratz, 1997]. Also called deciphering.

The process of decoding a message so that its meaning becomes obvious. [OTA, 1993]

The transformation of encrypted text (called ciphertext) into original text (called plaintext). Sometimes called "deciphering". [O’Reilly, 1992]

delegation: The act whereby one user or principal authorises another to use his (or her or its) identity or privileges, perhaps with restrictions. [CORBA Security Services, 1997]

denial of service: The prevention of authorised access to resources or the delaying of time-critical operations. [ISO 7498 - 2]

digital signature: Data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and integrity of the unit and protect against forgery e.g. by the recipient. [ISO 7498 - 2].

An authentication mechanism which enables the creator of a message to attach a code that acts as a signature. The signature guarantees the source and integrity of the message.[Stallings]

An authentication tool that verifies the origin of a message and the identity of the sender and receiver. Can be used to resolve any authentication issues between the sender and receiver. A digital signature is unique for every transaction. [O’Reilly, 1992]

A means to guarantee the authenticity of a set of input data the same way a written signature verifies the authenticity of a paper document. A cryptographic transformation of data that allows a recipient of the data to prove the source and integrity of the data and protect against forgery. Specifically, an asymmetric cryptographic technique in which each user is associated with a public key distributed to potential verifiers of the user's digital signature used to encrypt messages destined for other users, and a private key known only to the user and is used to decrypt incoming messages. To sign a document, the document and private key are input to a cryptographic process which outputs a bit string (the signature). To verify a signature, the signature, document, and user's public key are input to a cryptographic process, which returns an indication of success for failure. Any modification to the document after it is signed will cause the signature verification to fail (integrity). If the signature was computed using a private key other than the one corresponding to the public key used for verification, the verification will fail (authentication). [ASTM E1762]

digitized signature: An electronic image of an actual written signature. A digitized signature looks much the same as the original, but it does not provide the same protection as a digital signature, as they can be forged and copied. [AHIMA, 1996a]. See electronic signature.

disaster plan: A plan the provides direction and guidelines to protect health information from damage, minimise disruption, ensure stability, and provide for orderly recovery in the event of a disaster, such as flood, fire, etc. [AHIMA, 1996b] The Joint Commission on Accreditation of Healthcare Organisations requires that accredited facilities develop a management plan that addresses emergency preparedness. [Joint Commission, 1996]

disaster recovery: The process whereby an enterprise would restore any loss of data in the event of fire, vandalism, natural disaster, or system failure. [CPRI, 1996c]

disaster recovery plan: See contingency plan.

disclosure: The release of information to third parties within or outside the health care provider organisation from an individual's record with or without the consent of the individual to whom the record pertains. There are a multitude of internal and external users of health information for which various policies of disclosure may apply. For instance, when patients present to a health care facility or provider for treatment, it is reasonable to assume that they are authorising the caregiver to have information about their condition and treatment. However, such assumption should not extend to all employees of a health care provider organisation, but only those with a need to know. Disclosures for quality monitoring, educational purposes, research, administrative purpose, payment purposes, attorneys, law enforcement personnel and agencies, family members, and the patients themselves all must be conducted according to institutional policies. [CPRI, 1995b; CPRI, 1995c]

discretionary access control (DAC): An access control policy regime wherein the creator of a resource is permitted to manage its access control policy information. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control). [O’Reilly, 1992]

domain: The set of objects that a subject is allowed to access. [O’Reilly, 1992]

eavesdropping: Unauthorised interception of information. Usually refers to passive interception (receiving information), rather than active interception (changing information). [O’Reilly, 1992]

electronic signature: The attribute that is affixed to an electronic document to bind it to a particular entity. An electronic signature process secures the user authentication (proof of claimed identity, such as by biometrics {fingerprints, retinal scans, hand written signature verification, etc.}, tokens or passwords) at the time the signature is generated; creates the logical manifestation of signature (including the possibility for multiple parties to sign a document and have the order of application recognised and proven) and supply additional information such as time stamp and signature purpose specific to that user; and ensures the integrity of the signed document to enable transportability, interoperability, independent verifiability, and continuity of signature capability. Verifying a signature on a document verifies the integrity of the document and associated attributes and verifies the identity of the signer. There are several technologies available for user authentication, including passwords, cryptography, and biometrics. [ASTM 1762]

encryption: The cryptographic transformation of data to produce ciphertext. [ISO 7498-2].

The process of encoding a message so that its meaning is not obvious. [OTA, 1993]

end-to-end encryption: A type of encryption in which a message is encrypted when it is transmitted and is decrypted and then encrypted again each time it passes through a network communications node. Sometimes called "online encryption". Contrast with link encryption.

erasure: Removal of signals recorded on magnetic media. Simply reinitialising a disk or tape doesn’t erase data; it simply makes the data harder to access. Someone who knows how to bypass ordinary volume checking mechanisms may still be able to access sensitive data on reinitialised disks or tapes. [O’Reilly, 1992]

fingerprint system: A biometric system that compares a fingerprint pattern with a stored pattern to determine whether there’s a match. [O’Reilly, 1992]

firewall: A dedicated computer equipped with safeguards that acts as a single, more easily defined, Internet connection [Cheswick and Bellovin, 1994]

freedom of information act: Requires that records pertaining to the executive branch of the federal government be available to the public except for matters that fall within exempted areas, including "medical files and similar files, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy." [U.S.C. §552]

functional requirements: A statement of the system behaviour needed to enforce a given policy. Requirements are used to derive the technical specification of a system. [National Security Council, 1991]

gateway: Typically, a system that is attached to two systems, devices, or networks that otherwise do not communicate with each other. Communications from one system or network to another are routed through the gateway. A gateway system may be used as a guardian or "firewall" between trusted and untrusted systems or networks. The gateway filters out any information that’s not allowed to pass from the trusted system to the untrusted system or network, or vice versa. [O’Reilly, 1992]

A device in the computer communications environment that directs information traffic. Gateways are often employed to connect a network under the control of one organisation (an internal network) to a network controlled by another organisation (an external network such as a public network). Thus gateways are natural points at which to enforce access control policies. [National Research Council, 1991]

granularity: The relative fineness or coarseness by which a mechanism may be adjusted. [CORBA Security Services, 1992]

An expression of the relative size of a unit. The smallest discrete information that can be directly retrieved. [ASTM E1769]

In security, degree of protection. Protection at the file level is considered coarse granularity, whereas protection at the field level is finer granularity. Granularity at a single user is fine granularity because it means the access-control mechanism can be adjusted to include or exclude any single user. [Fites and Kratz, 1993]

hash function: A function that maps a variable-length data block or message into a fixed-length value called a hash code. The function is designed in such a way that, when protected, it provides an authenticator to the data or message. Also referred to as a message digest. [Stallings, 1995]

A function which maps strings of bits to fixed-length strings of bits satisfying that it is computationally infeasible to find for a given output an input which maps to this output and computationally infeasible to find for a given input a second input which maps to the same output. [ASTM E1762] One-way hash function A (mathematical) function that is comparatively easy to compute but, when knowing a result, it is computationally infeasible to find any of the values that my have been supplied to obtain it. [ASTM E1762]

health care data: Data which are input, stored, processed or output by the automated information system which support the business functions of the Health care Establishment. These data may relate to person identifiable records or may be part of an administrative system where persons are not identified.

administrative data/information: Data/information collected during the course of a health care event unrelated to the status of the individual's health or health care. Includes demographics, provider identification, caregiver identification, date and time of care, and other such data providing the who, what, when, and where of data capture. [CPRI, 1995a].

clinical data/information: Data/information related to the health and health care of an individual collected from or about an individual receiving health care services. Includes a caregiver's objective measurement or subjective evaluation of a patient's physical or mental state of health; descriptions of an individual's health history and family health history; diagnostic studies; decision rationale; descriptions of procedures performed; findings; therapeutic interventions; medications prescribed; description of responses to treatment; prognostic statements; and descriptions of socio-economic and environmental factors related to the patient's health. [CPRI, 1996b; ASTM 1769]

identification: The process of telling a system the identity of a subject (e.g., a user or another system). Usually, this is done by entering a name or presenting a token to the system. See also authentication. [O’Reilly, 1992]

impersonation: Posing as an unauthorised user, usually in an attempt to gain access to a system. Synonymous with masquerade. [O’Reilly, 1992]

information: Data to which meaning is assigned, according to context and assumed conventions. [National Security Council, 1991]

integrity: The property that data has not been altered or destroyed in an unauthorised manner. [ISO 7498 - 2].

A security principle that keeps information from being modified or otherwise corrupted either maliciously or accidentally. Integrity protects against forgery or tampering.[O’Reilly]

The property that an object (health data or information) only in a specified and authorised manner. Data integrity (the accuracy and completeness of the data [Ball and Collen, 1992]) , program integrity, system integrity, and network integrity are all relevant to consideration of computer and system security. [National Research Council, 1991]

IETF: Internet Engineering Task Force. Reviews and issues Internet standards. [CORBA Security Services, 1997]

intruder: An individual who gains, or attempts to gain, unauthorised access to a computer system or to gain unauthorised privileges on that system. [Stallings, 1995]

kerberos: The name given to Project Athena’s code authentication service. [Stallings, 1995]

key: In cryptography, a secret value that’s used to encrypt and decrypt messages. A sequence of symbols (often a large number) that’s usually known only to the sender and the receiver of the message. See also private key encryption and public key encryption. [O’Reilly, 1992]

An input that controls the transformation of data by an encryption algorithm [National Research Council, 1991]

link encryption: A type of encryption in which a message is encrypted when it is transmitted and is decrypted when it is received. Contrast with end-to-end encryption.[O’Reilly, 1992]

logic bomb: Logic embedded in a computer program that checks for a certain set of conditions to be present on the system. When these conditions are met, the logic bomb executes some function that results in unauthorised actions. [Stallings, 1995]

login: The process of identifying oneself to, and having one’s identity authenticated by, a computer system. [O’Reilly, 1992]

longitudinal/lifetime patient record: The concept of access to health information across an individual's lifetime. [Dick and Steen, 1991] A permanent, co-ordinated record of significant information, in chronological sequence. It may include all historical data collected or be retrieved as a user designated synopsis of significant demographic, genetic, clinical, and environmental facts and events maintained within an automated system. [ASTM E1384]

MAC: Mandatory Access Control - an access control regime wherein resource access control policy information is always managed by a designated authority, regardless of who creates the resources. [CORBA Security Services, 1997]

A means of restricting access to objects that is based on fixed security attributes assigned to users and to files and other objects. The controls are mandatory in the sense that they cannot be modified by users or their programs. [Stallings, 1995] Contrast with discretionary access control.

masquerade: Posing as an authorised user, usually in an attempt to gain access to a system. Synonymous with impersonation. [O’Reilly, 1992]

master patient index (MPI): The means for locating a patient record in a numeric identification system. [Abdelhak, 1996] It has generally referred to an index within a given health care facility, in which case it serves as a patient directory. [CPRI, 1996a]

mechanism: A specific implementation of security services, using particular algorithms, data structures, and protocols. [CORBA Security Services, 1997]

message authentication: Ensuring, typically with a message authentication code, that a message received (usually via a network) matches the message sent. [O’Reilly, 1992]

message authentication code: A code calculated during encryption and appended to a message. If the message authentication code calculated during decryption matches the appended code, the message was not altered during transmission. [O’Reilly, 1992] Sometimes the acronym "MAC" is used for message authentication code.

message digest: Hash function. [Stallings, 1995]

model: See security model.

need to know: A security principle stating that a user should have access only to the data he or she needs to perform a particular function. [O’Reilly, 1992]

non-repudiation: The provision of evidence which will prevent a participant in an action from convincingly denying his responsibility for the action. [CORBA Security Services, 1997]]

Proof (to a third party) that only the signer could have created a signature. A basis of legal recognition of electronic signatures. [ASTM E1762]

object: From the Orange Book definition: "A passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects are: records, blocks, pages, segments, files, directories, directory trees, and programs, as well as bits, bytes, words, files, processors, video displays, keyboards, clocks, printers, network nodes, etc." [O’Reilly, 1992]

one-time cipher: A type of encryption in which a cipher is used only once. Two copies of a pad are created; one coy goes to the sender, and the other to the recipient. The pad contains a random number for each character in the original message. The pad is destroyed after use. Sometimes called a "one-time- pad". [O’Reilly, 1992]

open security environment: An environment in which at least one of the following conditions is true:

Application developers do not have sufficient clearance or authorisation to provide an acceptable presumption that they have not introduced malicious logic.

Configuration control does not provide sufficient assurance that applications are protected against the introduction of malicious logic prior to and during the operation of system applications. [O’Reilly, 1992]

open systems architecture: Use of standardised technology and structures for hardware, operating system, data bases, fault tolerances, and networking and communications transport. [ASTM E1769]

operational assurance: Confidence that a trusted system’s architecture and implementation enforce the system’s security policy. In the Orange Book, the set of operational assurances includes system architecture, system integrity, covert channel analysis, and trusted recovery. [O’Reilly, 1992]

Orange Book: Common name for the Department of Defense document that is the basic definition of the Trusted Computer System Evaluation Criteria (US DOD, 1985d). The Orange Book provides criteria for the evaluation of different classes of trusted systems and is supplemented by many documents relating to its extension and interpretation. [National Research Council, 1991]

ownership: It is a generally accepted principle that the primary patient record is maintained and owned by the health care provider. This principle is established by statutes and licensing regulations in many states, which grant the provider control over the physical document, but give the patient ownership-type rights to the information contained in the record. Therefore, the patient generally has control over the release of patient-identifiable (confidential) information, except in circumstances identified by case law, by federal or state statutes and regulations, and by provider policy. [CPRI, 1994]

passive threat: A type of threat that involves the interception, but not the alteration, of information. For example, a passive tap is a type of wiretapping that involves eavesdropping, monitoring, and/or recording of information, but not the generation of false messages or control signals. The danger of a passive threat is primarily the secrecy of the information being transmitted. Contrast with active threat. [O’Reilly, 1992]

The threat of unauthorised disclosure of information without changing the state of the system. [CORBA Security Services, 1997]

password: Confidential authentication information composed of a string of characters. [ISO 7498 - 2]

A sequence that an individual presents to a system for purposes of authentication. [National Research Council, 1991]

penetration: A successful,, unauthorised access to a computer system. [O’Reilly, 1992]

personally identifiable health information: Health information which contains an individual's identifiers (e.g., name, social security number, birth date) or contains a sufficient number of variable to allow identification of an individual. [OTA, 1993, Institute of Medicine, 1994 ]

personal identification number (PIN): A number or code of some kind that’s unique to an individual and can be used to provide identity. Often used with automatic teller machines and access devices. [O’Reilly, 1992]

Typically used in connection with automated teller machines to authenticate a user. [National Research Council, 1991]

physical security: Protection of physical computer systems and related buildings and equipment from fire and other natural and environmental hazards, as well as from intrusion. Also covers the use of locks, keys, and administrative measures used to control access to computer systems and facilities. [O’Reilly, 1992]

The measures used to provide physical protection of resources against deliberate and accidental threats. [CORBA Security Services, 1997]

plaintext: The input to an encryption function or the output of a decryption function. See cleartext. [O’Reilly, 1992]

primary patient record (primary record of care): The primary legal record documenting the health care services provided to a person in any aspect of health care delivery. This term is synonymous with medical record, health record, primary patient record, client record, and residence record; when stored in a computer system and used by caregivers while providing patient care services to review patient data, receive decision support, and document their own observations, actions, or instructions synonymous with all terms associated with computer-based patient record. [ASTM E1384; CPRI, 1996d]

principal: A user or programmatic entity with the ability to use the resources of a system. [CORBA Security Services, 1997]

privacy: An individual’s desire to limit the disclosure of personal information.[NRC,1997]

The right of individuals to keep information about themselves from being disclosed to anyone. [CPRI, 1995c] As set forth by Samuel Warren and Louis Brandeis in a 1890 article that first enunciated the concept of privacy as a legal interest deserving an independent remedy, privacy was described as "the right to be let alone." Further, Alan Westin conceived of privacy as "an instrument for achieving individual goals of self realisation." [OTA, 1993] Ball and Collen describe privacy as the right of an individual to be left alone, to withdraw from the influence of the environment; to be secluded, not annoyed, and not intruded upon by extension of the right to be protected against physical or psychological invasion or against the misuse or abuse of something legally owned by an individual or normally considered by society to be property. [Ball and Collen, 1992]

A security principle that protects individuals from the collection, storage, and dissemination of information about themselves and the possible compromises resulting from unauthorised release of that information. [O’Reilly, 1992]

Privacy Act of 1974: Grants people certain rights to information collected about them by the federal government and its agencies. Rights include finding out what information has been collected, to see and have a copy of the information, to correct or amend the information, and to exercise limited control of the disclosure of that information to other parties. [U.S.C. §552a(b), 1977]

private key: One of the two keys used in an asymmetric encryption system. For secure communication, the private key should be known only to its creator.[Stallings, 1995]

A key in an asymmetric algorithm; the possession of this key is restricted, usually to one entity. [ASTM E1762]

private-key encryption: A type of encryption that uses a single key to both encrypt and decrypt information. Also called symmetric, or single-key, encryption. contrast with public key encryption. [O’Reilly, 1992]

privilege: A right granted to a user, a program, or a process. For example, certain users may have the privileges that allow them to access certain files in a system. Only the system administrator may have the privileges necessary to export data from a trusted system. [O’Reilly, 1992]

A security attribute which need not have the property of uniqueness, and which thus may be shared by many users and other principals. Examples of privileges include groups, roles, and clearances. [CORBA Security Services, 1997]

The individual's right to hold private and confidential the information given to a health care provider in the context of a professional relationship. The individual may by overt act of consent or by other means waive the right to privilege. For example, if a patient brings a lawsuit against a facility and the records are needed to present the facility's case, the privilege is waived. [Fites and Kratz, 1993]

proof of delivery: Non-repudiation evidence demonstrating that a message or data has been delivered. [CORBA Security Services, 1997]

proof of origin: Non-repudiation evidence identifying the originator of a message or data. [CORBA Security Services, 1997]

proof of receipt: Non-repudiation evidence demonstrating that a message or data has been received by a particular party. [CORBA Security Services, 1997]

proof of submission: Non-repudiation evidence demonstrating that a message or data has been submitted to a particular principal or service. [CORBA Security Services, 1997]

protection boundary: The domain boundary within which security services provide a known level of protection against threats. [CORBA Security Services, 1997]

protocol: A set of rules and formats for the exchange of information, particularly over a communications network. [O’Reilly, 1992] Examples include X12 and HL7.

Protocol Data Unit (PDU): The data fields of a protocol message, as distinguished from the protocol header and trailer fields. [CORBA Security Services, 1997]

public key: One of the two keys used in an asymmetric encryption system. The public key is made public, to be used in conjunction with a corresponding private key.[Stallings, 1995]

In a public-key (asymmetric) cryptosystem, the component of a key pair which is revealed. [CORBA Security Services, 1997]

A key in an asymmetric algorithm, that is publicly available. [ASTM E1762]

public-key cryptosystem: An encryption system which uses an asymmetric-key (q.v.) cryptographic algorithm. [CORBA Security Services, 1997]

public-key encryption: A type of encryption that uses two mathematically related keys. The public key is known within a group of users. The private key is known only to its owner. Asymmetric encryption. Contrast with private key encyption. [O’Reilly, 1992]

read: An operation involving the flow of information from an object to a subject. It does not involve the alteration of that information. [O’Reilly, 1992]

recovery: The restoration of an information system back to an error-free and secure state from which normal operation can resume. [O’Reilly, 1992]

redisclosure: The disclosure by a third party recipient of disclosed health information without the authorisation of the patient. [Abdelhak, 1996]

release of information: The disclosure of documents containing patient-identifiable information to a third party requester. [Huffman, 1985]

reliability: A measure of consistency of data items based on their reproducibility and an estimation of their error of measurement. [Institute of Medicine, 1994]

replay: The recording of a legitimate message and the later, unauthorised resending of the message. [O’Reilly, 1992]

repudiation: The denial by a message sender that the message was sent, or by a message recipient that the message was received. [O’Reilly, 1992]

Denial by one of the entities involved in a communication of having participated in all or part of the communication. [ASTM 1762]

residue: Data left in storage or on a medium before the data has been rewritten or eliminated in some other way. [O’Reilly, 1992]

retina system: A biometric system that compares a retina blood vessel pattern with a stored pattern to determine whether there’s a match. [O’Reilly, 1992]

retention: The maintenance and preservation of information in some form (e.g., paper, microfilm, or electronic storage) for a given period of time. [Abdelhak, 1996] There are no federal laws outlining time frames for the retention of health information. Many states, however, have specific requirements, and these, as well as the statutes of limitation, Medicare Conditions of Participation, and use for patient care, legal, research, or educational purposes, should be used as a basis for developing a retention policy. [AHIMA, 1994]

right: A named value conferring the ability to perform actions in a system. Access control policies grant rights to principals (on the basis of their security attributes); in order to make an access control decision, access decision functions compare the rights granted to a principal against the rights required to perform an operation.[CORBA Security Services, 1997]]

risk: The aggregate effect of the likelihood of occurrence of a particular threat with the degree of vulnerability to that threat and the potential consequences of the impact to the organisation if the threat did occur.[Stallings, 1995]

risk assessment: An analysis of a system’s information needs and vulnerabilities to determine how likely they are to be exploited in different ways and the costs of losing and/or recovering the system or its information. [O’Reilly, 1992]

role: A privilege attribute representing the position or function a user represents in seeking security authentication. A given human being may play multiple roles and therefore require multiple role privilege attributes.[CORBA Security Services, 1997]

RSA Algorithm: An asymmetric encryption algorithm invented by Ron Rivest, Adi Shamir, and Len Adelman. A public-key algorithm based on exponentiation in modular arithmetic. It is the only algorithm generally accepted as practical and secure for public-key encryption.[Stallings, 1995]

A public key crypto-system, invented and patented by Ronald Rivest, Adi Shamir, and Leonard Adelman, based on large prime numbers. [National Security Council] RSA is the most well-known asymmetric algorithm. [ASTM E1762]

safety: The property that a system will satisfy certain criteria related to the preservation of personal and collective freedom from risk. [National Research Council, 1991]

sanitizing: The overwriting of sensitive information. On magnetic media, degaussing. Sometimes called "scrubbing". [O’Reilly, 1992]

seal: To encrypt data for the purpose of providing confidentiality protection. [CORBA Security Services, 1997]

secondary record: A record that is derived from the primary record and contains selected data elements. [ASTM E1384]

secrecy: The intentional concealment or withholding of information [OTA, 1993]

A security principle that keeps information from being disclosed to anyone not authorised to access it. Synonymous with confidentiality. [O’Reilly, 1992]

secret key: A key in a symmetric algorithm; the possession of this key is restricted, usually to two entities. [ASTM E1762]

secret-key cryptosystem: A cryptosystem which uses a symmetric-key (q.v.) cryptographic algorithm. [CORBA Security Services, 1997]

secure time: A reliable Time service that has not been compromised, and whose messages can be authenticated by their recipients. [CORBA Security Services, 1997]

security: The combination of availability, confidentiality, integrity and accountability. Freedom from risk or danger. Safety and the assurance of safety.[O’Reilly, 1992]]

Means to control access and protect information from accidental or intentional disclosure to unauthorised persons and from alteration, destruction, or loss. [CPRI, 1995b] Protection of information systems against unauthorised access to or modification of information, whether in storage, processing, or transit, and against the denial of service to authorised users or the provision of service to unauthorised users, including those measures necessary to detect, document, and counter such threats. [National Security Council] Data/information security The result of effective protection measures that safeguard data/information from undesired occurrences and exposure to accidental or intentional disclosure to unauthorised persons, accidental or malicious alteration, unauthorised copying, loss by theft and/or destruction by hardware failures, software deficiencies, operating mistakes, or physical damage by fire, water, smoke, excessive temperature, electrical failure, or sabotage. [Institute of Medicine, 1994] The protection of the integrity, availability, and confidentiality of computer-based information and resources used to enter, store, process, and communicate it. [NIST, 1994]

security audit: An independent review and examination of system records and activities in order to test for adequacy of system controls, to ensure compliance with established policies and operational procedures, to detect security breaches and to recommend any indicated changes in control policy and procedures. [ISO 7498 - 2]

The facility of a secure system which records information about security-relevant events in a tamper-resistant log. Often used to facilitate an independent review and examination of system records and activities in order to test for adequacy of system controls, to ensure compliance with established policy and operational procedures, to detect breaches in security, and to recommend changes in control, policy and procedures. [CORBA Security Services, 1997]

security breach: The unauthorised disclosure, destruction, modification or withholding of information. [Stallings, 1995]

security domain: A set of information system assets for which an organisation (or user) has responsibility for the implementation and maintenance of security. [Stallings, 1995]

security education program: The systematic, defined method to provide information and to teach skills related to all activities of the organisation related to information security. A complete information security education program addresses policies, standards, training, controls, risk assessment, auditing and monitoring, and assigned responsibility for management of the program. [CPRI, 1995c]

security level: A representation of the sensitivity of information, derived from a sensitivity label (consisting of a classification and categories). [O’Reilly, 1992]

security manager: The person assigned responsibility for management of the organisation's security program. [CPRI, 1996c]

security model: A precise statement of the security rules of a system. [O’Reilly, 1992]

security objective: A statement of intent to counter a given threat or enforce a given organisational security policy. [Common criteria]

security perimeter: An imaginary boundary between the Trusted Computing Base (inside the perimeter) and other system functions (outside the perimeter). In a networking environment, sometimes used to refer to the boundary between trusted and untrusted systems and networks. [O’Reilly, 1992]

security policy: A statement of the set of rules, measures and procedures that determine the physical, procedural and personnel security controls imposed on the management, distribution and protection of assets.[Stallings, 1995]

The framework within which an organisation establishes needed levels of information security to achieve the desired confidentiality goals. A policy is a statement of information values, protection responsibilities, and organisation commitment for a system. It is a set of laws, rules, and practices that regulate how an organisation manages, protects, and distributes sensitive information. [OTA, 1993] The American Health Information Management Association recommends that security policies apply to all employees, medical staff members, volunteers, students, faculty, independent contractors, and agents. [AHIMA, 1996c]

From the Orange Book definition: "The set of laws, rules, and practices that regulate how an organisation manages, protects, and distributes sensitive information. [O’Reilly, 1992]

The data which defines what protection a system’s security services must provide. There are many kinds of security policy, including access control policy, audit policy, message protection policy, non-repudiation policy, etc. [CORBA Security Services, 1997]

security service: Code that implements a defined set of security functionality. Security services include Access Control, Audit, Non-repudiation, and others. [CORBA Security Services, 1997]

security target: The statement of security requirements and functional specifications to be used as baseline for an evaluation. [ITSEC]

sensitive information: Information that, if lost or compromised, would negatively affect the owner of the information, would jeopardise the ability of the system to continue processing, and/or would require substantial resources to recreate. According to the U.S. government (NTISSP 2), "information the disclosure, alteration, loss, or destruction of which could adversely affect national security or other federal government interests". [O’Reilly, 1992]

sensitivity: The degree of importance assigned to information denoting its need for protection against confidentiality related security breaches.

sensitivity label: A security level associated with the content of the information. [National Security Council] Society has historically considered information which has a heightened potential for causing harm to the patient or data subject, or to others, such as the subject's spouse, children, friends, or sexual partners. The degree to which the information will cause public humiliation, stigmatisation, lost employment, insurance problems, or loss of family and friends all contributes to it being identified as "sensitive." Records that contain information about socially or politically prominent persons have also been accorded special protections. Society is beginning to attribute special sensitivity to any and all health information. [Kunitz and Associates, Inc., 1995]

A label representing the security level of an object and describing the sensitivity of the data in the object. The label consists of two parts: a hierarchical classification and a set of non-hierarchical categories or compartments. In systems supporting mandatory access controls, sensitivity labels determine whether a particular subject will be allowed to access a particular object. [O’Reilly, 1992]

signature system: A biometric system that compares a signature with a stored pattern to determine whether there’s a match. [O’Reilly, 1992]

smart card: An access card containing encoded information and sometimes a microprocessor and a user interface. The information on the code, or the information generated by the processor, is used to gain access to a facility or a computer system. [O’Reilly, 1992]

spoof: A trick that causes an authorised user to perform an action that violates system security or that gives away information to an intruder. [O’Reilly, 1992]

subject: From the Orange Book definition: "An active entity, generally in the form of a person, process, or device that causes information to flow among objects or change the system state. [O’Reilly, 1992]

symmetric encryption: A form of cryptosystem in which encryption and decryption are performed using the same key. Also known as conventional encryption. [Stallings, 1995]

symmetric key: The key used in a symmetric ("secret-key") encryption system. In such systems, the same key is used for encryption and decryption. [CORBA Security Services, 1997]

system security: The result of all safeguards including hardware, software, personnel policies, information practice policies, disaster preparedness, and oversight of these components. [Institute of Medicine, 1994]

system security administrator: The person who controls access to computer systems by entering commands to perform such functions as assigning user access codes and privileges, revoking user access privileges, and setting file protection parameters. [CPRI, 1996c]

strong authentication: Authentication by means of cryptographically derived credentials. [ISO/IEC 9594- 8]

technical specification: A technical description of the desired behaviour of a system, as derived from its requirements. A specification is used to develop and test an implementation of a system. [National Research Council, 1991]

threat: An action or event that might prejudice security. [ITSEC]

A possible danger to a computer system. See also active threat and passive threat. [O’Reilly, 1992]

The potential for exploitation of a vulnerability. [National Research Council, 1991]

token: When used in the context of authentication, a physical device necessary for user identification. [National Research Council, 1991]

A physical item that’s used to provide identity. Typically an electronic device that can be inserted in a door or a computer system to gain access. [O’Reilly, 1992]

traced delegation: Delegation wherein information about the initiator and all intervening intermediates is available to each recipient in the call chain, or to the authorisation subsystem controlling access to each recipient. [CORBA Security Services, 1997]

traffic: The message flow across a network. Analysis of message characteristics (e.g., length, frequency, destination) can sometimes provide information to an eavesdropper. [O’Reilly, 1992]

transmission: The exchange of data between person and program, or program and program, when the sender and receiver are remote from each other. [Longley, 1987]

trap door: Secret undocumented entry point into a program, used to grant access without normal methods of access authentication. [Stallings, 1995]

A hidden mechanism that allows normal system protection to be circumvented. Trap doors are often planted system developers to allow them to test programs without having to follow security procedure or other user interfaces. They are typically activated in some unobvious way (elg., by typing a particular sequence of keys). [O’Reilly, 1992]

Trojan horse: A type of programmed threat. An independent program that appears to perform a useful function but that hides another unauthorised program inside it. When an authorised user performs the apparent function, the Trojan house performs the unauthorised function as well (often usurping the privileges of the user). [O’Reilly, 1992]

trust: Reliance on the ability of a system to meet its specifications. [O’Reilly, 1992]

trust model: A description of which components of the system and which entities outside the system must be trusted, and what they must be trusted for, if the system is to remain secure. [CORBA Security Service, 1997]

trusted code: Code assumed to always perform some specified set of operations correctly. [CORBA Security Services, 1997]

TCSEC: Trusted Computer System Evaluation Criteria (a U.S. Department of Defence Standard specifying requirements for secure systems). [CORBA Security Services, 1997]

Trusted Computing Base (TCB): From the Orange Book definition: "The totality of protection mechanisms within a computer system - including hardware, firmware, and software - the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or system. The ability of a TCB to correctly enforce a security policy depends solely on the mechanisms within the TCB and on the correct input by system administrative personnel of parameters (e.g., a user’s clearance) related to the security policy. [O’Reilly, 1992]

Trusted Computing Base. The portion of a system which must function correctly in order for the system to remain secure. A TCB should be tamper-proof and its enforcement of policy should be non-circumventable. Ideally a system’s TCB should also be as small as possible, to facilitate analysis of its integrity. [CORBA Security Services, 1997]

trusted distribution: The process of distributing a trusted system in a way that assures that the system that arrives at the customer site is the exact, evaluated system shipped by the vendor. [O’Reilly, 1992]

trusted facility management: The management of a trusted system in a way that assures separation of duties (e.g., separate operator, system administrator, and security administrator roles), with duties clearly delineated for each role. [O’Reilly, 1992]

trusted path: A mechanism that allows a terminal user to communicate directly with the Trusted Computing Base. The mechanism can be activated only by the person or the TCB and cannot be initiated by untrusted software. With a trusted path, there is no way an intermediary program can mimic trusted software. [O’Reilly, 1992]

trusted recovery: The set of procedures involved in restoring a system and its data in trusted fashion after a system crash or some other type of system failure. [O’Reilly, 1992]

trusted system: A system believed to enforce a given set of attributes to a stated degree of assurance (confidence). [National Research Council, 1991]

A system designed and developed in accordance with Orange Book criteria and evaluated according to those criteria. [O’Reilly, 1992]

A computer and operating system that can be verified to implement a given security policy. [Stallings, 1995]

universal identifier: A means to provide positive recognition of a particular individual for all people in a population. A universal health care or patient identifier provides the identifier for use in health care transactions. [ASTM E1714]

user: A human being using the system to issue requests to objects in order to get them to perform functions in the system on his behalf. [CORBA Security Services, 1997]

A person or a process who accesses a computer system. [O’Reilly, 1992]

validity: The extent to which data correspond to the actual state of affairs or an instrument that measures what it purports to measure. Validity concerns relate to the issue of whether analyses done on a given database are appropriate for the questions being asked and whether those analyses will provide defensible answers that are internally consistent and externally generalizable. [Institute of Medicine, 1994]

virus: A computer program, typically hidden, that attaches itself to other programs and has the ability to replicate. In personal computers, "viruses" are generally Trojan horse programs that are replicated by inadvertent human action and which when executed result in undesired side effects generally unanticipated by the user.

A type of programmed threat. A code fragment (not an independent program) that reproduces by attaching to another program. It may damage data directly, or it may degrade system performance by taking over system resources which are then not available to authorised users. [O’Reilly, 1992]

Code embedded within a program that causes a copy of itself to be inserted in one or more other programs. In addition to propagation, the virus usually performs some unwanted function. [Stallings, 1995]

voice system: A biometric system that compares a vocal pattern with a stored pattern to determine whether there’s a match. [O’Reilly, 1992]

vulnerability: A security weakness due to failures in analysis, design, implementation or operation. [ITSEC]

A weakness in a system that can be exploited to violate the system's intended behaviour. There may be security, integrity, availability, and other vulnerabilities. The act of exploiting a vulnerability represents a threat, which has an associated risk of being exploited. [National Research Council, 1991]

worm: Program that can replicate itself and send copies from computer to computer across network connections. Upon arrival, the worm may be activated to replicate and propagate again. In addition to propagation, the worm usually performs some unwanted function. [O’Reilly, 1992]

Referenced Documents

Abdelhak M (Ed.), 1996 Health Information: Management of a Strategic Resource. Philadelphia: W.B. Saunders Company.

AHA, 1993. Toward a National Health Information Infrastructure: Report of the Work Group on Computerization of Patient Records to the Secretary of the U.S. Department of Health and Human Services. AHA Work Group on Computerization of Patient Records. Chicago: American Hospital Association, April.

AHCPR, 1991. Report to Congress: The Feasibility of Linking Research-Related Data Bases to Federal and Non- Federal Medical Administrative Data Bases. Agency for Health Care Policy and Research Pub. No. 91-0003. Rockville: MD: AHCPR, PHS, U.S. DHHS, April.

AHIMA, 1994a. Guidelines on Maintenance, Disclosure, and Redisclosure of Health Information. Chicago: American Health Information Management Association.

AHIMA, 1994b. Retention of Health Information. Chicago: American Health Information Management Association, March.

AHIMA, 1996a. Electronic Signatures. Chicago: American Health Information Management Association, March.

AHIMA, 1996b. Disaster Planning for Health Information. Chicago: American Health Information Management Association, April.

AHIMA, 1996c. Information Security – An Overview. Chicago: American Health Information Management Association, June.

ASTM E1384. Standard Guide for Description for Content and Structure of the Computer-Based patient Record. ASTM Committee E-31 on Computerized Systems, Subcommittee E31.19 on Vocabulary for Computer-Based Patient Records Content and Structure. West Conshohocken, PA: ASTM, Jan. 10, 1996.

ASTM E1714. Guide for the Properties of a Universal Healthcare Identifier. Committee E-31 on Computerized Systems, Subcommittee E31.12 on Medical Records. West Conshohocken, PA: ASTM, Aug. 15, 1995.

ASTM 1762. Guide for Electronic Authentication of Health Care Information. Committee E-31 on Computerized Systems, Subcommittee E31.20 on Authentication. West Conshohocken, PA: ASTM, Oct. 10, 1995.

ASTM E1769. Guide for Properties of Electronic Health Records and Record Systems. Committee E-31 on Computerized Systems,

Subcommittee E31.12 on Medical Records. West Conshohocken, PA: ASTM, Dec. 10, 1995.

Amatayakul M, 1996. Privacy protections afforded by computer-based patient record systems. Topics in Health Information Management. Gaithersburg, MD: Aspen Publishers, Inc., 16(4), May.

Ball MJ, Collen MF, 1992 (Eds.). Aspects of the Computer-based Patient Record. New York: Springer-Verlag.

Cheswick WR, Bellovin SM, 1994 Firewalls and Internet Security. Reading, MA: Addison-Wesley

CPRI, 1996a. Action Plan for Implementing a Universal Patient Identifier, Draft Version 1.0. Schaumburg, IL: Computer-based Patient Record Institute, May.

CPRI, 1996b. Computer-based Patient Record Description of Content. Work Group on CPR Description, Schaumburg, IL: Computer-based Patient Record Institute, April.

CPRI, 1996c. Guidelines for Managing Information Security Programs at Organizations Using Computer-based Patient Records. Work Group on Confidentiality, Privacy & Security, Schaumburg, IL: Computer-based Patient Record Institute, January.

CPRI, 1996d. CPR Project Evaluation Criteria, Version 2.1. Work Group on CPR Systems Evaluation, Schaumburg, IL: Computer-based Patient Record Institute, March.

CPRI, 1995a. Description of the Computer-based Patient Record and Computer-based Patient Record System. Work Group on CPR

Description, High Level Description Project Team, Ver. 1.0. Schaumburg, IL: Computer- based Patient Record Institute, April.

CPRI, 1995b. Guidelines for Establishing Information Security Policies at Organizations Using Computer-based Patient Records. Work Group on Confidentiality, Privacy & Security, Schaumburg, IL: Computer-based Patient Record Institute, February.

CPRI, 1995c. Guidelines for Information Security Education Programs at Organizations Using Computer-based Patient Records. Work Group on Confidentiality, Privacy & Security, Schaumburg, IL: Computer-based Patient Record Institute, June.

CPRI, 1994. Position Paper: Access to Patient Data. Schaumburg, IL: Computer-based Patient Record Institute, April.

Dick RS, Steen EB (Eds.), 1991. The Computer-based Patient Record: An Essential Technology for Health Care. Washington, DC: National Academy Press.

Fites PE, Kratz MPJ, 1993. Information Systems Security: A Practitioner's Reference. New York: Van Nostrand Reinhold.

The Object Management Group, "CORBAservices", OMG Publications, 1996, Chapter 15.

ISO 7498-2, "Information Processing systems -Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture", International Standards Organization, 1989.

DOD Standard 5200 28 - STD, "Department of Defense Trusted Computer System Evaluation Criteria", Department of Defense, 1985.

Crisis Emergency Response Team: http://www.cert.org/

R. Anderson, "Clinical Systems Security: Interim Guidelines," BrMJ 1996;312:109-111.

Secure Environment for Information Systems in Medicine: http://www.semper.org/sirene/projects/seismed/

A Model EDI Audit Program, A Set of Guidelines for Evaluating Electronic Data Interchange (EDI) Control Issues, DISA Publications, 1995.

National Research Council, "For the Record: Protecting Electronic Health Information", Computer Science and Telecommunications Board, National Academy Press, Washington, DC, 1997.

W. Stallings, "Network and Internetwork Security Principles and Practice", The Institute of Electrical and Electronic Engineers, Inc.,, New York, 1995. ISBN 0-02-415483-0.

D. Russell and G.T. Gangemi Sr., "Computer Security Basics", O’Reilly & Associates, Inc., CA, 1996. ISBN 0-937175-71-4.

PT 6-012 and CEN/TC 251/WG6, EUROPEAN PRESTANDARD Draft, prENV xxxx, 1996-10-26, UDC, "Medical Informatics: Security Categorization and Protection for Healthcare Information Systems", European Committee for Standardization, Central Secretariat: rue de Stassart 36, B-1050 Brussels, 1997.

Applied Cryptography, 2nd edition by Bruce Schneier, John Wiley and Sons, New York, 1996.

ECMA TR/46 "Security in Open Systems: A Security Framework", European Computer Manufacturers Association, 1988.

ITSEC "Information Technology Security Evaluation Criteria" European Commission, 1991.

DOD Standard 5200.28-STD "Department of Defense Trusted Computer System Evaluation Criteria", US Department of Defense, 1985.

X/Open Snapshot: "Distributed Security Framework: Company Review Draft", X/Open Company Ltd.,U.K. 1994.

Computer Related Risks: Peter G. Neuman, The ACM Press, 1995

Mitre "Taxonomy of Threats and Security Services for Information Systems", Working Paper WP 93B0000323, 1994

Healthcare Informatics Standards Board, Inventory of Health Care Information Standards, Pertaining to the Health Insurance Portability and Accountability Act (HIPAA) of 1996 (P.L. 104-191), January 1997.

Borenstein and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanism for Specifying and Describing the Format of Internet Message Bodies", RFC 1522, 1993.

S. Dusse and Tim Matthews, "S/MIME: Anatomy of a Secure E-mail Standard", Messaging Magazine, July/Aug 1996.

Joint Commission on Accreditation of Hospitals, "Consolidated Standards Manual/87", Chicago, JCAH, 1996

AFEHCT Security Work Group, "Health Care Transactions Security Analysis", June 1997.

D. Russell and G.T. Gangemi Sr., "Computer Security Basics", O’Reilly & Associates, Inc., 1992.

Garfinkel and Gene Spaffor, "Practical UNIX & Internet Security", O’Reilly & Associates, Inc., April 1996.

John D. Halamka MD, Peter Szolovits Ph.D, David Rind MD, Charles Safran MD, "A WWW Implementation of National Recommendations for Protecting Electronic Health Information"