Billing Compliance Assurance Architecture for Healthcare Industry (BCAHI)

Billing Compliance Assurance Architecture for Healthcare Industry (BCAHI) Syeda Uzma Gardazi 1,*, Arshad Ali Shahid 2 1 Student of FAST NUCES, Islamabad. 2 Prof & Head, Dept of CS, FAST NUCES, Islamabad. uzma.gardazi@gmail.com, arshad.ali@nu.edu.pk Abstract: Software companies must ensure that their products comply with standards and government laws. This paper aims at developing software-intensive systems architecture for the Healthcare Industry to meet Health Insurance Portability and Accountability Act (HIPAA), HITECH and Office of Inspector General (OIG) third party medical billing guidelines by proposing an architecture Billing Compliance Assurance Architecture for Healthcare Industry (BCAHI) using software engineering techniques. BCAHI can help the healthcare industry to ensure compliance with OIG 3rd party medical billing guidelines by including compliance components and explain their relationship using connectors at software architecture level. BCAHI will help companies to track compliance in the healthcare industry by leveraging BCAHI architecture. The architecture was evaluated through a case study from the healthcare industry. Keywords: Medical Billing, Compliance Assurance Architecture, Office of the Inspector General (OIG), Quality Attributes (QA) and Compliance Attributes (CA). Received: Sept 2010, Published: April 2011 *Corresponding Author: Syeda Uzma Gardazi, uzma.gardazi@gmail.com 1. Introduction It is essential that Medical Billing and audit work together in an organization to be sure that they have controls in place to mitigate internal and external risks associated with medical billing. Billing professionals can readily understand that the Billing compliance audit is the process of collecting and evaluating evidence to determine whether a billing process is compliant with OIG billing guidelines. Senior management and business managers should have concerns about medical billing compliance with applicable OIG and insurance guideline. Currently medical billing companies working in third world countries as backup office(s) e.g. Pakistan are facing problems to track compliance with international regulations and standards. This paper aims at proposing & validating BCAHI architecture and its various aspects that will ensure compliance with 16

Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry OIG guideline. HIPAA is a US law that ensures and support confidentiality, integrity and availability (CIA) of protected health information (PHI). HITECH law further explains the role of business associates to transform unsecure PHI to secure PHI and notification actions required in case of breach. OIG third party medical billing guidelines address all the relevant areas for billing compliance including, without limitation: education and training requirements; identification of risk areas for fraud, abuse and waste; integrity of the Company s data information system; resolution of ambiguities contained in the claim information provided to the Company by its clients; elimination of duplicate billing errors; appropriate response to overpayment; required documentation for specified billing; unbundling; maintenance of confidentiality of PHI; use of proper modifiers; encouragement of compliant activities; requirements of federal and state law; quality assurance of claim information; hiring and evaluation of employees; and record retention.the context of the validation will be limited to a case study at a medical billing and transcription company. This work will explain CA description and usage in software architecture to track compliance. This improvement can be attributed to the increased ability of the software industry to better understand international regulations and standard requirements for the security and privacy of health information. The first step will be to address the issues related to how the BCAHI will treat CA. The major research area is software architecture and sub-area is architecture for medical billing compliance. Process Model: The first study will be carried out on existing models. A process model will be proposed exclusively for BCAHI. Then the flow of the remaining research will be as follows: Notations: Notations play an important role in visual representation and designing of any software product. Valid notations will be designed for BCAHI and they will be a part of software engineering. Language: On the basis of notations proper modeling language will be defined having a formal semantics. BCAHI Architecture: Lastly a proper BCAHI architecture will be devised which will help to ensure medical billing compliance in accordance with OIG 3rd party medical guidelines, HIPAA security and privacy law and HITECH applicable to the medical industry. 2. Related work Health Insurance Portability and Accountability Act (HIPAA) ensures confidentiality, integrity and availability of protected health information (PHI). The covered entities under HIPAA should adopt recommended mechanisms to protect PHI being transmitted over the network [1]. A framework was proposed to ensure the email system compliance with the HITECH regulation. HITECH regulatory requirements were reviewed and prioritized. Based upon these requirements CA are identified. Reference model is being formulated based upon these CA. Next the architecture style is being selected. Based on reference model and selected architecture styles the reference architecture for Email Handler and Spam Filter (EHSF) has been formulated. Then EHSF architecture is devised. At last best encryption algorithm was suggested for email system in accordance with HITECH regulation [2]. Software architecture can be defined differently. Software 17

