Billing. [2]. 7. 13. 12. Cloud-Based. Email Service. [1]. 15. 11. 14. 16. 10. 19. 18. 17. Fig. 1. Healthcare Network Diagram for Hospital ABC. Each arrow indicates a ...
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
Identifying and Evaluating the Threat of Transitive Information Leakage in Healthcare Systems Thomas Lechler* Susanne Wetzel* Richard Jankowski Stevens Institute of Technology Castle Point on Hudson Hoboken, NJ 07030, USA {tlechler,swetzel,rjankows}@stevens.edu
Abstract— Electronic protected health information is a priority among politicians and healthcare providers alike. Under the current circumstances with increased data breaches and their associated costs ensuring information security is essential for the success of healthcare providers. This paper presents a detailed case study of a major hospital in the NY/NJ metropolitan area demonstrating the complexity of the healthcare system and its inherent information security risks. The study shows that only a systemic perspective allows identifying all potential risks and providing solutions for improved information security. The main conclusion of this study is that transitive information risks have major implications for healthcare organizations and regulators. Identifying these risks will significantly improve information security in the healthcare environment.
I. INTRODUCTION In February 2009, the electronic Health Information Technology for Economic and Clinical Health (HITECH) Act [1] was signed into law. The quest of HITECH is to improve efficiency in these complex health care systems through an increased adoption and use of electronic health records (EHR) by the health care providers. In particular, the implementation of EHR also stipulates the electronic processing and exchanging of sensitive patient information. Considering the complexity of relations in today’s health care system and the increased exchange of sensitive electronic information in the future naturally leads to questions about information security and privacy and how it can be maintained. Despite the HIPAA [2] regulations and the extensions introduced as part of the HITECH Act [1] addressing privacy and security concerns associated with the transmission of electronic health records, information security breaches occur at a rather large scale (e.g., [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14]). In particular, [4] lists 49 data breaches since January 1, 2010 affecting 500 or more individuals Breaches due to malicious activities have doubled [12]. Most breaches are due to unauthorized data access by an insider of the organization [11]. Some breaches have rather unusual causes such as a machine incorrectly folding patient bills [5]. According to a recent survey [15], there is a great level of awareness of the stipulated privacy and security regulations, but yet more than 30% of the respondents expect not to be compliant with the regulations by the deadlines set forth by the HITECH Act [16]. Between 2000 and 2007, 11% *This work was supported by NSF grant IIS-0959167.
of all reported data breach incidents in the U.S. were in healthcare, with healthcare ranking second place only after the educational sector [17]. Furthermore, [11] finds that there is a lack of awareness as to the costs associated with a breach in healthcare which typically exceed those associated with breaches in financial or retail sectors. In particular, penalties for breaches as established by the HITECH Act alone may exceed $1 million per breach. A study of the Ponemon Institute [18], [19], [20] finds that the cost of a data breach continues to increase, with an average cost of $3.4 million per breach in 2009. While overall the average the cost for a compromised record was $204, in healthcare the costs averaged at $294 per record [21]. These alarming numbers are clearly underline the economic implications of information security for healthcare systems. While regulations such as HIPAA and the HITECH act have resulted in some increased awareness, investment, and compliance with respect to security and privacy in healthcare systems [11], [22], there are some major deficiencies. Healthcare providers still invest less in IT security than other industries [23], [24]. According to [22], about 60% of of healthcare organizations spend 3% or less of their IT budgets on security and less than 50% have a formally designated chief (information) security officer. However, even bigger a problem is the main technical focus of current security efforts. The top security technologies and tools in place [22], [3] include firewalls, user access controls, audit logs, and wireless security protocols. Furthermore, much if not most of the efforts address matters on a mostly localized level [11], i.e., considering individual entities or individual relationships between entities only. While [11] recognizes the need for a holistic approach, there generally is still a lack of awareness that goes beyond the typical malicious threats (including hacking, deceit, malware, misuse, abuse) and non-malicious threats due to errors and omissions - both from the inside and the outside of the individual entities [14]. In particular, a systemic perspective on information security assurance might uncover unintended threats that do not occur on the individual entity level. Specifically, if non-redundant sets of data are exchanged between different entities—possibly through a sequence of exchanges—these different data flows may lead to a situation in which an entity may derive additional information by aggregating the data it received. The main objective of this
1530-1605/11 $26.00 © 2011 IEEE
1
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
study is to evaluate the importance and risk of these transitive information leakages in healthcare systems. The objective of this paper is to conduct a case study from the perspective of a large hospital in the NY/NJ metropolitan area to analyze the information flows between the partners related to this specific network of organizations. In particular, this paper conducts a systems analysis to identify the potential risks for transitive information leakages [25]. By taking a systemic perspective, this study provides a crucial contribution to the ongoing discussion of information security problems in today’s healthcare systems in specific but also for other complex networks of organizations with constant information flows between each other in general. The case study clearly demonstrates that transitive information leakages are of systemic nature and are conceptually different from information security threats on the individual level. It also demonstrates that these systemic threats cannot be addressed on the local level. The results of this case study have theoretical and political implications for the healthcare system in particular but also for information security assurance for complex systems in general. Outline: The remainder of the paper is structured as follows: In Section II we present the case study which is analyzed in Section III. We close the paper with some conclusions and an outlook for future research in Section IV.
4
Dictation Services [2]
5
12
Software Vendors [57]
15 Collection Agencies [7]
16 11
6 Research Affiliates [300]
Cloud-Based Email Service [1]
17
2 14 Hospital ABC
7
Outsourced Billing [2]
9
18 19
Patient Portal [1]
10
Cloud-Based Server Service [2]
8 1 3
13 Insurance [100]
State DOH [1]
II. A H EALTHCARE N ETWORK C ASE S TUDY In the following, a case study is presented of a healthcare information systems network from the perspective of a single hospital. The real names of the organizations participating in this case study were changed to assure anonymity. The hospital which is at the center of this study is hereafter referred to as Hospital ABC. It is a large NY/NJ metropolitan hospital with $1 Billion in revenue per year. There is a considerable research component provided by Hospital ABC, with numerous university and medical school affiliations within the region. Figure 1 shows the direct data flows Hospital ABC has with other healthcare entities as well as the data flows those entities have downstream with other commercial or healthcare affiliates. Due to the complex nature of the relationships, this study abstracts from the specific entity (e.g., specific insurance company) and focuses on the type of entity (e.g., insurance in general) and the relationship the type has with other players in the healthcare network.1 As part of this study, not all individual entities were contacted due to the complexity of the network and the number of individual entities involved. The purpose of the study is to describe the data flows that Hospital ABC maintains by doing business and analyze the risks that present themselves through these relationships.2
1 While developed for Hospital ABC, the network diagram is by and large representative of major research-oriented hospitals. 2 In particular, this study does not consider the relationships between the patients and other lateral healthcare organizations providing treatment services to the patient [3].
Fig. 1. Healthcare Network Diagram for Hospital ABC. Each arrow indicates a specific data flow labeled to simplify reference in the case study. Except for Cloud-Based Emails Services, [x] indicates the number of entities within that type that Hospital ABC has relationships with. For Cloud-Based services, [1] indicates that an entity typically maintains exactly one relationship with such a provider.
A. Preliminaries Before we can analyze the data flows, we first provide an overview of healthcare-specific applications and discuss the main types of data sharing in healthcare systems. We furthermore define the patient’s data set as represented in these data flows. 1) Healthcare-specific Applications: Healthcare applications are typically very specialized with a limited number of vendors producing such applications. For Hospital ABC, the top four healthcare applications are: • Electronic Medical Record (EMR): System that documents the patient’s medical record in an electronic format. • Laboratory Information System (LIS): System that documents patient laboratory test results. This system interfaces with other systems, such as the EMR to allow a clinician to view lab results from the medical record. • Order Management System (OMS): System responsible for placing orders, such a laboratory work or diagnostic imaging within the hospital. • Picture Archival and Communications System (PACS):
2
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
Electronic system that is used to archive and store radiology images. For each of these applications, Hospital ABC considered less than five vendors to provide such an application—which byand-large is representative for the major healthcare providers similar to Hospital ABC. 2) Data Sharing in Healthcare: Healthcare entities frequently share data with outside providers. However, the sharing is governed by federal regulations. Section 45 C.F.R. 164.501 of the Health Insurance Portability and Accountability Act (HIPAA) [2] defines the term covered entity (CE) as either a Health Plan, a Healthcare Clearinghouse, or a Healthcare provider that transmits electronic data in a manner covered under HIPAA. If one covered entity wishes to transmit protected health information (PHI) to another covered entity for purposes of health treatment, payment, or operations, it is permitted to do so under HIPAA. This would include the case of a hospital reporting patient information to an insurance company. In cases where a covered entity wishes to transmit health information to a non-covered entity, such as a software vendor, a Business Associate Agreement (BAA) is required. A BAA is a contract established by the covered entity that holds the non-covered entity, otherwise known as the business associate, responsible to provide adequate security controls to protect the data that they are given. Business Associate Agreements usually contain the following components relating to the security and privacy of PHI: •
•
•
• • •
Agreement of specific use that the Business Associate (BA) may obtain PHI under the course of the agreement. This is a clear definition of what the BA is allowed to do with the PHI. For example, if the BA is collecting data to provide software support, that use will be included in the BAA. Any other use, such as collecting data for research, would be prohibited. Agreement that BA will not use or disclose PHI in a manner not covered by the agreement or as required by law. Agreement that BA will use appropriate safeguards to protect PHI. Our analysis did not find any agreements that specified what was considered an appropriate safeguard for protecting data. Agreement that BA will report to the CE any disclosure and make effort mitigate any disclosure of PHI by BA. Agreement that BA will hold any subcontractor that receives PHI from BA to the same terms in the BAA. Agreement that BA will maintain an accurate audit trail of all access to PHI.
In the event that identifiable patient information is to be shared for the purpose of research, the organization must get an authorization from each patient that will take part in the study. This authorization will outline the scope of the study and specify to the patient how their data will be used.
name ssn pssn mrn research id health plan acct numbers email addr ph numbers fax numbers address dob dod diag treatment
Patient Data Set Identifiers Patient’s Name Patient’s Social Security Number (SSN). Patient’s partial SSN, such as “last 4.” This is implied if the ssn is sent. Patient’s Medical Record Number (MRN). Unique research identifier3 that is used to identify the patient with a study. Patient’s insurance ID number. Patient’s credit card, savings, or checking account numbers. Patient’s email address. Patient’s phone numbers. Patient’s fax numbers. Patient’s address of residence. Patient’s date of birth (DOB). Patient’s date of death (DOD). Patient’s diagnosis. Patient’s treatment information. TABLE I PATIENT DATA S ET.
Government Regulated Data Sharing: Certain government entities require the mandatory reporting of specific diseases. For example, in New York State, certain communicable diseases must be reported promptly to the New York State Department of Health. This reporting requirement clearly identifies the patient by name and demographic information as well as the medical condition being reported [26]. Insurance Data Sharing: Since insurance companies are often used to pay for medical treatment, the hospital is required to share any diagnostic and treatment information with the insurer. Insurance companies have access to a patient’s medical record for all treatment that is covered under the insurance policy, and maintain databases of health information for each patient. Commercial Data Sharing: There are many ways that a patient’s record can be shared with a commercial entity. Most common would be the case of a healthcare function being supported by a commercial entity, such as a software vendor providing support for one of its software applications. This sharing can be in the form of the software vendor having access to the hospital’s systems in order to do on-demand support. In addition, hospitals may send data, such as patient records to the vendor for testing. Research Data Sharing: Many healthcare organizations have a significant research function and collaborate with other healthcare providers and pharmaceutical companies. Depending on the type of research, the entities may share identifiable information about the patient, including the medical record. General Purpose Data Sharing: As organizations seek to reduce costs, many are looking to cloud-type providers as a way to outsource application. Google’s Postini service [27], for example, puts all of an organization’s email into Google’s cloud. As users access their email, they make requests to Google’s systems, which in turn. provide the users with their email. In a healthcare environment email is a core 3 This ID is unique within a particular study, and is set by the lead organization of the study.
3
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
service, with many patient identifiers contained within the mail system as physicians and other clinicians collaborate about treatment and other services. 3) Patient’s Data Set: The data set in Table I defines the information that Hospital ABC typically shares with other entities. This data set is simplified in some areas such as diagnosis and treatment which usually encompass many discrete data points. In the following, {name, ssn, pssn, mrn, research id, health plan, acct numbers, email addr, ph numbers, fax numbers, address, dob, dod, diag, treatment} is referred to as complete patient data set. B. Case Study We now provide a detailed analysis of the individual data flows in Hospital ABC’s healthcare network (labeled as Flows 1 to 19 in Figure 1). A summary of the data exchanges is found in Table II. Flow 1: Hospital ABC - Insurance Relationship Hospital ABC has a relationship with the insurance company for purposes of payment for treatment. There are roughly 40 major insurance companies in the United States, with many more smaller insurers providing healthcare benefits to patients. Hospital ABC deals with over 100 insurance companies. As patients are diagnosed and treated, the Hospital ABC sends information to the insurance company allow the billing of treatment services performed. This information is sent to the insurance carrier by a daily batch file transfer through a secure mechanism.4 The insurance company also has a file for each patient, including all prior medical information, demographic information, and the patient’s social security number. Since the insurance carrier is another covered entity with a direct responsibility under HIPAA to protect patient information, no Business Associate Agreement is needed for this file transfer. The insurance company is held to the same obligations under HIPAA as is Hospital ABC. Flow 2: Hospital ABC - Research Affiliate Relationship Hospital ABC sends data to a research affiliates for the purposes of a clinical trial or other such study. The research division of Hospital ABC seeks out and obtains outside funding for research from public sources, such as through the National Institute of Health, or private sources, such as through a clinical trial. This external funding provides an incentive for the open collaboration with other organizations. Many of these studies span the course of several years. 4 In this paper, we use the terms “secure” or “securely” to define a method of how data is communicated or handled between entities. By using these terms we indicate that the data is appropriately protected with industryaccepted encryption, such as the Advanced Encryption Standard (AES), and has appropriate authentication and authorization mechanisms in place. Some data flows may be through AES Virtual Private Networks, Secure File Transfer Protocol mechanisms, or by encrypting the data source with an appropriate file encryption mechanism. HIPAA guidance often cites NIST regulations when specifying security controls, and our definition of secure would imply that these controls are followed in the manner offering the most protection.
If the research affiliate is another hospital or educational research organization, the data will usually be sent to and aggregated by the organization that has received the grant to perform the study. In the case of multiple hospitals collaborating for research, there would be one organization that collects the data, and possibly disseminates it with the other study participants. This may be through the use of an online Web system that participating organizations can log into and view results of the study. There are other, commercially funded research affiliates, such as the case of a pharmaceutical company. This company would provide a drug to patients, which is monitored by a Principal Investigator (PI) located within Hospital ABC. The PI would report findings back to the pharmaceutical. Hospital ABC, like many larger research-oriented hospitals, has just under 300 research affiliates, with upwards of a thousand particular studies with both industry and other research organizations. Depending on the study, data may be sent to the affiliate through a secure Web interface or other similar secure service. No Business Associate Agreement is needed as the patient has provided consent to participate in the study. Flow 3: Hospital ABC - State Department of Health Relationship Hospital ABC sends data about communicable diseases to the State Department of Health (DOH) as per state law. The data is used to allow the state to monitor potential epidemics, such as measles and smallpox. Data is sent to the state agency via a secure mechanism. No Business Associate Agreement is needed as this is a state agency conducting an official function regulated by law. Flow 4: Hospital ABC - Software Vendor Relationship For support purposes, Hospital ABC allows software vendors to have access to the clinical computing environment. This is a vital function that is provided by the vendor, with Hospital ABC counting on timely resolution to system issues to maintain an effective clinic and provide patient care. Hospital ABC may provide the software vendor full administrative control via a secure remote access mechanism to the clinical systems the vendor supports. Or Hospital ABC may require that the vendor work with Hospital ABC’s IT staff to resolve the issue without the vendor getting access to the hospital’s systems. The following main cases were identified: •
Software vendors with full access to the clinical system: 63% of all Hospital ABC’s clinical software vendors have full administrative control of the systems that they support. This would allow the vendor complete access to Hospital ABC’s patient records that are contained within the application. This may include sending portions of the database to the vendor to allow a replication of the issue at the vendor site. Prudence might suggest to give the vendor access only to a test system containing test data, and require the Hospital ABC’s IT staff to replicate the issues in test. However, Hospital ABC is concerned that issues with a crucial healthcare system may adverse
4
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
From To Flow name ssn pssn mrn research id health plan acct numbers email addr ph numbers fax numbers address dob dod diag treatment
H I 1 x
H R 2 x
H G 3 x
x x
x x
x x
x x
x x
x
H V 4 x x x x x x x x x x x x x x x
H D 5 x x x x x x x x x x x x x x x
H C 6 x x x x
H O 7 x x x x
x x x
x x x
x x
x x
x
x
H S 8 x x x
H P 9 x
P S 10 x
R V 11 x
x x
x x
x x x x x x x
x x x x x x x
x x
x x
x x
x x
D V 12 x
I S 13 x x x
x
D E 15 x x
x
x x x x x
R S 14 x
C E 16 x x x x
O E 17 x x x x
O S 18 x x x x
P E 19 x
x x x
x x x
x x x
x x
x x
x x
x x x x x x x
x
x
x
x x
x x
x
x x
x x x x x x x x x x
x x x x
x x
TABLE II DATA E XCHANGES FOR F LOWS 1 TO 19 IN F IGURE 1. Legend: H (Hospital ABC), I (Insurance), R (Research Affiliates), G (State DOH), V (Software Vendors), D (Dictation Service), C (Collection Agencies), O (Outsourced Billing), S (Cloud-Based Server Service), P (Patient Portal), and E (Cloud-Based Email Service).
•
•
affect patient treatment and cause issues at the clinics where patients are being treated. Many of Hospital ABC’s clinical applications provide an audit trail of the vendor’s activity, however with administrative access the vendor has the capability of removing the audit trail. Software vendors with partial or limited access to the clinical system: 19% of all Hospital ABC’s clinical software vendors have partial or limited access to the systems they support. This includes cases such as that the vendor cannot access the application unless Hospital ABC’s staff are overseeing and monitoring the access to the application. Vendors constrained into this limitation are the smaller companies that Hospital ABC deals with. The reason for this is because the vendor does not have advanced remote monitoring capabilities to detect issues on their own, rather they require a call from Hospital ABC to report a problem. After a problem is reported by Hospital ABC, a collaborative session is opened where the vendor will assist with the resolution of the issue. Software vendors with no access to the clinical system: Less than 10% of all Hospital ABC’s clinical software vendors do not have access to the clinical system. This is largely due to legacy applications where support has been discontinued, or applications that are less critical and are supported by Hospital ABC’s IT staff.
Hospital ABC also has three vendors that have asked for and received a complete database of all of Hospital ABC’s patients to be used in the context of testing a new application. The purpose is to allow the vendor to test with a large data set of production data. When the new application is produced, the vendor will provide Hospital ABC with a copy at a deeply discounted rate incentivizing the data sharing with the vendor. Hospital ABC, as a larger hospital with a fully electronic medical record, has 57 relationships with clinical software
vendors. Furthermore, the clinical applications that Hospital ABC uses are so specialized that there may be only a few players in a particular niche market. It is not uncommon for Hospital ABC to use the same PACS and LIS vendors as do other hospitals of a similar size. Data is sent to the software vendor via a secure mechanism. A Business Associate Agreement is needed and is in effect for this relationship. Flow 5: Hospital ABC - Dictation Services Relationship As physicians treat patients, they often will dictate notes about the patient that get transcribed into the medical record. The physician will typically use either a stand-alone handheld device, or a dictation provider service that allows the physician to dictate the memo into a voicemail-like system for transcription. The dictation vendor then has staff that listens to each memo and transcribes it for entry into the patient’s EMR. Hospital ABC has 3 different dictation providers that are used for this type of service. Two vendors support handheld dictation, and the other is used for phone-recorded dictation. It isn’t uncommon for a clinical department to have the business relationship with the dictation service, thereby increasing the number of dictation vendors that the hospital deals with. Hospital ABC has such an arrangement, with the Department of Surgery using one handheld provider, and the rest of the hospital using another handheld provider. Dictation services are a commodity, and dictation providers have been known to outsource their services to subcontractors, who in turn, may contract with subsubcontractors. This has posed privacy concerns in the past, such as the case of a dictation provider based in Pakistan attempting to extort money from the University of California at San Francisco [28]. In such cases, the hospital may believe that they are dealing with the dictation provider, however it may be a subcontractor that is the one with the business
5
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
relationship with the hospital. Data is sent to the dictation provider via a secure feed, such as a mechanism initiated when the physician “syncs” the handheld with her workstation. Other solutions involve the physician dialing a number that is a voice recording system hosted by the dictation provider. The voice memo is saved on the vendor’s system and then transcribed back into the hospital’s EMR. A Business Associate Agreement is needed and is in effect for this relationship. Flow 6: Hospital ABC - Collection Agencies Relationship In the event that a patient will not pay Hospital ABC for services rendered, Hospital ABC will utilize the services of a collection agency in an attempt to recover a portion of the outstanding balance. Hospital ABC does not handle difficult collections, rather the claim is sold to the collection agency at a fraction of the value owed. Hospital ABC deals with 7 collection agencies regularly. There are two main reasons for the number of agencies. Hospital ABC allows the various agencies to compete against one another, and the Hospital ABC bills patients different than the physicians, therefore there are two major billing groups. The data would be sent securely to the collection agency through a batch process, and a Business Associate Agreement is needed and is in effect for this relationship. Flow 7: Hospital ABC - Outsourced Billing Relationship Hospital ABC outsources its billing functions to outside providers. The providers issue paper or electronic statements to the patient, and handle the financial transaction as well, such as processing a credit card on behalf of Hospital ABC. A major bank will handle the funds, however there is no indication that the bank gets medical information, rather they simply handle the transaction between the billing provider and the hospital. Hospital ABC uses three companies to provide this outsourced billing service, one billing provider for paper bills, one provider for handling electronic payment, and a third provider for handling electronic payment via the patient portal. The patient portal process is described in Flow 9 and is included as a separate entity in Figure 1. Paper bills are sent to patients who have opted to not get an electronic statement. The patient pays by credit card or issuing a check which is handled by the billing provider and processed through the bank. The billing provider that handles electronic transactions maintains a Web-based billing system for patients to access. The provider sends the patient an email stating that there is a bill from the hospital. The patient accesses the Web system and can pay bills using a credit card or bank transfer. A Business Associate Agreement is needed and is in effect for these relationships. Flow 8: Hospital ABC - Cloud-Based Server Service Relationship Hospital ABC has a relationship with a cloud-based server service for the purpose of scalable server services
on-demand. The cloud vendor provides Hospital ABC with computing resources as are needed for rapid deployment of server functions that cannot be supported by internal processes. For example, various research projects may require processor-intensive computing resources. The cloud vendor has the ability to provide this computing power on-demand for the hospital. This is a new use-case for Hospital ABC, but many departments are exploring the option, with research groups already utilizing this for their research needs. There are two primary providers for this type of service currently in production. The full data flow between the hospital and cloud server provider is through a secure channel. Because there is patient data stored on the cloud server provider’s systems, a Business Associate Agreement is needed and is in effect. Flow 9: Hospital ABC - Patient Portal Relationship Hospital ABC contracts with an external provider to offer patient portal services. The portal allows a patient to log in to a web interface and communicate with their physician, view laboratory results, check invoices, and pay bills online. The online bill paying is a separate service than those described in Flow 7, with the portal provider getting a direct billing feed only for patients that have enrolled in the patient portal program. Enrollment into the portal automatically signs the patient up for electronic bill paying through the portal systems. This has resulted in substantial cost savings for Hospital ABC, as the electronic method of collecting bills has been more cost effective than the paper methods. The portal is developed in a standard Web application development environment, and provider hosts the entire web infrastructure at an off site location, which is replicated to various data centers for redundancy. The data would be sent to the patient portal provider through a secure channel, such as an encrypted feed from the hospital. All communications through the Web interface, such as for administration or the patient’s use, would be secured with encryption. A Business Associate Agreement is needed and is in effect for this relationship. Flow 10: Patient Portal - Cloud-Based Server Service Relationship The patient portal provider contracts with the cloud server provider for the purposes of off site hosting of the portal application. Although the portal provider develops the portal application and database components, the provider does not have their own data center for hosting services. The cloud server provider offers a solution to this by hosting the portal application without the need for the portal provider to invest in their own data center. This arrangement is favorable to the portal provider, who is a smaller company that focuses on this niche service. Billing is done similar to a utility bill, there are only charges when the services are utilized, and the portal knows the average usage per patient that is enrolled and has a billing plan to charge the hospital accordingly.
6
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
All data that is provided to the patient portal is stored on the cloud server’s systems. Neither entities in this relationship are covered entities, however the portal provider is bound by the Business Associate Agreement that it signed with the hospital, and further establishes with the cloud server provider a Non-Disclosure Agreement (NDA) and security requirements for the data that is stored on the cloud server provider’s systems. Flow 11: Research Affiliates - Software Vendor Relationship The research affiliates of Hospital ABC include other research hospitals similar in size and scope to Hospital ABC. There is an estimated 125 research hospitals and universities that are affiliated with Hospital ABC that have similar clinical systems. With the specialization of healthcare software and lack of vendors providing solutions, many other research organizations share the same clinical software vendors as Hospital ABC. Although not confirmed, a conservative estimate is that for each software vendor providing services to Hospital ABC, 25% of Hospital ABC’s research affiliates will use the same vendor. Under HIPAA, the research affiliate would be required to establish a BAA with the software vendor for this type of relationship. Flow 12: Dictation Service - Software Vendor Relationship Similar to the situation where the research affiliate shared the same software vendor as Hospital ABC, it is even more likely that the dictation vendor will share the same vendors with every hospital it does business with. The reason is that the vendor must interface with the Hospital ABC’s systems to update the EMR with the transcribed dictations. While some dictation providers may offer an HL7 feed into the hospital’s EMR, there is a strong likelihood that dictation providers will have the same types of systems as the hospital. This relationship scenario between dictation service and software vendor would likely include support, in which case the software vendor will have access to the EMR located at the dictation service. Neither of the entities in this relationship are covered entities, however the dictation provider would be bound by the BAA established with the hospital to ensure that there is an appropriate contract between the dictation provider and software vendor establishing appropriate security measures. A standard Non-Disclosure Agreement is the likely contract. Flow 13: Insurance - Cloud-Based Server Service Relationship The insurance provider contracts with the cloud-based service provider to outsource a portion of its IT infrastructure. The insurance company has found that it is more economical to put its resource-intensive databases into the cloud provider’s systems, where it has a higher degree of availability than it would if managed by the insurance company’s IT staff. The insurance company would require that the cloud server service provider sign a Business Associate Agreement under HIPAA.
Flow 14: Research Affiliates - Cloud-Based Server Service Relationship The research affiliates of Hospital ABC include other research organizations that have similar demands for resource intensive computing power. In such cases, these research institutions will contract with a cloud-based server service in a similar relationship that Hospital ABC has with its cloud-based server service providers. Because there is patient data stored on the cloud server provider’s systems, a Business Associate Agreement is needed and is in effect. Flow 15: Dictation Service - Cloud-Based Email Service Relationship Dictation services are a commodity item, with many small providers in this market. Companies of this size do not have a sophisticated IT infrastructure of their own, and maintaining a mail system is in itself an application that requires a high-degree of availability. If the mail server is not operational, mail simply does not get delivered and the dictation provider would suffer the impact of a missed or severely delayed email message. Furthermore, it may be a case where the dictation provider has subcontractors working on the transcribing work, and representing themselves as the dictation provider. A cloud-based email solution would work well in this case, as the dictation provider simply enables a web-based account for the subcontractor. To avoid this, a smaller dictation service may simply use an outsourced mail provider for email and calendaring services. This would allow the dictation provider to have their own company branded domain name, while outsourcing the entire technical function off to the cloud email provider. Neither of the entities in this relationship are covered entities, however the dictation provider would be bound by the BAA established with Hospital ABC to ensure that there is an appropriate contract between the dictation provider and cloud email provider establishing appropriate security measures. A standard Non-Disclosure Agreement is the likely contract. Flow 16: Collection Agencies - Cloud-Based Email Service Relationship The collection agencies are in a similar situation as the dictation services. The collection agency operates by buying outstanding debt, and then having agents contact the patient in an effort to collect on the debt. Hospital ABC deals with many smaller collection agencies that are using services such as Gmail or Yahoo webmail to communicate with Hospital ABC. This appears to be due to the fact that the collection agency will typical follow a decentralized structure with agents working remotely, possibly as private subcontractors. This model would not require the agency to procure office space for the agents. Email services, like office space, is an investment similar to office space that can be done away with simply by utilizing cloud email services. As with the previous data flow, neither of the entities in this relationship are covered entities. The collection agency is bound by the BAA established with Hospital ABC to ensure
7
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
that there is an appropriate contract, such as a standard NonDisclosure Agreement, is in place to provide for adequate security. Flow 17: Outsourced Billing - Cloud-Based Email Service Relationship The outsourced billing providers with relationships with Hospital ABC outsources its mail function to the cloudbased email provider. This service allows the outsourced billing staff to access their mail from any Internet-connected computer through the cloud-based system. This removes the requirement for the billing provider to maintain its own email system, and provides more reliability than if the service was managed internally. The outsourced billing providers with relationships with Hospital ABC both use cloud-based email services. This may expose any information that may be communicated with Hospital ABC for the normal course of conducting billing operations. The billing provider has signed a business associate agreement with the hospital, and would be required to establish that the cloud email service maintains the appropriate security controls through a non-disclosure agreement. Flow 18: Outsourced Billing - Cloud-Based Server Service Relationship The electronic-based billing provider offers Hospital ABC a service allowing patients to pay their bills online. The billing provider must have maximum availability for the billing application to allow for patients to pay their bills electronically. A cloud-based server service would offer the availability that the outsourced billing provider needs, and could potentially do it cheaper and more reliably than the billing provider can do for themselves. The information stored on the cloud-based server provider would be the information contained within the outsourced billing provider’s application. The billing provider is bound by the business associate agreement to ensure that the cloud-based server service has the appropriate security controls enabled. This would likely be through the use of a non-disclosure agreement. Flow 19: Patient Portal - Cloud-Based Email Service Relationship The patient portal provider outsources its email systems to the cloud-based email service provider. The portal provider has a smaller staff, a significant portion of which are application developers. The developers often work from home, and a web-based email system allows them to access their corporate mail without using the VPN. Furthermore, the portal provider has already deployed their application into the cloud see (Flow 10), so the notion of outsourcing a core service is not a new one. The patient portal provider is bound by a Business Associate Agreement to ensure that the cloud email service provider has implemented the adequate security measures, and has done so with a standard non-disclosure agreement.
III. CASE DISCUSSION The case study from the perspective of one hospital demonstrates the complexity of relations different partners maintain within the healthcare system. Just one hospital exchanges sensitive data with approximately 500 external entities—more than half are research affiliates that are being provided with a limited data set. More important are the types of identified data flows. Approximately 30% of all entities (Figure 1) receive more than one non-redundant data flow from multiple sources that in turn have received data from other sources. This increases the risk of data aggregation possibly leading to a complete patient data set. This type of relationship is referred to as n:m - transitive relationship [25]5 . An n:m - transitive relationship is one where multiple entities that represent organizations of a network exchange information with multiple others over several steps in the value chain. For example, patient data that are sent from the hospital to the research affiliates may end up in the possession of a software vendor, who also receives patient data from dictation services. This software vendor may be able to match patient data provided from the research affiliate with those data provided from the dictation service and derive much more information than anyone intended the software vendor to have. Aside from n:m - transitive relationships, the work in [25] distinguishes three additional categories of relationships: (1) 1:1 - non-transitive relationships, (2) 1:1 - transitive relationships, and (3) n:m - non-transitive relationships. In this categorization, transitive means that there is a hierarchical structure of relationships. Flow 1 in Figure 1 is a 1:1 non-transitive relationship. Yet, the relationships between Hospital ABC and the entities Software Vendor, Cloud-based Email Service, and Cloud-based Server Service are all n:m - transitive relationships. Obviously, the n:m - transitive relationship (i.e., a chain of many-to-many relationships) is the most general case. In turn, it also bears the highest risk in that it may enable some partners to infer and aggregate information that is not typically intended for them and that they would not be able to obtain if the relationship was non-transitive or one-to-one only. It is widely accepted that cloud services pose major security and privacy risks [30]. However, in addition our study identifies the potential for transitive data leakage–especially as more and more data and services are handled through cloud technology. Yet, even more concerning are the software vendors as a location for potential information leakage. This is due to the sheer number of software vendors and the multiple applications they offer. For example, consider Hospital ABC conducting a research study with two other research affiliates. Hospital ABC uses Software Vendor X to provide their laboratory information system , Research 5 The general notion of n:m relationships is widely used in the context of database systems. The relational model was first introduced in the seminal work by Codd [29].
8
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
Affiliate A uses Vendor X to provide their PACS, and Research Affiliate B uses software Vendor X for their OMS. The hospital and both vendors send their data to Software Vendor X as part of their support agreements. Software Vendor X now has the capabilities to now deduce a more complete data set than it received from any one of the three entities. Further complicating this scenario is the case where several hospitals have data on the same patient and provide to Vendor X, what they believe, are limited data sets thus allowing for downstream aggregation of data. This scenario demonstrates that with that there is a strong correlation between increased system complexities and increased risks of transitive information leakage. As organizations measure the risk [31] of sharing data, they provide their partner with a data set appropriate to the level of inherent risk. Risky scenarios would call for a more limited data set to be shared. Introduction of n:m - transitive relationships imposes risk to these relationships and creates a situation with more residual risk than most organizations would perceive or be able to measure today [32]. The n:m - transitive relations increase the risk of unintended disclosure. It is important to note that these risks cannot simply be controlled by regulating the amount of information exchanged between entities or using techniques for masking or anonymization data, e.g., through kanonymization (cf. [33], [34]). This is due to the fact that in general the flows are required to maintain certain services provided by these outside entities. For example, a provider for outsourced billing will not be able to render services based on k-anonymized data. Furthermore, while anonymization or masking techniques may be effective means to protect some data flows for a single, non-transitive relationship, considering these flows in the global context of multiple levels may lead to unintended information leakages as various anonymized (possibly done in multiple ways and at varying extend for different flows) and non-anonymized data flows may be aggregated. Specifically, transitive relationships may arise as entities establish their own relationships to enhance their own processes. Today, systemic analysis of networks do encounter specific non-transitive information threats but they do not consider the case of non-malicious transitive information leakages. It also extends to common models such as the McCumber Infosec model and its generalization due to Machonachy et al. [35], [36] to a model for Information Assurance (IA). While the latter includes a time component and as such allows the accounting for change, considerations generally focus on individual points in time rather than across a period of time. In addition, in order to account for n:m - transitive relationships it would also be necessary to introduce some form of “parallelism”, i.e., the considering of the multiple dimensions of the Machonachy et al. IA model for all entities in the network. And, as will be argued in the sequel, any risk assessment will not be viable without including the economic perspective.
IV. CONCLUSIONS AND OUTLOOK The main conclusion of this case analysis is that threats do not only exist on individual partner levels but are inherent to the structure of the overall system; i.e., threats on the systems level are larger than the sum of the threats on the individual levels. The identified n:m - transitive information relations between different healthcare partners posing systemic information security threats cannot simply be controlled by regulations. The problem is that transitive information leakages could occur even if all authorized partners conform to all existing regulations. Entities that take part in a system including inherent n:m - transitive relationships face more risks of information leakages as they may not realize that other players on the network have the ability to aggregate information with other sources leading to a potential unintended data breach. Consequently, organizations that cannot be held liable for incidents will not necessarily invest in security controls [37]. Another consequence of n:m - transitive information relations is that investments in security technologies focused on the individual entity level and not on the systems level are not effective in achieving higher levels of information security. So far, only the technical perspective of n:m - transitive information leakages was discussed. Yet, the economic aspects of transitive information leakages lead to another set of interesting questions that need to be addressed in future research. Partners within a healthcare network are under a high economic pressure and need to provide partners with as much information as possible to allow for an efficient implementation of tasks without major delays caused by, e.g., authorization policies. Attempts on restricting the entities’ data flows with the intention of mitigating unintended information leakages will be undoubtedly met with economic pressure in the form of productivity. For example, an entity that handles outsourced billing functions needs the customer’s name in order to operate efficiently. If they are given anything less, the business process will experience a negative impact in terms of productivity. When forced to decide between security or productivity related to patient treatment, a clinical user will always do whatever is the right thing for the patient even if it is in violation of the security policy. Yet, the notion of productivity is an important aspect to consider when building any system or process. As such, this interplay poses important challenges for future research. Further analysis of networks are needed to better understand the conditions for the tradeoffs network partners are facing in deciding whether or not to comply with security protocols. It is very likely that general security policies will not be followed by some partners of a network leading to an increase in transitional information risks. A productivity analysis is necessary to understand the role of data for each partner and to answer the question of how policies should be constituted to be effective. Another question revolves around the structure of the network. How does a partner’s position in the network affect
9
Proceedings of the 44th Hawaii International Conference on System Sciences - 2011
the definition and implementation of information security policies. A monopolist in a network could dominate the security standard that might not be optimal for the remaining network entities to carry out their activities in an economically viable and secure fashion. Under these conditions, policies might not be followed by all indirect partners. This case study of a specific system of healthcare providers reveals several limitations for achieving higher levels of information security. In particular, the identified n:m - transitive relations are posing an overseen but important new security threat to be considered by further research and future regulations.
[1] [2] [3] [4] [5]
[6]
[7]
[8]
[9] [10] [11] [12] [13] [14] [15] [16] [17] [18]
[19]
[20] “Ponemon Study Shows the Cost of a Data Breach Continues to Increase,,” 2010, http://www.ponemon.org/news-2/23. [21] D. Fluckinger, “Health Care Data Breach Can Hurt Provicers Wallet and Its Image,” 2010, http://searchhealthit.techtarget.com/news/2240016641/ Health-care-data-breach-can-hurt-providers-wallet-and-its-image. [22] “2009 HIMSS Security Survey,” 2009, http://www.himss.org/content/ files/HIMSS2009SecuritySurveyReport.pdf. [23] Gartner, “Gartner Research: 2010 Update: What Organizations are Spending on IT Security, March 26, 2010, ID G00175257,” 2010. [24] N. Versel, “Health IT Pros Warn of Network Vulnerabilities During Cyber War”,” 2009, http://www.fiercehealthit.com/story/ health-it-pros-warn-network-vulnerabilities-during-cyberwar/ 2009-11-23. [25] T. Lechler and S. Wetzel, “Transitive Inter-Organizational Network Structures: A Potential Source for Semi-Honest Information Leakage and its Economic Implications,” 2010, Technical Report CS-2010-2, R EFERENCES Stevens Institute of Technology. [26] N. D. of Health, “Form DOH-389,” “The Health Information Technology for Economic and Clinical http://www.health.state.ny.us/forms/doh-389.pdf, http://www.health. Health Act (HITECH) Act of 2009,” http://www.impac.com/pdf zip/ state.ny.us/forms/doh-389.pdf. The\%20Stimulus\%20Act\%20of\%202009.pdf. [27] Google, “Google Postini Services,” 2010, http://www.google.com/ “The Health Insurance Portability and Accountability Act (HIPAA) of postini/. 1996,” 2010, http://www.hhs.gov/ocr/privacy/. [28] D. Lazarus, “A Tough Lesson on Medical Privacy - Pakistani TranA. Appari and M. E. Johnson, “Information Security and Privacy scriber Threatens UCSF Over Back Pay,” San Francisco Chronicle, in Healthcare: Current State of Research,” 2008, http://www.ists. 2003. dartmouth.edu/library/416.pdf. [29] E. F. Codd, “A Relational Model of Data for Large Shared Data “Breaches Affecting 500 or More Individuals,” 2010, http://www. Banks,” Commun. ACM, vol. 13, no. 6, pp. 377–387, 1970. hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/ [30] L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner, postedbreaches.html. “A Break in the Clouds: Towards a Cloud Definition,” SIGCOMM “Security Breach: Mailing Machine Wreaks Havoc at New Comput. Commun. Rev., vol. 39, no. 1, pp. 50–55, 2009. York Hospital,” 2010, http://www.fiercehealthfinance.com/story/ [31] Y. Asnar and N. Zannone, “Perceived Risk Assessment,” in QoP security-breach-mailing-machine-wreaks-billing-havoc-ny-hospital/ ’08: Proceedings of the 4th ACM Workshop on Quality of Protection. 2010-05-24. ACM, 2008, pp. 59–64. “GA Hospital Data Breach Due to Outsourc[32] L. A. Jackson and W. Al-Hamdani, “Economic Acceptable Risk ing Error,” 2008, http://www.fiercehealthit.com/story/ Assessment Model,” in InfoSecCD ’08: Proceedings of the 5th Annual ga-hospital-health-data-breach-due-outsourcing-error/2008-09-28? Conference on Information Security Curriculum Development. ACM, utm medium=rss&utm source=rss&cmp-id=OTC-RSS-FHI0. 2008, pp. 36–39. N. Versel, “Hackers, Peer-to-Peer Networks, Hu[33] V. Ciriani, S. De, C. Vimercati, S. Foresti, and P. Samarati, “Chapter 1 man Error All Threaten Health Data SecuK-Anonymous Data Mining: A Survey,” in Secure Data Management rity,” 2010, http://www.fiercehealthit.com/story/ in Decentralized Systems. Springer, 2007, pp. 1–34. hackers-peer-peer-networks-human-error-all-threaten-health-data-security/[34] C. C. Aggarwal and P. S. Yu, Privacy-Preserving Data Mining: Models 2010-05-24. and Algorithms. Springer, 2008. A. Zieger, “Study: Peer-to-Peer File Sharing Apps Can [35] J. McCumber, “Information Systems Security: A Comprehensive Expose Medical Data,” 2009, http://www.fiercehealthit.com/ Model,” in Proceedings of the 14th National Computer Security story/study-peer-peer-file-sharing-apps-can-expose-medical-data/ Conference. National Institute of Standards and Technology, 1991. 2009-03-01. [36] W. V. Machonachy, C. D. Schou, D. Ragsdale, and D. Welch, “VA Suffers Major Data Loss, Again,” 2007, http://www.fiercehealthit. “A Model for Information Assurance: An Integrated Approach,” in com/story/va-suffers-major-data-loss-again/2007-02-20. Proceedings of the 2001 IEEE Workshop on Information Assurance C. Davis, “Patient Data Is At Risk: Do You Call and Security, United States Military Academy, West Point. IEEE, IT?” 2010, http://www.fiercehealthfinance.com/story/ 2001, pp. 306–310. patient-data-risk-what-will-you-do/2010-04-21. [37] R. Anderson, “Why Information Security is Hard-An Economic Per“2010 HIMSS Analytics Report: Security of Patient spective,” in ACSAC ’01: Proceedings of the 17th Annual Computer Data,” 2010, http://www.krollfraudsolutions.com/about-kroll/ Security Applications Conference. IEEE Computer Society, 2001, p. HIMSS-Security-Patient-Data.aspx. 358. E. Mills, “FTC Warns 100 Organizations About Leaked Data Via P2P,” 2010, http://news.cnet.com/8301-27080 3-10457932-245.html. “The Breach Blog,” 2010, http://www.breachblog.com/. “Verizon Data Breach Investigations Report,” 2009, http://www. verizonbusiness.com/resources/security/reports/2009 databreach rp. pdf. “The State of Healthcare Privacy in the U.S.” 2010, http://www. fairwarningaudit.com/subpages/healthcare-privacy-survey-2010.asp. A. Lipowicz, “Hospitals Face Compliance Problems with HITECH Act,” 2010, http://washingtontechnology.com/articles/2010/02/18/ hitech-act-hospitals-compliance-difficulties.aspx. K. Prince, “Health Care Data Security Breaches in the U.S,” 2008, http://www.scmagazineus.com/ health-care-data-security-breaches-in-the-us/article/120069/. G. Helmer, “Ponemon Study Finds Average Cost of Data Breach Was $3.4 million in 2009,” 2010, http://www.securityprivacyandthelaw. com/2010/05/articles/cybersecurity-cybercrime/ ponemon-study-finds-average-cost-of-data-breach-was-34-million-in-2009/. “2009 Annual Study: Global Cost of a Data Breach,” 2010, http://www.securityprivacyandthelaw.com/uploads/file/ Ponemon COB 2009 GL.pdf.
10
