JOnline: Using Systems Engineering to Aid in HIPAA Compliancy 

 
Download Article

The International Council on Systems Engineering (INCOSE) defines systems engineering as “an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.”1 Systems engineering has been used throughout history dating back to water distribution centers and the Roman highway systems. In modern history, governments have increasingly turned to systems engineering for their complex, multidisciplined, interconnected projects.

HIPAA

In History and Overview of HIPAA, author R.Z. Owen describes how the administration of former US President George H.W. Bush called a group of healthcare industry leaders together in the early 1990s to discuss how healthcare (in the US government’s case, Medicare) administrative costs could be reduced.2 Given the significant data exchange in the healthcare industry, such as insurance enrollment, eligibility and claims information, medial treatment data (including prescription and laboratory results), and billing information, it was determined that significant savings could be achieved by increasing the use of electronic data interchange (EDI) within the industry. EDI is defined as computer-to-computer electronic transmission of intra-industry business information.

An advisory panel was formed and eventually recommended that federal legislation be passed to ensure that a consistent set of standards could be used across all states. While there are several sections to this legislation, the administrative simplification section of the Health Insurance Portability and Accountability Act (HIPAA) is the pertinent area for this discussion.

The administrative simplification section mandates the use of specific electronic formats and specifies which administrative and medical coding schemes can be used within those formats. At the same time, the US Congress recognized that encouraging the use of electronic means to pay and collect claims data increased the potential for abuse of people’s medical information. Therefore, key parts of HIPAA also increase and standardize methods to ensure the confidentiality and security of health data. HIPAA privacy regulations require that access to patient information be limited to only those authorized and that only the information necessary for a task be available to them. HIPAA security regulations set standards to protect electronic health information systems from improper access or alteration.

Healthcare

Hospitals are the most complex of health service organizations. According to S.L. Carter and T.G. Gill, they are “characterized by a complicated organizational structure, an extensive division of labor, and an elaborate system of coordination of tasks, functions, and social interaction.”3 Many departments, including emergency services, admitting, billing, nutritional services, surgical services, imaging services, laboratory and maternity services interoperate to provide services. However, the typical hospital business structure has each department operating as an independent business unit. To make the situation even more complex, there is no standard hospital organization, because each hospital reflects its community needs, with most of the existing organizational designs dating back to the pretechnology times of the 1950s.4

A study of the Bethesda Healthcare System (Maryland, USA) notes that one major challenge to management is that most hospitals typically have little control over doctors. Due to the traditional business arrangement of doctors as independent business operators, doctors are not employees of the hospital— they come in only to use the services. At the same time, doctors are the primary users of the hospital’s systems. If the requirements the hospital places on them are too burdensome, as customers they are free to seek services elsewhere. Because of this independence, hospital decisions are often shared between hospital administration and doctors’ groups.5

Information Systems and the Healthcare Industry

From the 1970s to the mid-1990s, hospitals increased their IT use from practically nothing to a broad range of systems covering financial information, clinical decision support, medical electronic imaging and computer-assisted care. However, these systems worked independently without integration between the administrative and clinical areas.

The Advent of the CDR

An approach used to achieve such integration was the development of clinical data repositories (CDR). A CDR is typically a relational database that consolidates data from a variety of clinical sources to present a unified view of a single patient. The patient record usually contains patient location, prescribed medications, time of last medication administration and dietary needs. Other database feeds can include laboratory results, EKG readouts, pharmacy orders and radiology reports. Preliminary CDRs included only this clinical data, but new CDRs include other administrative data to include patient demographics, billing and insurance data feeds.

Protecting electronic medical records requires more effort than simply locking file cabinets. The confidentiality, integrity and availability (CIA) of a CDR must be addressed through access control, data integrity checks and procedures to build in redundancy and resiliency. These complex relational databases with decision support have added a new dimension of technological complexity to already complex patient care work flows.

Cultural Challenges

Doctors, nurses and other clinical care workers have proven resistant to technological change within the healthcare arena. An article titled “I.T. Often a Tough Sell to Nursing Staffs” notes that “nurses already are under a lot of pressure to change work processes to improve care delivery, and many simply don’t have time to learn about computers.”6

