Você está na página 1de 5

Security and Confidentiality in Healthcare Informatics

Yahya Y. Al-Salqan
Sun Microsystems
Palo Alto, CA 94303
alsalqan@Eng.Sun.Com

ABSTRACT
In order to provide secure healthcare informatics systems, three different security levels need to be considered: 1) Secure healthcare applications to provide user
authentication and access control mechanism to
healthcare applications, components, and objects.; 2)
Secure database to provide the protection of the database against unauthorized disclosure, alternation, or
destruction of healthcare information by legal personnel; and 3) Secure communication infrastructure
which provides the protection of healthcare informatics systems from unauthorized attempts to access
information or interfere with its operation. In this
paper, we put the emphasis on the database and communication security. Several issues in this document
are learned from our experience in our project, the
Advanced Research TEstbed on Medical Information
System (ARTEMIS).

INTRODUCTION
The evolution from paper-based to computer-based
patient records changes the way in which we have to
perceive and deal with privacy and security issues.
The ability to automatically manipulate data, the
increased ease of possible access to vast amount of
data, and their availability regardless of time and place
all create a completely different and increasingly complex environment that challenges traditional
approaches to confidentiality and security [1]. In this
age of universal electronic connectivity, viruses and
hackers, electronic eavesdropping, and electronic
fraud, there is indeed no time at which security and
confidentiality does not matter.
Knowledge of some data elements can endanger ones
employment, insurability, and even acceptance in a
society. Indications of illicit drug use, sexual promiscuity and sexually transmitted diseases, infection with
human immunodeficiency virus (HIV), and psychiatric admissions, are harmful for obvious reasons.

Within the healthcare informatics system, there is an


emerging need to insure the security and integrity of
healthcare data while maintaining the patients privacy.
This document defines general security requirement
specifications in healthcare informatics systems. We
deal with security in two contexts: first, security in the
database context to mean the protection of the data
base against unauthorized disclosure, alternation, or
destruction of patient information by legal personnel.
Second, security in the distributed system context to
mean the protection of healthcare informatics systems
from unauthorized attempts to access information or
interfere with its operation.

Database Security
Protection of patients confidentiality is a basic
requirement for ethical and legal use of information
technology in healthcare informatics systems. As
information systems for inter-connected hospitals or
rural health clinics become widespread, there is a need
to take measures to guard against intentional or unintentional modification, destruction, loss, use, or disclosure of patients computer-based data.

Data Integrity
The term integrity in this section is used to mean accuracy, correctness, or validity. The problem of healthcare Informatics system integrity is the problem of
ensuring that the data is accurate, that is, to guard the
database against invalid updates. Invalid updates may
be caused by errors in data entry, by mistakes on the
part of operator or by deliberate falsification [7]. In this
section, we assume that the user is authorized to
attempt the update or insert on hand. The healthcare
integrity system needs to check that every update as
well as insert operation is valid and preventing such
operations if it turns out to be invalid.

Updating a patient record is different than updating


other databases because, in general, patient information (such as diagnosis) cannot be changed (updated)
once it is inserted in the patients record. Whereas,
there is no harm to update a mistake or a typo in the
patients name or address. Therefore, a general policy
is required to reflect such practice. This policy may
vary according to the data classification of the item
that needs to be updated. Perhaps top secret and confidential information cannot be updated, whereas
unclassified information can.

Integrity of Distributed Databases


In healthcare informatics, it is common to have a distributed database or a collection of databases. It may
happen that each database is consistent but the federated one is not. Therefore, the integrity subsystem
guarantees merely that such situation cannot occur.
The integrity of federated databases becomes more
complicated when it deals with guaranteeing the integrity of concurrent transaction in different yet linked
databases, especially if these databases are of different
types (relational, object-oriented, etc.). In the following, we enumerate some security requirements of distributed healthcare informatics databases. Most of
these requirements are adopted as a result of our experience in the ARTEMIS project.

Database Schema
A database schema is a collection of objects, such as
tables, views, clusters, procedures, and packages. Each
database has a list of valid users. To access a database,
a user must run a database application (such as
SQL*Forms form, SQL*Plus, or precompiled program in OracleTM [8]) and connect using a user name
defined in the database. When a user connects to a
database, the user has access to all objects contained in
the corresponding schema.