architecture is a structure represented using components and connectors to represent the relationship between components [3]. The authors identify software architecture usage and description in Pakistani Software Industry [4]. Compliance is being ensured with applicable regulatory requirements while the software is being engineered. Regulatory requirements are represented using different rules. A methodology was discussed to derive compliance [5]..Compliance with regulatory requirements must be ensured in the software being engineered. The regulations are described as rules to support and ensure software compliance with applicable regulatory requirements and obligations [6]. The authors identify the motivational factors that can motivate software architects to adopt regulatory compliant architecture. A generalized survey was done on Software Architects and Software Project Managers to identify the motivational factors that can affect them [7]. User Requirements Notation models of the HIC and privacy legislation was presented by authors to define compliance tracking using the proposed framework [8]. Pruning of log data represented as trees was suggested for automated audits. The authors demonstrated that the resultant method was more efficient than usual audit approaches [9].The authors suggested proposing a Software Architecture for Information Assurance (SARCHIA) that will help companies working as back office in developing countries to track compliance in the healthcare industry by leveraging SARCHIA framework and architecture [10]. This paper will attempt to provide an architecture named BCAHI that will facilitate the software industry dealing with medical billing information. In this paper we will transform the compliance requirements of the US medical billing system into software architecture. We will not focus in a particular software architectural style or notation, but we will focus on regulatory compliance part of the medical billing. This will be done using an ad-hoc language named Comp to represent components and connectors in software architecture BCHAI. BCAHI can be adopted by the healthcare industry in developing countries like Pakistan. 3. Formulation process for billing compliance architecture The main goal of this paper is to develop an architecture that intends to help medical billing companies working in third world countries as backup office(s) e.g. Pakistan to track compliance with international regulations and standards by adopting BCAHI. BCAHI will be a guideline for Pakistan s medical billing industry that may deal with US health care industry while working in Pakistan to develop and provide more effective and efficient notations that will analyze, visualize and construct applications used in the medical industry. The following contributions, related to the handling of compliance to OIG 3rd party medical billing guideline, HIPAA security and privacy law and HITECH regulations, are expected: Definition and identification of Compliance Attributes (CA). Exploration of notations e.g. ADLs to build a modeling language for BCAHI. Devising the BCAHI architecture. 18

Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry Methodology for evaluating BCAHI architecture. Evaluating BCAHI impact to make recommendations based on evaluation results Figure 1 explains the process to formulate BCAHI. Figure 1: Billing Compliance Architecture Formulation Process 4. A third party medical billing company as a case study A Healthcare IT Company (UHIC) is committed to complying with all controlling legal requirements. Such compliance is a foundational element of healthy and sustainable growth and essential to protecting company s interests and fulfilling its corporate mission. The Office of the Inspector General of the Department of Health and Human Services recommends that third-party medical billing companies adopt and implement billing compliance programs. Pakistani companies are not governed by U.S. laws but the companies who want to outsource a service, such as billing, require those third-parties to comply with the HIPAA. This is a unique and increasingly important issue in this domain. While the adoption of such plans is strictly voluntary, UHIC who outsource medical billing and transcription services, require its backup offices in Pakistan to comply with the HIPAA, HITECH, OIG guideline and AAMT guideline. UHIC office in Pakistan is so committed to excellence in medical billing, that it has devoted the time and resources necessary to crafting this Compliance Program. Below 19

mentioned diagram explains the UHIC s business process: A Healthcare IT Company Figure 2: UHIC s Business Process Provider may refer to healthcare provider/practice that may be referred as 'client' according to the company's service agreement. Providers often communicate special instructions to UHIC s employees by following methods: i) Instructions received telephonically or via Instant Messenger ii) iii) Instructions received via Secure Support Center or via E-mail Instructions received via instruction s module available at UHIC s website under the member area Following diagram shows the statistical analysis of special instructions (x-axis=type of instruction and y-axis=# of instructions) received from providers by UHIC: 300 250 200 150 100 50 0 No Show Charges Statistical Analysis of Special Instructions Received from Providers 285 72 95 Provider Fee 4 Participating and 81 71 Capitation 7 31 Workers 184 114 Coding 39 39 29 85 Balance out Codes to Adust in 25 148 Other Instructions 71 26 E-mail/Contact # of Instructions Reported Figure 3: Statistical Analysis of Special Instructions Received from Providers In order to streamline the process of implementing these special instructions and ensure 20

Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry clarity in their adherence, all departments/employees receiving the instructions from clients shall follow the procedure shown below: Figure 4: Receive Special Instructions from Provider Flow Chart 4.1 Extending requirements categorization for compliance with healthcare regulations Initially requirements were categorized as functional and non-functional requirements. In this section we will focus on a cross-section of all requirements (functional and nonfunctional) named as legal requirements. Legal requirements will explain the applicable regulatory and standards requirements needs. These requirements will help to identify the appropriate Compliance Attributes (CA) and its effect on software architecture for its compliance. Key compliance attribute (short, CA): any attribute of software which serves as a mean to describe applicable regulatory requirement and possibly to evaluate it. To handle these error systematically/manually architecture for Providers Special Instructions Generation, Verification and Implementation Module for Web and Management Information System (MIS) is discussed. 21

