Claim Processing

• Claim Processing is a multi-step process of processing the claim submitted by the Provider or the Beneficiary. Two ways to submit a claim:

a) Hard copy format (entered manually into system)

b) Electronically (EDI or DDE)

For Hard Copy format: Image of hard copy format is captured for audit and archival purpose using imaging, micro-filming or intelligent character recognition (ICR/OCR); assigns a control number to each claim; claim information is manually entered or using ICR technology; then claims is submitted to the shared system.

A. Validation and Sorting

i.Stamps the date of receipt on paper claims

ii.Image paper claims and attachments (stores the copy)

iii.EDI translation is performed on electronic submission. Translates into flat file.

iv.Automated process is performed for initial format validation check.

v.HIPAA compliance edits are performed.

vi.A back up copy of electronic files is created for audit and archival purpose.

vii.Sorting of claim is done.

viii.A control number (unique) is assigned to each claim.

ix.Claims are sent into shared system into batches.

x.Any claim that doesn’t pass the edit is rejected back to the Provider.

xi.Beneficiary and Provider data is checked on the claim against the data in the corresponding beneficiary and provider data in files. If the Provider or Beneficiary data is not matched with the data on the file, the claim is rejected.

xii.Incomplete claims are returned to submitter for correction and resubmission.

xiii.Complete claims are ready for batch processing and moved to next processing stage.

xiv.Claims with invalid data are denied.

B. Adjudication

Automated batch processing

i. Completeness

ii. Valid submittals

iii. Valid values and

iv. Data consistency

v. Apply rules and guidelines to check for duplicate and suspensions and valid Provider and Beneficiary eligibility.

vi. If suspensions are generated or further investigation is required, the claims/adjustment undergo further manual processing

vii. Rejection may be generated by line or by claim; if some parts of claim are acceptable, that part of the claim may be paid.

C.

Pricing and Remittance Advice:

• · Once the claim/adjustment is complete, it goes through pricing and is then sent for verification.

View blog reactions

HL7 Format

HL7 is a standard developing organization operating in healthcare domain and develop standards to permit exchange of healthcare information between computer applications in encoded format.

HL7 format uses Arden syntax for encoding medical information.

While interfacing two machines or applications which exchange medical information, some specifications need to be specified like:

· Defining the communication protocol it will use.

· HL7 version to be used (currently 3.0).

· Define HL7 messages to be sent or received between the applications.

· Defining the message format for each message that the two applications or machines will exchange.

As we know every healthcare organization bills for services provided, the moment medical information is exchange for billing purpose; the HL7 standard comes into picture.

· Whether it’s transferring the clinical data to different departments throughout the hospital, or

· Exchanging data with reference labs.

So, overall HL7 provides standards to make process of clinical data exchange to be standardized, secured and consistent.

View blog reactions

HIPAA 5010: Changes in Individual Transaction

270- Eligibility Request

· Added search option wit Member ID, last name and date of birth.

· Added support for additional 38 Patient Service Type codes.

· Added benefit search based on Diagnosis Codes.

271- Eligibility Response

· Changes are made to clarify that when a patient has active benefit coverage, the health plan must report: Beginning effective date, Plan Name and the benefit effective date if different from overall coverage.

· New Health Plan requirements are added to the 271 Eligibility response.

· New requirements are added to specify nine category of benefits to be reported if available the patient.

· When reporting on co-insurance, co-payment and deductible, it’s now explicitly required that patient portion of payment is to be reflected in either monetary or percentage amount.

276/277- Claim Status Request and Response

· Sensitive Private Health information is removed for status check purpose.

· REF segment can now be used to identify prescription number for pharmacy information.

· Specific tracing number can be recorded (modified TRM segment).

· New requirements allow Payer to report more status code (STC) and greater details about the claim status.

287- Health Care Service Certification

· Structural changes are made which enables to group information about patient events such as diagnosis, category of service hierarchically.

· Procedures are moved to from Healthcare information code segment (HI) to professional (SV1), institutional (SV2) and dental (SV3).

· The 278 TR3 also clarified the use of the patient condition segment, by adding separate implementation segments and rules.

· Reject reason code data elements was changed, now to be a repeating data element to allow multiple reject codes to be reported.

837- Healthcare Claims (I, P and D)

· Subscriber information is not reported if Patient information uniquely identifies the patient.