User Authentication
The database management system can require rigorous
user authentication. For example, a database management system might require a user to pass both specific
password and time-of-day checks. This authentication
process takes place in addition to authentication performed by the operating system.
A users password is used while establishing a connection to prevent unauthorized use of the database. A
users password is stored in the databases data dictionary where all the passwords must be stored in an
encrypted format to maintain security for the users. A

user must be able to change his/her own password at


any time.

User Table space Setting and Quota


As part of every users security domain, several
options can be set regarding tablespace usage, such as:
users default tablespace; users temporary tablespace;
and space usage quotas for tablespaces of the database.

User Profiles
As part of a users security domain, limits can be set on
the amount of various system resources available to the
user. This allows security administration to prevent the
uncontrolled consumption of valuable system
resources, such as CPU time. This becomes important
in a multi-user environment, especially when the
healthcare information is stored in a multimedia database.
In some databases like OracleTM [8], resource limits
are managed with user profiles. A profile is a named
set of resource limits that can be assigned to a user.

Views
Views are very useful for adding another level of security to tables: A view can give an access to selected
columns of the base table(s) that define the view. For
example, a view can be defined on the PATIENT table
to show only the patients ID, name, and day of birth
columns. Consequently, if a clerk A is granted access
to the view, he/she will not be able to see any other
information from the patient record.

Roles
Roles are used in databases to facilitate privilege management. Roles are named groups of related privileges
that are granted to users and applications. For example,
if the healthcare provider decided to grant all nurses
the same privileges, such privileges can be formalized
by a role that materializes such privileges. In general,
we recommend this approach for the following advantages:

Reduce Privilege administration: Rather than


explicitly granting the same set of privileges to
every individual (nurse), the privileges for nurses
as a group can be granted to a role.

Dynamic privilege management: If nurses


privileges need to be modified, only the privileges
for the nurses role need to reflect the changes.

Selective availability of privileges: The role


granted to a nurse can be selectively enabled (or

disabled). This adds an important feature to the


healthcare informatics system since personnel,
especially doctors, often need a flexible system.
For instance, it is common for doctors to cover
one another in certain cases. Through this feature,
it will be easy to grant the covering doctor the
same privileges as the original doctor.

Application awareness: Database applications can


automatically enable (or disable) selective roles
when a user, say a clerk, attempts to execute an
application via a given username.

Application-specific security roles can be


protected by passwords; therefore, a user cannot
access an application if he/she does not know the
password.

Role-based access control (RBAC) [9] mechanism can


be utilized to support the creation and management of
such roles in healthcare informatics systems.

Multilevel Database Security


The need for a multilevel security policy in healthcare
informatics systems arises since a database contains
information with a variety of security data classifications (top secret, confidential, etc.) and has users with
different access privileges. The multilevel security policy restricts access to classified data to cleared personnel and requires that classified data be protected not
only from direct access by unauthorized personnel, but
also from disclosure through indirect means [3].
It is required in multilevel database system to have the
ability to individually classify atomic facts in a database. For instance, in a relational database model, this
means that the data are classified at the level of individual data items. Special cases may; however; be classified at the attribute level, the tuple (row) level, or even
the relation (object) level. Consequently, in a multilevel database security environment, not all data are
authorized to all users; therefore, a multilevel relation
will appear differently to users with different access
privileges.
Multilevel database security can be accomplished by
assigning roles to views instead to tables where different views of the same table are created.

Auditing
Database auditing deals with monitoring and recording selected user actions. Auditing is normally used to
investigate suspicious activities and to monitor and
gather information about specific database activities.

Auditing is very essential to healthcare informatics


systems since it helps maintaining the integrity of a
database, or, at least, to discover after the fact who had
affected what values and when.
Audit granularity becomes an important issue. While
auditing events in operating systems are operations
like open file or call procedure, they are seldom as
specific as write record or execute instruction [3].
For auditing to be useful, database audit trails must
include accesses at the record, field, and element or
table level.