4.2 OIG Key Compliance Attributes Innocent billing errors and unintentional misconduct associated with billing activities can threatens any company s reputation and ability to do business. Therefore, all suspected errors and violations of the law are taken seriously and will be appropriately investigated to determine whether, in fact, there have been any errors or misconduct. R1: Bill the Medicare/Medicaid beneficiaries or commercial contracted payer patients for the difference between the total charges and the amount allowed by the payer. CA1: Balance Billing. R2: Bill the patient for which bankruptcy notification have been received. CA2: Bankruptcy. R3: Bill the patient xyz instead of patient abc. CA3: Billed to wrong patient. R4: Charge the patient def for the services not provided as claimed. CA4: Billing for items or services not rendered or not provided as claimed. R5: Bill CPT code 99213 service as if covered. CA5: billing for noncovered services as if covered R6: Adjust the negative balance for patient xyz. Failing to communicate to Billing Company s clients that refund requests have been received or that overpayments exist. CA6: Overpayment Adjustment. R7: Up-coding the level of service provided. CA7: Up-coding. R8: Double billing resulting in duplicate payment. CA8: duplicate or previously paid. R9: Bill the HMO beneficiaries or commercial contracted payer patients for the difference between the total charges and the amount allowed by the payer. CA9: Wrong billing of HMO patients. R10: Send PHI without encryption over the unsecured PHI, QA1: Security and CA9: Encryption. R11: Conveying information to payers or patients that in any manner differs from the information provided to UHIC, in writing, by the physician (e.g., changing place of service, date of service or procedure code), unless earlier instructions are superseded by subsequent written instructions. CA11: lack of integrity. R12: Billing for each component of the service instead of billing using an all-inclusive code CA12: Unbundling 4.3 Characteristics of Key Compliance attributes CA belongs to a specific domain and it is affected by applicable regulatory requirements. For different domains usual programming notations and data types are used. For CA different methods may be used including but not limited to: Real and integer value (CA can be quantitatively measured, as # of billing compliance issue), 22

Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry Boolean values (CA can result in true and false, as billing compliance issue recovery). Following are two types of CA: Basic (means that their values cannot be computed from others) and Drive (means that their values can be computed from others). A derived compliance attribute X will contain Y list of other compliance attributes that will determine values of X. 5. Examples In this section we will transform the compliance requirements into software components and connector using COMP language for UHIC case study. We will discuss following two compliance requirements for UHIC: Provider s special instruction compliance with OIG 3rd party medical billing guidelines and Minimization of overpayments to handle the provider s special instructions effectively. 5.1 Compliance It refers to maximizing the providers instructions compliance with OIG 3rd party medical guideline, HIPAA and HITECH requirements. This is CA concerning the compliance of provider instruction with applicable standard. This condition requirement is shown below: Maximize (compliance) For this a statistical analysis of issues reported to this medical billing company were analyzed. These issues were reported internally by employees or externally by providers, patients and others. Initially the issues were categorized in to eleven categories. Average complaint ratio details are mentioned below: Website-12% EMR-13% Networks-13% Billing-62% The average response time to resolve these complaints were 10 minutes. Then the issues were divided into following three categories: A billing compliance issue Not a billing compliance issue Issue not categorized Figure 5 shows the issue categorization based on cases reported to a medical billing company. Total 251770 issues were reported from year 2007 till now. 4053 out of 251770 23

reported issues were categorized as billing compliance Issues. 107088 issues out of 251770 were reported against Not a billing compliance issue category. Issues Categories 139929 Total Number of Issues 251770 Total Billing Compliance Issues Reported Not A Billing Compliance Issue Reported Issues Not Categorized 107088 4753 Figure 5: Issue categorization based on cases reported to a medical billing company a) Defining the Compliance Requirement Compliance is disjoint union of the number of special instructions and their compliance with the standard. union compliance =(special_ instructions_received, requirements_compliance) If we want to increase the compliance then we have to increase the compliance with applicable regulatory requirements and standards. max(compliance) =(special_instructions_received) AND max(requirements_compliance) First factor is statistically measurable, so we define its data type as integer. For second variable we will define its type as enumeration data type and its value will be either yes or no. No_of_special_instructions_received, requirements_compliance=(yes_no, ascii) This expression does not help to measure the requirements compliance in an efficient manner. We will attempt to provide concreate values to this variable at next. First we will focus on special_instructions_received. It will include three kinds of interactions: providers will login at website using login information, add special instructions through website and UHIC s employee will receive/handle the special instructions through MIS software. As the exact number of special instructions depends 24

Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry on both the number of providers and the number of special instructions received through Website/IM/E-mail/Call, following five measurement units will be used to represent them: measurement unit no_providers, no_instructions_emails, no_instructions_call, no_instructions_im, no_instructions_website Then, we obtain: Number of providers/clients Number of instructions received via: Email, IM, Call or Website. Verify and Implement special instruction through MIS So, the optimal amount of compliance equals to Non-compliance issues resolved/ Total non-compliance issues + (1-(no_of_providers reported issues/total Providers)). requirements no_special_instructions < Non-compliance issues resolved within time/ Total non-compliance issues + (1-(no_of_providers reported issues/total Providers)) For requirements_compliance, we will represent it in a form of ascii or yes/no and can be expressed as: requirements requirements_compliance <=ascii b) CA behavior in a particular software architecture. Compliance is disjoint union of the number of special instructions and their compliance with the standard. Software architecture for special instructions system assigns a component for every provider and UHIC employee. In these components, we identify some ports that are bound with a connector. component Provider ports out init_special_instruction, notify_uhic_employee in instruction_question, instruction_answer end Provider component UHIC_Employee ports in receive_special_instruction, receive_meeting out special_instruction_progress, notify_provider end UHIC_Employee connector Instruction_Progress connects Provider with UHIC_Employee binds init_special_instruction with receive_special_instruction notify_ UHIC_Employee with notify_employee end Instruction_Progress 25