· Clearly defined as to how NPI subparts are to be reported structurally.

· A separate element is added to report tax number.

· ICD-10 is supported.

835- Claim Payment/Remittance

· A remittance delivery method segment is added.

· A new Healthcare Medicare Policy segment is added.

· Segment is added to supply the Payer URL.

View blog reactions

Major Changes in HIPAA 5010

1. This new rule adopts the use of ANSI X12 version 5010 of EDI transactions in healthcare, replacing the older version 4010A1.

2. This new rule also addresses to adopt ICD-10, which is a modification of Medical Code Set Data.

3. It clarifies the NPI instructions and it’s use.

4. In HIPAA 5010 additional attention is paid to Privacy Issue around “Minimum Necessary” rule.

5. This new rule also eliminates the dependency on Companion Guide.

6. Additional attention is paid on Acknowledgement Transactions.

7. New rule will eliminate the PHI theft, fraud and abuse cases in healthcare industry.

View blog reactions

HIPAA

HIPAA stands for ‘Health Insurance Portability and Accountability Act’. HIPAA was started by Congress in 1996 and was produced in two Titles:

· Title I: Title I protects the health insurance coverage of workers and their families when they change or loose job.

· Title II: Title II, also known as ‘Administrative Simplification Provision’. It requires the establishment of national standards for electronic healthcare transactions and national identifiers for Providers, Health Insurance Plans and Employers. Basically it addresses the security and privacy of Health Data.

HIPAA mandates healthcare organizations to implement privacy and security standards when electronically storing and sending healthcare information.

Under Title II, comes the five different rules to protect the healthcare information of an individual:

1. Privacy Rule

2. Transaction Code Set Rule

3. Security Rule (Administration, Physical and Technical)

4. Unique Identifier Rule

5. Enforcement Rule

View blog reactions

SWOT Analysis

SWOT analysis is done in strategic planning before the phases of SDLC. SWOT stand for Strength, Weakness, Opportunity, Threats. Basically we analyze our company, project under these four headings

I suppose its nothing more than a structured form of brain storming, but because it is simple, it a great way at the start of the project to encourage people to think 'out of the box'.

That means, it is better to look into the industry where we are and then identify the threats and opportunity of the industry, not of our company but of the whole industry that we are in. We need to consider the competition right away, then we can identify company's strength and weakness.

The logic behind the SWOT analysis is to align company's strength and/or weakness to the opportunities of industry. This way we can attack the industry with the current company's strengths or we may remove the company's weakness to confront the threats of industry.

There are lots of tools in market to get templates for SWOT analysis like smartdraw, mindjet, etc.

View blog reactions

Healthcare Terms

HIPAA: HIPAA stands for Healthcare Insurance Accountability And Portability Act.

HMO: HMO Stands for Health Maintenance Organization. It offers prepaid comprehensive coverage for both hospital and physician services.

Medicare: It’s a Federal health insurance program for people of age 65 or older and for individuals with disabilities.

Medicaid: It is a program sponsored by the federal government and administered by states and is intended to provide health care and health related services to low income individuals.