Inter-Organizational Security
All of the above requirements address intra-organizational security concerns. The need for inter-organization access control comes into effect once data need to
be shared among two or more institutions, like a hospital and a clinic or laboratory. This is more complex
since several security issues need to considered.
Encryption, secure data communication, interoperability, inter-organizational security policy and arrangements, and integration of heterogeneous databases are
examples of issues that need to addressed. Meta roles
(roles managing roles) can be used in some cases to
guarantee inter-organizational security.

Secure Data Transfer


There is always a trade-off between healthcare information availability and patients privacy protection. In
several cases, there is a discrepancy between patients
and physicians on the sensitivity of data. Physicians in
general prefer rich information on the patients condition, while patients often consider some pieces of
information sensitive and need to be kept secret. The
problem is more complex because there is no quantitative measure to sensitivity, since it is mostly contextspecific and varies from one patient to another.
Generally speaking, any classified data cannot be
transferred without the patients consent. If the patient
refuses to accept the transfer of data which the healthcare provider or practitioner feels is essential to his/her
best interests, the healthcare provider must explain the
consequences of the refusal of transfer. Healthcare
practitioner need to identify which part of the data
need to be transferred or disclosed based on the needto-know basis [10].

Security in Legacy Systems


Security in legacy systems is a very complicated subject. Perhaps the best way to tackle such a problem is
by adopting a well-designed integration approach. Our

approach in the ARTEMIS project relies on using the


Common Object Request Broker Architecture
(CORBA) as a means of integrating legacy systems.
Through CORBA objects, security hooks can be programmed. We believe this approach is flexible. It
allows the adoption of new approaches such as Cryptographic API (CAPI) security services. CAPI will be
discussed in subsequent sections.

Communication Network Security


Distributed systems are vulnerable to attack when
information is in transit. Information must be sent to
the correct place and protected against corruption and
replay. The healthcare information also needs to be
confidential. Security of communication in healthcare
environments should be end-to-end. This section gives
general guidelines for ensuring secure environments.

Cryptography as a Solution
Cryptography is taking a plain text and then encoding
it to a cyphertext. Communications use cryptography
should be useful only to the sender and the intended
recipient. All cryptography schemes rely on key(s).
In conventional cryptographic systems, the sender and
the receiver know a single secret key. Such a mechanism is known as a shared key cryptosystem. The best
known of these in current commercial use is the U.S.
Data Encryption Standard (DES). The problem with
using a shared key is transferring the secret key
between the sender and the receiver.
A contemporary approach to this problem is the public
key cryptography, wherein a message can be encrypted
using one key and decrypted using another. The two
keys are mathematically related in such a way that
knowledge of one key does not make it possible to find
the other. Therefore, one key, the public key, to be
made widely known, while the corresponding key is
kept private to a single user. Messages encrypted using
the private key can be decrypted using the public key
and vice versa.
Public key cryptography is used for both privacy and
authentication. One major problem with public key
cryptosystem is that it is slow. The best known example of a public key cryptosystem is RSA.
Cryptography is a very important part to achieve
secure communication. It can help prevent penetration
from the outside. It can protect privacy of users of the
systems so that only authorized participants can com-

prehend communications. It can ensure integrity of


communications. It can increase assurance that
received messages are genuine. All of these features
are important in the healthcare environment.
Private and Public Key Cryptosystems
To maximize information security in healthcare environment, we recommend using a combination of public key and shared key cryptosystems. The plain text
needs to be encrypted using a DES key. Then the DES
key itself will be encrypted using the public key of the
destination. Finally, both the cyphertext and the
encrypted DES key will be transmitted to the destination. This approach combines the advantages of both
key mechanisms.
Several network protocols are available which use the
combination of the public and private key cryptosystems. The Secure Socket Layer (SSL) protocol from
Netscape [11] is the mostly used protocol for Web
applications, Simple Key management for Internet
Protocol (SKIP) from Sun Microsystems [1 2] and
IPsec from IETF for host based security, are examples
of such protocols which can be utilized in providing a
secure health care informatics.
It is important to note that the communication facility
utilizes the security model must be capable of supporting a variety of cryptosystem algorithms and protocols
and be capable of extending the set of protocols supported as new protocols are developed.