Below mentioned figure presents the whole first layer of the special instructions system architecture: Figure 6: Components and connectors of the first layer for the provider s special instructions system architecture. 5.2 Overpayment It means to minimize the overpayments to comply with Medicare and Medicaid OIG guideline. Following figure shows that 3% overpayment issues were reported by UHIC s employees and 2% of total issues i.e. 251770 were reported by providers: Figure 7: Total overpayment issues reported internally by UHIC s employees and externally by providers 26

Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry This is CA concerning the compliance of provider instruction with applicable standard. This condition requirement is shown below: minimize(overpayment ) This requirements needs to be handled carefully with other conflicting requirements e.g. efficiency. For example, consider the Provider component. This is developed with provider names details and control module. The control module imports the provider s information from web and a connector exists between them. To minimize non-compliance of Provider s compliant Special Instructions, verify the frequency of special instructions compliance. At next level, the overpayment noncompliance issue can be fixed by repaying/adjusting the overpaid amount. Minimize (Overpayments) = max (repay_overpaid_amount) OR max(overpayments_adjustments) 6. Conclusion We come across two types of requirements, one being user requirements and the other being legal requirements. The problem occurs when there is a conflict between the two. Hence, we have proposed an architecture using a case study from healthcare industry which reviews and analyses the compatibility of the user requirements with the key compliance attributes derived from regulatory requirements. 7. Acknowledgement The authors, Ms. Syeda Uzma Gardazi and Mr. Arshad Ali Shahid would like to acknowledge the Higher Education Commission (HEC), Govt. of Pakistan and FAST- NUCES for providing funding and required resources to complete this work. It would have been impossible to complete this effort without their continuous support. References 1. http://en.wikipedia.org/wiki/health_insurance_portability_and_accountability_act 2. S. U. Gardazi, and A. A. Shahid, E-mail System Architecture for HITECH Compliance, SEDM 2010. 3. L. Bass, P. Clements and R. Kazman, Software Architecture in Practice. Reading, MA: Addison Wesley, 1998. 4. S. U. Gardazi and A. A. Shahid, Survey of Software Architecture Description and Usage in Software Industry of Pakistan, IEEE ICET 2009. 27

5. S. Ghanavati, D. Amyot, and L. Peyton (2007), A Requirements Management Framework for Privacy Compliance. Proc. of the 10th Workshop on Requirements Engineering (WER'07), Toronto, Canada, May, 149-159 6. T. D. Breaux, A. I. Anton, Analyzing Regulatory Rules for Privacy and Security Requirements, IEEE Transactions on Software Engineering, 34(1), pp. 5-20, January 2008. 7. S. U. Gardazi, S. F. Gardazi, H. Khan and A. A. Shahid, Motivation in Software Architecture and Software Project Management, IEEE ICET 2009. 8. S. Ghanavati (2007). A compliance framework for business processes based on URN. M.Sc. thesis, University of Ottawa, Canada, May 2007. http://jucmnav.softwareengineering.ca/twiki/ bin/view/ucm/virlibghanavatimscthesis. 9. R. Accorsi and T. Stocker, Automated Privacy Audits Based on Pruning of Log Data, In Proceedings of the IEEE Conference on Enterprise Distributed Object Computing, pages 175 182, 2008. 10. S. U. Gardazi, A. A. Shahid, Software Architecture for Information Assurance (SARCHIA), PROFES 2010. 28