In some cases, such resistance stems from general discomfort with information technology. Resistance to change also plays an important role. “More often, however, it [resistance] was a result of new systems requiring that changes be made in the ways they [doctors] have traditionally recorded, retrieved, and utilized clinical data.”7 The issue of appearing competent has also proved a barrier. According to L.A. Runy, “The need to be perceived as competent health care professionals also plays a role in the adoption and use of new technologies…. Clinicians fear they’ll look inexperienced and incompetent when they’re learning new technology.”8

As stated previously, since doctors are not employees of the hospital organizations and do not share administrative leadership, they cannot be forced to adopt new technologies. Physicians in this case are customers of the hospitals and, in large metropolitan areas, have a choice as to where they refer their patients for inpatient services.

In the past, the tendency has been for technology services to plan technological development and clinical workers to develop clinical solutions independently. The need is to “match the characteristics of the technology with the characteristics of the users rather than attempt to change the attitudes, mental models, alliances or culture of the users.”9 A system where users are the primary drivers of the planning process would appear to be useful.

Healthcare Information Management Challenges

Healthcare workflow processes in hospitals were, in many cases, designed and implemented decades ago when the hospitals were initially built. Many are incompatible with present-day technology and regulatory requirements. For example, the logging in and out of a workstation proves problematic for healthcare providers needing quick access to health records. The resulting workflow has been to use generic accounts to log into the workstations. As healthcare organizations grew, these processes have been carried over incrementally, resulting in a “patchwork approach to solving workflow issues.”10

HIPAA was initially designed to provide employees with portability of their health insurance from one employer to the next without loss of coverage. Along the way, items such as privacy, security, electronic transactions and standard code sets were added.11 This regulation and others are among many other problems facing healthcare organizations. They do, however, serve as a good example of the structural and cultural problems that reduce efficiency and safe patient care. Many organizations are struggling with the existing legacy/patchwork systems, increased regulatory oversight, patient demands for efficient and inexpensive care, and cultural resistance to technology in clinical workers. Health organizations are faced with the following question: How does one integrate existing systems, requirements and customer needs into a comprehensive security model while maintaining patient care?

Analysis of Systems Engineering

INCOSE’s definition of systems engineering also states:

Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.12

The systems engineering process appears to have many benefits for healthcare information management and HIPAA compliance. HIPAA requires a methodology to be applied to security decisions and design. Systems engineering provides such a basis, in addition to guidance on defining user requirements and gaining user acceptance. Each principle will be examined for its applicability.

Iterative Top-down Design

A complex system (such as healthcare operations) is designed or analyzed by breaking each system down. Each component is analyzed for functional capability and subcomponents. This process is continued on each subcomponent until subcomponents are eventually broken into objects or users.

Figure 1 demonstrates the complexity of high-level information flow within a typical healthcare organization. Looking at this complexity from the inside does not lead to a complete understanding of the relationships and interdependencies. An iterative top-down approach allows an examination to start with the organization as a whole—with an exam of each system and user encountered until the single component level is reached.

Figure 1 - Provider and Payer Enterprise System 

This is extremely valuable in the health information management (HIM) environment. Patchwork approaches have led to interconnection failures and security weakness between vendor-provided solutions. A top-down approach allows for analysis of the complex, departmentalized, yet interdependent activities that occur. This sets the stage for defining the unique requirements for each healthcare organization.

Bottom-up Integration

Systems are built by taking the lowest-level components and putting them together one level at a time. Between each level’s assembly, the functional components are analyzed for compliance to the stated requirements. In reality, bottom-up integration is top-down design in reverse.

Bottom-up integration for HIPAA compliance should start with role engineering/analysis. Role engineering for rolebased access control (RBAC) is the process of defining roles, permissions, role hierarchies and constraints, and assigning the permissions to the roles.

The requirement for RBAC in HIPAA stems from the HIPAA privacy rule’s “minimum necessary” standards. The standards state that healthcare organizations must disclose only the minimum amount of information required to accomplish an intended purpose. RBAC grants rights and permissions to roles rather than individual users. Users then acquire the rights and permissions by being assigned to appropriate roles. By grouping individuals with other individuals having similar access rights, RBAC can provide significant security management efficiencies.

Workflow analysis is an important product of bottom-up integration. Most information systems are designed or acquired to replace an existing system. Little analysis is given to the work processes that are to be enhanced by the system.14 A bottom-up approach analyzing the contribution of the system or subsystem to the stated requirements eliminates repetition and waste.