CMS: CMS is the Centers for Medicare & Medicaid Services.It is the federal agency responsible for administering the Medicare, Medicaid, SCHIP (State Children's Health Insurance), HIPAA(Health Insurance Portability and Accountability Act), CLIA (Clinical Laboratory Improvement Amendments), and several other health-related programs.

EDI: It stands for Electronic Data Interchange. It’s the mutual exchange of healthcare data between the providers and insurance company.

EOB: EOB stands for Explanation Of Benefits. It details the results of processing a claim. Provider receives a remittance advice or remit, which is a notice sent by the insurance company that contains payment information about a claim.

Coding: It’s the process of assigning diagnoses, procedures, and services using numeric and alphanumeric characters. Two coding systems are used in healthcare: ICD-9-CM (International classification of disease) and HCPCS (Healthcare Common Procedure Coding System).

HIPDB: Its Healthcare Integrity and Protection Data Bank which combats fraud and abuse in health insurance and health care delivery.

HCRA: HealthCare Reimbursement Account, a tax exempt account used to pay for healthcare expenses.

MEVS: Medicaid Eligibility Verification System. It allows provider’s to electronically access the state’s eligibility file.

NPI: Stands for National Provide Identifier. Its purpose is to uniquely identify a healthcare provider in standard transactions, such as healthcare claims.

HHS: The Department of Health and Human Services (HHS) has determined that CMS will have responsibility for enforcing the transactions and code set standards, as well as security and identifiers standards when those are published. CMS will also continue to enforce the insurance portability requirements under Title I of HIPAA. The Office for Civil Rights in HHS will enforce the privacy standards.

COB: Coordination of Benefits.

EFT: Electronic Fund Transfer

LR: Legislative request

View blog reactions

EDI Transaction Flow in Healthcare

View blog reactions

EDI Testing

Recommended Types of Testing:

Type 1: EDI syntax integrity testing – Testing of the EDI file for valid segments, segment order, element attributes, testing for numeric values in numeric data elements, validation of X12 or NCPDP syntax, and compliance with X12 and NCPDP rules. This will validate the basic syntactical integrity of the EDI submission.

Type 2: HIPAA syntactical requirement testing – Testing for HIPAA Implementation Guide-specific syntax requirements, such as limits on repeat counts, used and not used qualifiers, codes, elements and segments. Also included in this type is testing for HIPAA required or intra-segment situational data elements, testing for non-medical code sets as laid out in the Implementation Guide, and values and codes noted in the Implementation Guide via an X12 code list or table.

Type 3: Balancing – Testing the transaction for balanced field totals, financial balancing of claims or remittance advice, and balancing of summary fields, if appropriate. An example of this includes items such as all claim line item amounts equal the total claim amount. (See pages 19-22, Healthcare Claim Payment/Advice – 835 Implementation Guide for balancing requirements of the 835 transaction.)

The Coupler Mapper Maporators provides extensive set of functions to achieve this type of testing.

Type 4: Situation testing – The testing of specific inter-segment situations described in the HIPAA Implementation Guides, such that: If A occurs then B must be populated. This is considered to include the validation of situational fields given values or situations present elsewhere in the file. Example: if the claim is for an accident, the accident date must be present.

Type 5: External code set testing – Testing for valid Implementation Guide-specific code set values and other code sets adopted as HIPAA standards. This level of testing will not only validate the code sets but also make sure the usage is appropriate for any particular transaction and appropriate with the coding guidelines that apply to the specific code set. Validates external code sets and tables such as CPT, ICD9, CDT, NDC, status codes, adjustment reason codes, and their appropriate use for the transaction. NOT SUPPORTED by Coupler.

Type 6: Product types or line of services: This testing type is required to ensure that the segments/records of data that differ based on certain healthcare services are properly created and processed into claims data formats. These specific requirements are described in the Implementation Guides for the different product types or lines of service. For example, ambulance, chiropractic, podiatry, home health, parenteral and enteral nutrition, durable medical equipment, psychiatry, and other specialized services have specific requirements in the Implementation Guide that must be tested before putting the transaction in production. This type of testing only applies to a trading partner candidate that conducts transactions for the specific line of business or product type.

Type 7: Implementation Guide-Specific Trading Partners: The Implementation Guides contain some HIPAA requirements that are specific to Medicare, Medicaid, and Indian Health. Compliance or testing with these payer specific requirements is not required from all trading partners. If the trading partner candidate intends to exchange transactions with one of these Implementation Guide special payers, this type of testing is required. When a certification service certifies a trading partner for compliance, the certification service must indicate whether these payer specific requirements were met during the certification process. Other payers and trading partners may have their own specific business requirements; but, unless they are listed in the HIPAA Implementation Guides, they are not HIPAA requirements. These non-HIPAA trading partner specific requirements must be tested as part of the business-to-business testing. For further information on business-to-business testing and for further information on testing trading partner rules that are not contained in the Implementation Guides, please see the Business-To-Business Testing White Paper developed by this sub-workgroup.

View blog reactions

HIPAA Modification Rule

1. What was adopted under the HIPAA Modifications

• Rule Version 5010 of the X12 standards suite of administrative transactions
• Version D.0 of the NCPDP suite for retail pharmacy
• Version 3.0 of the NCPDP Suite for Medicaid pharmacy subrogation
• Version D.0 orVersion 5010 for retail pharmacy supplies and services, based on trading partner agreements

2. Why Version 5010?

Version 4010 is outdated:

• More than 5 years since initial implementation, but 8 years since balloting of the current version
• Many situational and required rules did not fit business practices of the industry
• Industry relied extensively on companion guides, limiting value of standards
• Many transactions were not implemented at all because of limited utility and value

Version 5010 is an improvement because it…

• Includes structural and content oriented changes
• Incorporates more than 500 change requests
• Resolves ambiguities in situational rules
• Provides more consistency across transactions –most rules are the same throughout the suite
• Shortcomings have been addressed to increase value of transactions such as referrals and authorizations.

3. Why Version D.0?

Version 5.1 is outdated:

• More than 5 years since initial implementation, but 8 years since balloting of the current version

Version D.0 is an improvement because it:

• Incorporates change requests submitted by the industry to accommodate changing business needs
• Incorporates changes necessitated by the requirements of the Medicare Prescription Drug Improvement and Modernization Act (MMA)

4. Policy features of HIPAA modifications rule

• Compliance date for 5010 and D.0
• Mandatory compliance on January 1, 2012 –all covered entities
• Internal Testing to begin on or after January 1, 2010
• External testing to begin on or after January 1, 2011

• No entity may require another entity to use the new version of the standard without agreement between the two parties for testing and implementation

• Ability to use X12 or NCPDP for retail pharmacy supplies and services
• Supports existing industry practice
• Requires agreement between trading partners

• Compliance date for Version 3.0
• Mandatory compliance on January 1, 2012 –all covered entities except small health plans
• Small health plans have until January 1, 2013

5. Benefits of Conversion: 5010/D.0/3.0

• Less ambiguity in the TR3 (guides)
• Enhanced usability and usefulness of certain transactions such as referrals and authorizations (X12 and NCPDP)
• Improved utility of the NCPDP standards, compliance with Part D requirements
• Reduces reliance on companion guides
• Supports increased use of EDI between covered entities
• Supports E-Health initiatives now and in the future
• Version 3.0 provides standard method of recouping State Medicaid funds paid inappropriately

6. Who is Affected?

All HIPAA Covered Entities

• –Providers
• –Health Plans
• –Clearinghouses

Business Associates of Covered Entities that use the affected transactions

• Billing/Service Agents

7. What must be changed?

•The formats currently used must be upgraded from X12 Version 4010A1 to 5010 and from NCPDP 5.1 to D.0

•Systems that submit claims, receive remittances, exchange claim status or eligibility inquiry and responses must be analyzed to identify software and business process changes

•The new versions have different data element requirements

•Software must be modified to produce and exchange the new formats

•Business processes may need to be changed to capture additional data elements now required

•Transition to the new formats must be coordinated:

• –continue to use the current formats for some Trading Partners’ exchange
• –start to use the new formats with other Trading Partners

8. HIPAA 5010 Scope

•New ASC X12 standard acknowledgement and rejection transactions

• –The Functional Acknowledgement 997 is being replaced by the 999 transaction
• –The Claims Acknowledgement (277-CA) will be used to replace proprietary error reporting

9. Enhancements included with 5010

•Enhancements are focused on functional areas requiring 5010 changes and are limited to:

• –Improving claims receipt, control, and balancingprocedures
• –Increasing consistency of claims editingand error handling

• Provides common edit definitions to be used by all systems and jurisdictions

• –Returning claims needing correction earlierin the process
• Adds edits for common mistakes to the front end MAC systems, rather than waiting to do these edits in the adjudication systems

• –Assigning claim numberscloser to the time of receipt
• The front end systems will assign the base claim number (in the format expected by the adjudication system), and have the adjudication system add any suffix necessary for split or adjustment claims

10. HIPAA 5010 Scope vs. ICD-10 Scope

The HIPAA 5010 project is a pre-requisite for the ICD-10 project

•What 5010 DOES do:

• –Increases the field size for ICD codes from 5 bytes to 7 bytes
• –Adds a one-digit version indicator to the ICD code to indicate version 9 vs.10
• –Increases the number of diagnosis codes allowed on a claim
• –Includes some of the other data modifications in the standards adopted by Medicare FFS

•What 5010 DOES NOT do:

• –Does not add processing needed to use ICD-10 codes
• –Does not add a crosswalk of ICD-9 to ICD-10 codes
• –Does not require the use of ICD-10 codes

The 5010 format allows ICD-9 and/or ICD-10 CM & PCS code set values in the transaction standard.

The business rules for using ICD-10 code set values will be defined with the ICD-10 project.

View blog reactions