Cryptographic API
New system developers need not tightly couple the
applications to the cryptographic model. Instead, they
can use a much more powerful and flexible alternative
by using a standardized Cryptographic Application
Program Interface (CAPI) [15].
New healthcare application developers can add
hooks to access cryptographic functionality being
developed by other programmers. These hooks are
known as CAPIs [15]. Such an approach has the
advantage that applications can access several cryptographic implementations and are flexible enough to
add new ones in the future.
Currently, there are several CAPI proposals. The most
widely accepted proposals are Generic Security Services -GSS-API (Internet Engineering Task Force)
[16], The Generic Crypto Services-GCS-API (X/
Open) [17], and Cryptoki (RSA) [18]. Each of these
CAPIs was designed to support significantly different

levels of security awareness. The healthcare enterprise


needs to choose according to their security policy.

Authentication
There are two distinct aspects to communication
authentication: ensuring the integrity of the message
and ensuring the identity of the sender.
Message authentication can be assured by the digital
signature, which is done by encrypting the message
with a private key and decrypting it with a public key.
It is important to note that the communication facility
utilizes the security model must be capable of supporting a variety of authentication algorithms and pluggabel authentication modules (PAM) [19] and be capable
of extending the set of protocols supported as new protocols are developed. The usage of smart cards for
authentication will play a major role in health care
informatics.

Conclusion
In this paper, we discussed general security issues in
healthcare informatics. Distributed database and communication network security were discussed in details.

References
[1] Saffron, C., Ring, D, et. al., Protection of Confidentiality in the Computer-Based Patient Record,
M.D. Computing, Val. 12, No. 3, May/June 1995,
Pp.187-192.
[2] Al-Salqan, Y., Jagannathan, J., et al, Security and
Confidentiality in Healthcare, Submitted to the 1st
ACM/NIST Workshop on RBAC.
[3] Panglos, G., Security of medical Database Systems- Part 1, SEISMED (A2033) Project, AIM/
SEISMED/SP-07/10-10-94/2, October 1994.
[4] Panglos, G., Security of medical Database Systems- Part 2, SEISMED (A2033) Project, AIM/
SEISMED/SP-07/20-2-95/3, February 1995.
[5] Robinson, E. N. Jr, Editorial, M.D. Computing,
Vol. 11, No. 2, 1994, Pp. 69-73.
[6] Code Of Ethics, The American Medical Association.
[7] Date, C. J., An Introduction to Database Systems,
fifth edition, Addison Wesley.

[8] ORACLE System 7 Manuals.


[9] Barkely, J., Cincotta, T. et al, The USe of Role
Based Access Control in healthcare Information Security, NIST, http://waltz.ncsl.nist.gov/rbac/.
[10] Griew, A., and Currell, R., A Strategy for Security of the Electronic Patient Record, Institute of
Health Informatics, University of Wales, Aberystwyth,
UK, March 1995.
[11] Hickman, K. E.B., and Elgamal, T., The SSL
Protocol, Internet Draft: draft-hikman-netscape-ssl01.txt, June 1995.
[12] Aziz, A., Simple Key-Management For Internet
Protocols (SKIP), Internet Draft: draft-ietf-ipsecskip-02.txt, Sept. 1995.
[13] STT Wire Formats and Protocols, http://
www.microsoft.com/windows/ie/stt.htm,
October
1995.
[14] Garfinkel, S, and Spafford, G., Practical Unix
Security, OReilly & Associates, Inc. 1994.
[15] NSA Cross Organization CAPI Team, Security
Serivce API: Cryptographic API Recommendation,
NSA, June 1995.
[16] Linn, J., Generic Security Service Application
Program Interface, RFC 1508, Nov. 1993.
[17] X/Open, X/Open Preliminary Specification:
Generic Cryptographic Service API, Draft 3, March
1995.
[18] Kaliski, B., Cryptoki: A Cryptographic Token
Interface, Version 1.0, Draft 4, April 1995.
[19] Samar, V., and Lai, C., Making Login Services
Independent of Authentication Technologies, Proceedings of the 3rd ACM conference on Computer and
Communications Security, March 1996.

Você também pode gostar