Billing Compliance Assurance Architecture for Healthcare Industry … · Billing Compliance...

Computer Science Journal Volume 1, Issue 1, April 2011

16

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.

[email protected], [email protected]

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, [email protected]

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

Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry

17

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


18

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.


19

• 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


20

mentioned diagram explains the UHIC’s business process:

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) Instructions received via Secure Support Center or via E-mail

iii) 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:

Statistical Analysis of Special Instructions

Received from Providers 285

7295

4

81 71

731

184

114

39 39 29

85

25

148

26

71

0

50

100

150

200

250

300

No S

how

Charg

es

Pro

vid

er Fee

Partic

ipating a

nd

Capitation

Work

ers

Codin

g

Bala

nce o

ut

Codes to A

dust in

Oth

er In

structions

E-m

ail/C

onta

ct

# 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

A Healthcare IT Company


21

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 non-

functional) 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.


22

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 non-

covered 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),


23

• 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:

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

Maximize (compliance)


24

reported issues were categorized as billing compliance Issues. 107088 issues out of

251770 were reported against ‘Not a billing compliance issue’ category.

Issues Categories

251770

4753

107088

139929

Total Number of Issues

Total Bill ing Compliance

Issues Reported

Not A Bill ing Compliance

Issue Reported

Issues Not Categorized

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.

If we want to increase the compliance then we have to increase the compliance with

applicable regulatory requirements and standards.

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”.

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

union compliance =(special_ instructions_received,

requirements_compliance)

max(compliance) =(special_instructions_received) AND

max(requirements_compliance)

No_of_special_instructions_received,

requirements_compliance=(yes_no, ascii)


25

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:

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)).

For requirements_compliance, we will represent it in a form of ascii or yes/no and can

be expressed as:

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.

measurement unit no_providers, no_instructions_Emails, no_instructions_call,

no_instructions_IM, no_instructions_website

requirements no_special_instructions < Non-compliance issues resolved within time/ Total

non-compliance issues + (1-(no_of_providers reported issues/Total Providers))

requirements requirements_compliance <=ascii

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


26

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


27

This is CA concerning the compliance of provider instruction with applicable

standard. This condition requirement is shown below:

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 non-

compliance issue can be fixed by repaying/adjusting the overpaid amount.

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.

minimize(Overpayment )

Minimize (Overpayments) = max (repay_overpaid_amount) OR

max(overpayments_adjustments)


28

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.

Billing Compliance Assurance Architecture for Healthcare Industry … · Billing Compliance...

Documents

Transcript of Billing Compliance Assurance Architecture for Healthcare Industry … · Billing Compliance...