System Life Cycle

A life cycle is simply an understanding of the progression of a system from inception to design to implementation, operation and maintenance, and eventually to its shutdown, disassembly and disposal.15

It is useful to define the difference between life cycle design and the normal sense of design. According to B.S. Blanchard and W.J. Fabrycky, “Life cycle design is responsive to customer needs and to desired life cycle outcomes (business needs).”16 Figure 2 demonstrates how system life cycle design is applied to healthcare information systems technology, with an emphasis on HIPAA compliance.

Figure 2 - HIPAA System Configuration Life Cycle Management

Utilizing system life cycle management enables the organization to practice risk assessment and management through organizational-level oversight and control. Risk assessment and management are required components of the HIPAA security rule, which states:

Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity…. Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.18

This requirement has been troublesome to healthcare organizations to define and practice. Given healthcare’s silo department structure, risk decisions are often made at levels that do not adequately understand the threats involved. A topdown look is essential for proper risk assessment and management. In systems engineering, risk management is simply an integral part of systems life cycle management. The systems life cycle approach gives form to the many oversight activities that must be accomplished for regulatory compliance.

User Perspective

One source gives an excellent definition of a user perspective:

Systems engineering attempts to build systems that take into account what the user wants, needs, prefers, is happy with and can use. Every type of user of a potential system (operator, maintainer, management, etc.) must be involved in the design of that system.19

The user perspective is perhaps the most important contribution that systems engineering can bring to the healthcare compliance struggle. As discussed previously, there is a general discomfort with information technology among a great number of healthcare providers. Also, because of management and labor relationships, most providers cannot be simply “ordered” to adopt a new technology. Only through persuasion and involvement can doctors and other caregivers be motivated to make the required changes in technology and/or procedure.

Systems engineering solves this problem through the technology acceptance model (TAM). The purpose of the TAM is to understand the relationship among attitudes, intentions and behavior of potential IT users. In most conditions, users will report that they will use technology if they believe the IT system will help them accomplish their tasks and be easy to use.

Many information security personnel have jumped into the healthcare industry, rightfully sensing that, with the HIPAA security rule implementation on the horizon, there will be a need for them. Many meet with conflict within the organizations. These security personnel have fallen into the trap of violating the user perspective principle: the system engineer does not create the design. The system engineer creates a description of design parameters. A common mistake made when specifying security requirements is to fail to adequately consider how a component interacts with its environment and other components in the system.

User perspective and participation address these conflict issues. Figure 3 demonstrates the criticality of defining the user need in the design.

Figure 3 - Describing the System

All system development should start with a clear statement of need from the user’s perspective. With iterative top-down design and bottom-up integration, user perspective is needed for definitions for behavior, structure and effectiveness. While the security and privacy requirements are components of the system behavior, structure and effectiveness and are required by regulation, they cannot be implemented without user need being taken into account.

Conclusion

Healthcare has made the move from a paper-based system to an electronic system. Providers that have not made the change, will. The facts are based in economic reality. It is cheaper in the long run for the insurance payers and healthcare providers to conduct business electronically, necessitating electronic billing and patient records.

The HIPAA privacy rule became effective in April 2003, and the security rule followed in April 2004. Healthcare organizations have been pulled in every direction to spend money on “the only HIPAA compliance solution they will ever need.” Vendors claim that their product or method is “HIPAA-compliant.” The problem is that a system may or may not be HIPAA-compliant based on the needs and risk profile of the target organization.

The complexity, interoperability and technological growth point of the organizations and their systems mean that no single product or method will solve compliancy issues. Solutions that work for one provider will not necessarily work for others due to unique characteristics that hospitals develop to serve their markets.

Using systems engineering to look at the overall IT and HIM environments provides a means of meeting the HIPAA regulatory requirements while at the same time taking into account the unique requirements and specifications of healthcare operations. Healthcare operations can be fully evaluated only when the focus is on the system as a whole. According to M.W. Maier and E. Rechtin, “At the most fundamental level, systems are collections of things which produce results unachievable by the elements alone.”21 Modern healthcare is a system-produced result that could not take place without the interrelationships among its elements. It is with this definition that the value of a systems engineering approach to healthcare becomes clear.

