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
Computer Science Journal Volume 1, Issue 1, April 2011
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.
Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry
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
Computer Science Journal Volume 1, Issue 1, April 2011
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
Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry
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.
Computer Science Journal Volume 1, Issue 1, April 2011
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),
Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry
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)
Computer Science Journal Volume 1, Issue 1, April 2011
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)
Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry
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
Computer Science Journal Volume 1, Issue 1, April 2011
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
Syeda et al: Billing Compliance Assurance Architecture for Healthcare Industry
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)
Computer Science Journal Volume 1, Issue 1, April 2011
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.