Endnotes

1 International Council on Systems Engineering, “What Is Systems Engineering?,” 2006, www.incose.org/practice/whatissystemseng.aspx

2 Owen, R.Z.; History and Overview of HIPAA, Hawaii Medical Service Association, 2000, www.hipaadvisory.com/regs/hipaahistorybyzon.htm

3 Carter, S.L.; T.G. Gill; “Bethesda Healthcare Systems: Physician Information System,” International Conference on Information Systems, 1999, Charlotte, North Carolina, USA, p. 663-678

4 Bangert, D.; R. Doktor; “The Role of Organizational Culture in the Management of Clinical E-health Systems,” proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03), IEEE, 2002

5 Op. cit., Carter

6 Gillespie, G.; “I.T. Often a Tough Sell to Nursing Staffs,” Health Data Management, April 2002, www.healthdatamanagement.com/html/current/CurrentIssueStory.cfm?PostID=11369

7 Anderson, James G.; “Clearing the Way for Physicians’ Use of Clinical Information Systems,” Communications of the ACM, vol. 40, issue 8, 7 August 1997, p 83-90

8 Runy, L.A.; “The Nurse, the Physician and IT,” Hospital and Health Networks, December 2003, www.hospitalconnect.com/hhnmag/jsp/articledisplay.jsp?dc rpath=AHA/PubsNewsArticle/data/031202HHN_Online_Runy&domain=HHNMAG

9 Op. cit., Bangert

10 Dhaliwal, J.S.; R. Ramlochan; K.J. Heng; C.M. Khoong; H.S. Wong; “Using Enterprise Modeling to Reengineer Healthcare Processes,” SIGGROUP Bulletin, vol. 18, no. 1, April 1997, p. 51-53

11 Kurtz, Gary; “EMR Confidentiality and Information Security,” Journal of Healthcare Information Management, vol. 17, no. 3, 1999, p. 41-49

12 Op. cit., Internatinal Council on Systems Engineering, 2006

13 Beach, J.; M.D. Hester; “Operational Impacts of Administration Simplification,” proceedings from HIPAAWest Summit, June 2001, www.ehcca.com/presentations/HIPAAWest2/1_06.pdf

14 Wagner, S.C.; A. Chaudhury; R.H. Rao; G.L. Sanders; “A Workflow Perspective of Information Systems Development,” proceedings of the Association for Information Systems Conference, Pittsburgh, Pennsylvania, (USA), August 1995

15 International Council on Systems Engineering, “What Is Systems Engineering?,” 1999, www.incose.org/sfbac/welcome/what-se.pdf

16 Blanchard, B.S.; W.J. Fabrycky; Systems Engineering and Analysis, 3rd Edition, Prentice Hall, New Jersey, USA, 1998

17 Dalton, M.; “Ensuring Life Cycle Supportability through the Application of Systems Engineering Processes,” proceedings from 3rd Annual Systems Engineering & Supportability Conference, 23-26 October 2000, www.dtic.mil/ndia/systems/Dalton.pdf

18 Federal Register, Health Insurance Reform: Security Standards, 45 CFR Parts 160, 162, and 164, 20 February 2003, www.cms.hhs.gov/SecurityStandard/Downloads/securityfinalrule.pdf

19 Op. cit., International Council on Systems Engineering, 1999

20 Lanham, C.; “Making a Great Gumbo,” Process Heating, October 2002, www.processheating.com/CDA/ArticleInformation/features/BNP__Features__Item/0,3156, 8 4919,00.html

21 Maier, M.W.; E. Rechtin; The Art of Systems Architecting, 2nd Edition, CRC Press, USA, 2000

Michael Martel, CISSP, CPP
is the manager of information security services for MultiCare Health System, an employer with a workforce of more than 5,500. He is directly responsible for all information security issues of the organization and indirectly responsible for privacy issues. Martel also manages the Windows server team responsible for MultiCare’s LAN infrastructure. Prior to joining MultiCare, Martel served in the US Army Special Forces. During his military career, he worked in all areas of security, including intelligence operations, executive protection, site risk assessments, precious cargo recovery and information security.


Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by the ISACA. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of the Information Systems Audit and Control Association and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by the Information Systems Audit and Control Association Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.