Medicare Fee Schedule, Payment and Reimbursement Benefit Guideline

Medicare Fee Schedule, Payment and Reimbursement Benefit Guideline 

 

Medicare payment fee schedule  is changing from state to state and county to county. Hence before download any fee schedule implementation, please make sure that you are choosing the correct county and state.

A fee schedule is a complete listing of fees used by Medicare to pay doctors or other providers/suppliers.  This comprehensive listing of fee maximums is used to reimburse a physician and/or other providers on a fee-for-service basis.  CMS develops fee schedules for physicians, ambulance services, clinical laboratory services, and durable medical equipment, prosthetics, orthotics, and supplies.  See Related Links below for information about each specific fee schedule.

PHYSICIAN SERVICES

Medicare Part B pays for physician services based on the Medicare PFS, which lists the more than 7,000 unique codes and their payment rates. Physicians’ services include: 

● Office visits
● Surgical procedures
● Anesthesia services
● A range of other diagnostic and therapeutic services Physicians’ services are furnished in all settings, including:
● Physicians’ offices
● Hospitals
● Ambulatory Surgical Centers
● Skilled Nursing Facilities and other post-acute care settings
● Hospices
● Outpatient dialysis facilities
● Clinical laboratories
● Beneficiaries’ homes

MEDICARE PFS PAYMENT RATES

The Medicare PFS payment rates formula shows how a payment rate for an individual service is determined, and we provide a description for each component below the formula.

1) Relative Value Units (RVUs)

Three separate RVUs are associated with calculating a payment under the Medicare PFS:

● The Work RVU reflects the relative time and intensity associated with furnishing a Medicare PFS service

● The Practice Expense (PE) RVU reflects the costs of maintaining a practice (such as renting office space, buying supplies and equipment, and staff costs)

● The Malpractice (MP) RVU reflects the costs of malpractice insurance



2) Geographic Practice Cost Indices (GPCIs)

Each of the three RVUs are adjusted to account for geographic variations in the costs of practicing medicine in different areas within the country. These adjustments are called GPCIs, and each kind of RVU component has a corresponding GPCI adjustment.


3) Conversion Factor (CF)

To determine the payment rate for a particular service, the sum of the geographically adjusted RVUs is multiplied by a CF in dollars. The statute specifies the formula by which the CF is updated on an annual basis.

You can use the Physician Fee Schedule Search Tool to obtain national and local payment rates. 
For information on how to use the Physician Fee Schedule Search Tool, refer to How to Use the Searchable Medicare Physician Fee Schedule

https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNProducts/downloads/How_to_MPFS_Booklet_ICN901344.pdf

Method for Computing Fee Schedule Amount

The CMS continually updates, refines, and alters the methods used in computing the fee schedule amount. For example, input from the American Academy of Ophthalmology has led to alterations in the supplies and equipment used in the computation of the fee schedule for selected procedures. Likewise, new research has changed the payments made for physical and occupational therapy. The CMS provides the updated fee schedules to carriers on an annual basis. The sections below introduce the formulas used for fee schedule computations.

A. Formula

The fully implemented resource-based MPFS amount for a given service can be computed by using the formula below:

MPFS Amount = [(RVUw x GPCIw) + (RVUpe x GPCIpe) + (RVUm x GPCIm)] x CF

Where:

RVUw equals a relative value for physician work,

RVUpe equals a relative value for practice expense, and

RVUm refers to a relative value for malpractice.

In order to consider geographic differences in each payment locality, three geographic

practice cost indices (GPCIs) are included in the core formula:

A GPCI for physician work (GPCIw),

A GPCI for practice expense (GPCIpe), and

A GPCI for malpractice (GPCIm).

The above variables capture the efforts and productivity of the physician, his/her individualized costs for staff and for productivity-enhancing technology and materials.

The applicable national conversion factor (CF) is then used in the computation of every MPFS amount.

The national conversion factors are:

2002 - $36.1992

2001 - $38.2581

2000 - $36.6137

1999 - $34.7315

1998 - $36.6873

1997 - $40.9603 (Surgical); $33.8454 (Nonsurgical); $35.7671 (Primary Care)

1996 - $40.7986 (Surgical); $34.6296 (Nonsurgical); $35.4173 (Primary Care)

1995 - $39.447 (Surgical); $34.616 (Nonsurgical); $36.382 (Primary Care)

1994 - $35.158 (Surgical); $32.905 (Nonsurgical); $33.718 (Primary Care)

1993 - $31.926 (Surgical); $31,249 (Nonsurgical);

1992 - $31.001

For the years 1999 through 2002, payments attributable to practice expenses transitioned from charge-based amounts to resource-based practice expense RVUs. The CMS used the following transition formula to calculate the practice expense RVUs.

1999 - 75 percent of charged-based RVUs and 25 percent of the resource-based RVUs.

2000 - 50 percent of the charge-based RVUs and 50 percent of the resource-based RVUs.

2001 - 25 percent of the charge-based RVUs and 75 percent of the resource-based RVUs.

2002 - 100 percent of the resource-based RVUs.

As the tabular display introduced earlier indicates, CMS has calculated separate facility and nonfacility resource-based practice expense RVUs.

2010 Medicare Part B Fee Schedule for Delaware (DE),  District of Columbia Metropolitan Area (DCMA), Maryland (MD), New Jersey  (NJ), and Pennsylvania (PA) has been posted in https://www.highmarkmedicareservices.com/partb/index-feeinfo.html

2010 Medicare Part B Fee Schedule  for Connecticut, Indiana, Kentucky and New York has been posted in http://www.empiremedicare.com/ (please select Part B and specify the  region, you will be directed to 2010 Fee Schedule Database)

2010 Medicare physician fee schedule (MPFS)  updates for Florida, Puerto Rico and U.S. Virgin Islands are posted in http://medicare.fcso.com/Fee_news/

2010 Part B Medicare Physician Fee Schedule for  California (Jurisdiction 1 [J1] Part B) has been posted @ http://www.palmettogba.com/palmetto/providers.nsf/DocsCat/Jurisdiction%201%20Part%20B~Publications~Fee%20Schedules~Medicare%20Physician%20Fee%20Schedules%20and%20Updates~8525746A00550AA38525768100694D43

2010 Part B Medicare and Clinical Lab Fee Schedules for  the states Maine (ME), Massachusetts (MA), New Hampshire (NH), Vermont  (VT) and Rhode Island (RI) are posted @ http://www.medicarenhic.com/ne_prov/fee_sched.shtml

To view 2010  Medicare Fee Schedule for all regions please refer 
http://www.cms.hhs.gov/PhysicianFeeSched/PFSCSF/itemdetail.asp?filterType=none&filterByDID=0&sortByDID=2&sortOrder=descending&itemID=CMS1231104&intNumPerPage=10 (The Centers for Medicare  & Medicaid Services (CMS) has condensed all 56 Physician Fee  Schedule (PFS) carrier specific pricing files into one zip file) 

The final rule for payment policies under the Physician Fee Schedule  and other Revisions to Part B for CY 2010 has been posted in http://www.federalregister.gov/OFRUpload/OFRData/2009-26502_PI.pdf

Zip code look up to specific  Carrier Locality http://www.cms.hhs.gov/FeeScheduleGenInfo/ 2010 Durable Medical Equipment Prosthetics,  Orthotics and Supplies (DMEPOS) Fee Schedule for all States has been  posted @ http://www.cms.hhs.gov/DMEPOSFeeSched/LSDMEPOSFEE/itemdetail.asp?filterType=none&filterByDID=0&sortByDID=3&sortOrder=descending&itemID=CMS1231049&intNumPerPage=10

 

What is Differences Between a Rejection and Denial in Healthcare Billing System

Regardless of how brilliant a medical biller is, they are guaranteed to come across rejections and denials from time to time. These terms are frequently used to discuss medical billing claims and are often used interchangeably by even the most experienced team members in the health field. However, a rejection differs vastly from a denial. Additionally, the processes necessary to effectively overturn the ruling of a rejection is different from that of a denial. Understanding these fundamental differences is not only essential for ensuring that medical billing claims can be processed without unnecessary frustration, but will also help increase the efficiency of the revenue cycle and may potentially grow the profitability of the organization you work with.

Claims that do not meet the specific data requirements or the basic format necessary will be rejected, according to the Centers for Medicare & Medicaid Services (CMS). Rejected claims will not be processed because they are not considered to have been “received” by the payor, thus do not make it into the adjudication system. This may sound complicated, but it really isn’t. It simply means that a rejected claim must be resubmitted when the error (or errors) is corrected appropriately. It’s important to note that beneficiaries of a rejected claim cannot be held liable because the services were never actually billed.

Denied claims, on the other hand, have been received by the adjudication system of the payor, and cannot be resubmitted because the payment determination has already been decided upon. A denied claim can, however, be appealed by the request of the payor to necessitate the proper modifications, additional required documents, etc.

Improving Revenue Cycles through Term Clarity

Educating staff members of the differences between a denied or a rejected claim can not only accelerate the appeals process drastically, but also help pinpoint where improvements can be made in the future. For instance, if your team comes across an inordinate amount of rejected claims, you may want to focus additional effort toward improving the process of your claim edits or scrubber to provide your clean claims rate with an added boost. This would likely require the involvement of IT, the business office, and possibly the vendor.

Making an effort to reduce the amount of denied claims will require additional effort as the direct cause can be slightly more difficult to sniff out. Many organizations update their accounting system continuously, making changes where needed in an attempt to improve, but often times further complicate certain tasks in the process. An example would be if your accounting system were configured to reduce rejected claims by accepting the claim adjustment reason codes (CARCs) assigned by HIPAA by parsing them according to queues based on the designated CARCs. Although the system setup may reduce the amount of rejections, it very well may increase the amount of denials. When it comes to configuring a patient accounting system, small details can make all the difference in how claims are processed. This may sound like a lot of technical jargon, but it’s important to have a basic understanding of the operations that your accounting system undergoes when processing claims so that simple mistakes can be avoided and rejected/denied claims can remain separate from one another.

Unseen Opportunity to Improve the Revenue Cycle 

By lumping the terms, denied and rejected together, you may be completely overlooking a possible situation where your organization’s revenue cycle can greatly benefit. Here is a very real scenario that has played out in many organizations virtually unnoticed by all. Imagine if an organization had been receiving notifications for rejected claims as part of an acknowledgement report. The only problem was that no one was actually tasked to work the reports. Instead, the staff member that received the reports was under the impression that rejections and denials were the same thing, but knew that the system this organization had in place was designed to drive denials / rejections to work queues. So, instead of separating the rejected claims, the staff member simply ignored the reports all together creating a problem that could potentially impair the organization’s overall revenue if not properly attended to.

Later on down the line, the rejected claim would appear in the work queue of an A/R staff member. It wasn’t until then that it was realized that the claim had never actually been received by the payor. Obviously, this would greatly hinder the entire claim adjudication process. If the payor pays approximately 45 days after receiving the claim, but the claim was delayed for an additional 20 days because it was needlessly sitting in the work queue, the provider would then be forced to wait 65 days past the date that the claim was originally billed before the payment would be received. In some instances, if the claim sits idle for long enough, too much time will have elapsed, and the provider will lose the revenue associated with that claim. Obviously, that is the worst case scenario, but you’d be surprised at how often this actually occurs. All of this trouble could easily be avoided if a single staff member was aware of the differences between a denied and a rejected claim.

Once workflows are assigned to process denied and rejected claims separately, the bottom line of that organization will improve immediately.

For those that have been in the health industry for many years, it may be habitual to use these terms synonymously, but doing so may be having negative repercussions. It’s incredible to consider that the minor disparity between two similar words can have such a profound impact on your organization. It is up to management to be on the same page as their team so that everyone understands the difference between a denied claim versus a rejected claim. Once that occurs, the appropriate resources can be allocated to ensure that operations run as smoothly as possible.

What’s the difference between 837 Institutional, Professional, Dental?

Dear Blog Readers – HIPAA Friday To You! Last week we defined how other HIPAA EDI transactions may or may not to other 837 transactions. Today is our HIPAA EDI Day and the topic of the day is to simply provide you the list of how you can tell apart the 837 Institutional, from the 837 Professional, or from the 837 Dental.

837 Institutional, Professional, Dental

The 837 transaction has three different implementation guides specifically developed for Professional, Institutional and Dental claims. The specifications are geared to meet the individual requirements of the three different types of claim forms. For instance, the 837 Institutional manual allows for Value Codes, Occurrence Codes and Occurrence Spans. These fields are specific to the UB04 claim form only. The 837 Dental manual allows for Dental Coding and Tooth Designations. These are only used on dental claim forms. The SV segment occurs on each of the three 837 transactions but there is a slight variation for each claim. Professional uses an SV1 segment, Institutional uses an SV2 segment and Dental uses an SV3segment. This is a quick way to determine what type of 837 file is being encountered.

Structurally, all three sets of 837 specifications are same. The only differences would be claim specific data that pertains to a single transaction. All three transactions contain ISA, GS and ST segments but some data and qualifying codes are specific to the type of 837. Another way to quickly identify which type of 837 is being encountered is by the codes sent in the GS-08 or in the ST-03. Professionals use a 005010X222, Institutional uses a 005010X223 and Dental uses a 005010X224.
The most popular EDI claim type is the professional.

Professional

Institutional

Dental

837 EDI Professional Claim Example and Mapping

837 Professional Claim Scenario

The included example shows a standard 837 Professional claim file. It includes data from the provider of Service indicating the member’s demographic information, diagnosis, services rendered and charges. This data will be used by the Insurance Company to determine what benefits should be rendered.
Here are the attributes of the example:
- The submitter of the claim is AGILE BILLING SOLUTIONS
- The receiver of the claim is BCBS DISNEY
- The billing provider is JOHN WATSON
- The patient “Mickey Mouse” is the subscriber
- The payer is BCBS DISNEY
- Mickey Mouse had felt like he had Diarrhea (ICD-9 787.91) and went to visit the doctor and the doctor diagnosed him with the stomach flu (e.g. Gastroenteritis) ICD-9 Codes 787.91 (primary), 009.0 (primary), 009.1, 558
- Mickey’s initial office visit was on January 24th, 2012 – Where Mickey spent 15 minutes with Dr. Watson face-to-face and the diagnosis code for Diarrhea was established – Procedure Code 99213 (HCPCS) – cost $50
After the office Visit Mickey went to the lab for a Stool Culture lab test procedure Code 87046 – cost $15 The lab services were performed at the BEST LAB COMPANY

837 Deciphering Raw Data BHT – 2000A

Beginning of Hierarchical Transaction:  BHT*0019*00*004545*20120124*135420*CH

BHT01    Hierarchical Structure Code : Information Source, Subscriber, Dependent

BHT02    Transaction Set Purpose Code : Original

BHT03    Reference Identification : 004545

BHT04    Date : 1/24/2012

BHT05    Time : 1:54:20 PM

BHT06    Transaction Type Code : Chargeable

LOOP 1000A Submitter Name

Submitter Information:  NM1*41*2*AGILE BILLING SOLUTIONS*****46*1981

NM101    Entity Identifier Code : Submitter

NM102    Entity Type Qualifier : Non-Person Entity

NM103    Name Last or Organization Name : AGILE BILLING SOLUTIONS

NM108    Identification Code Qualifier : Electronic Transmitter Identification Number (ETIN)

NM109    Identification Code : 1981

 Submitter Contact Information: PER*IC*ANN GILLIS*TE*8185601000

 PER01     Contact Type: Information Contact “IC”

 PER02     Contact Name: ANN GILLIS

 PER03     Communication Qualifier: Telephone “TE”

 PER04     Telephone Number: 8185601000

LOOP 1000B Receiver Name

Receiver Information: NM1*40*2*BCBS DISNEY*****46*47198

NM101    Entity Identifier Code : Receiver “40″

NM102    Entity Type Qualifier : Non-Person Entity  “2″

NM103    Name Last or Organization Name : BCBS DISNEY

NM108    Identification Code Qualifier : Electronic Transmitter Identification Number (ETIN)  “46″

NM109    Identification Code : 47198

LOOP 2000A BILLING PROVIDER

Billing Provider Hierarchical Level: HL*1**20*1

HL01     Hierarchical ID: 1

HL02     Parent Hierarchical ID: No Parent

HL03     Hierarchy Level Name: “20″ = Information Source

HL04     Number of Hierarchical Children: 1 more additional subordinate HL

 Provider Specialty Information: PRV*BI*PXC*207Q00000X

 PRV01     Type of Provider: Billing “BI”

 PRV02     Code Qualifier: Health Care Provider Taxonomy Code “PXC”

 PRV03     Provider Taxonomy Code: 207Q00000X

837 Deciphering Raw Data 201AA – 2000B
LOOP 2010AA BILLING PROVIDER NAME

Billing Provider Information: NM1*85*1*WATSON*JOHN*H***XX*1134125736

 NM101    Entity Identifier Code : Billing Provider “85″

 NM102    Entity Type Qualifier : Person “1″

 NM103    Name Last or Organization Name : WATSON

 NM104    First Name: WATSON

 NM103    Middle Name or Initial: WATSON

 NM108    Identification Code Qualifier : National Provider Identifier “XX”

 NM109    NPI: 1134125736

  Billing Provider Address :N3*221 Baker Street

  N301     Street Address: 221 Baker Street

  Billing Provider City, State, ZIP Code: N4*ANAHEIM*CA*92802

  N401     City: ANAHEIM

  N402     State: CA

  N403     Zip: 92802

  Billing Provider Tax Identification: REF*EI*123456789  

  REF01    Reference Qualifier: Employer’s Identification Number “EI”

  REF02    EIN: 123456789

LOOP 2000B SUBSCRIBER HIERARCHICAL
Subscriber Hierarchical Level: HL*2*1*22*0

  HL01     Hierarchical ID: 2

  HL02     Parent Hierarchical ID: 1 (Information Source/Billing Provider)

  HL03     Hierarchy Level Name: “22″ = Subscriber

  HL04     Number of Hierarchical Children: 0 (Subscriber is the patient)

Subscriber Information: SBR*P*18*******CI

  SBR01    Payer Responsibility Sequence Number Code: Primary  “P”

  SBR02    Individual Relationship Code: Self  “18″

  SBR09    Code identifying type of claim: Commercial Insurance Co. “CI”

LOOP 2010BA SUBSCRIBER NAME
Subscriber Information: NM1*IL*1*MOUSE*MICKEY****MI*60345914A

   NM101    Entity Identifier Code : Subscriber  “IL”

   NM102    Entity Type Qualifier : Person “1″

   NM103    Subscriber Last Name: Mouse

   NM104    Subscriber First Name: Mickey

   NM108    Identification Code Qualifier : Member Identification Number “MI”

   NM109    Member Identification Number: 60345914A

    Subscriber Address: N3*1565 DISNEYLAND DRIVE

    N301     Street Address: 1565 DISNEYLAND DRIVE

    Subscriber City, State, ZIP Code: N4*ANAHEIM*CA*92802

    N401     City: ANAHEIM

    N402     State: CA

    N403     Zip: 92802

   Subscriber Demographic Information: DMG*D8*19281118*M

    DMG01    Date Time Period Format Qualifier: Date Expressed in Format CCYYMMDD “D8″

    DMG02    Subscriber Birth Date: 19281118

    DMG03    Subscriber Gender Code: ‘M’ for Male

    Subscriber Secondary Identification: REF*SY*055090001

    REF01    Reference Qualifier: Social Security Number “SY”

    REF02    SSN: 055090001

837 Deciphering Raw Data 2010BB – 2400

    LOOP ID – 2010BB PAYER NAME

    Payer Name: NM1*PR*2*BCBS DISNEY*****PI*8584537845

    NM101    Entity Identifier Code : Payer “PR”

    NM102    Entity Type Qualifier : Non-Person Entity  “2″

    NM103    Name Last or Organization Name : BCBS DISNEY

    NM108    Identification Code Qualifier :  National Plan ID “PI”

    NM109    Identification Code : 8584537845

   LOOP 2300 CLAIM INFORMATION

   Claim Information: CLM*ABC7001*65***11:B:1*Y*A*Y*Y

    CLM01    Claim ID: ABC7001

    CLM02    Claim Amount: 65

    CLM05-1  Place of Service Code: ’11′ Office

    CLM05-2  Facility Code Qualifier: ‘B’ Place of Service Codes for Professional or Dental Services

    CLM05-3  Claim Frequency Code: ’1′ The only bill to be received for a course of treatment

    CLM06    Provider or Supplier Signature On File Indicator: ‘Y’ Yes

    CLM07    Plan Participation Code: ‘A’ Assigned – Provider accepts agreement with payer

    CLM08    Benefit Indicator: ‘Y’ Subscriber authorized payer to remit payment directly to the provider

    CLM09    Release of Information Indicator: ‘Y’ Provider has a Statement Permitting Release of Medical Billing Data Related to a Claim

     ICD9Diagnosis Codes: HI*BK:78791*BF:0091*BF:558*BF:0090

     HI01-1  ‘BK’ for (DX1) Primary Diagnosis    HI01-2: 78791

     HI02-1  ‘BF’ for (DX2) Supporting Diagnosis HI02-2: 0091

     HI03-1  ‘BF’ for (DX3) Supporting Diagnosis HI03-2: 558

     HI04-1  ‘BF’ for (DX4) Supporting Diagnosis HI04-2: 0090

  LOOP 2400 SERVICE LINE

  Service Line Number 1: LX*1

  Professional Service Line Item Details: SV1*HC:99213*50*UN*1***1

  SV101-01 Procedure Code Qualifier: ‘HC’ HCPCS

  SV101-02 Procedure Code: 99213

  SV102    Procedure Amount:  $50

  SV103    Unit of Measure Code: ‘UN’ Units

  SV104    Service Unit Count: 1

  SV107-01 1st Diagnosis Code Pointer: 1

   Date or Time or Period: DTP*472*D8*20120124

      Date/Time Qualifier : ’472′ Service

      Date Time Period Format Qualifier : Date Expressed in Format CCYYMMDD

      Date Time Period : 20120124

  Service Line Number 2: LX*2 

   Professional Service Line Item Details: SV1*HC:87046*15*UN*1***1:2:3:4

  SV101-01 Procedure Code Qualifier: ‘HC’ HCPCS

  SV101-02 Procedure Code: 87046

  SV102    Procedure Amount:  $15

  SV103    Unit of Measure Code: ‘UN’ Units

  SV104    Service Unit Count: 1

  SV107-01 1st Diagnosis Code Pointer: 1

  SV107-02 2nd Diagnosis Code Pointer: 2

  SV107-03 3rd Diagnosis Code Pointer: 3

  SV107-04 4th Diagnosis Code Pointer: 4

   Date or Time or Period: DTP*472*D8*20120124

      Date/Time Qualifier : ’472′ Service

      Date Time Period Format Qualifier : Date Expressed in Format CCYYMMDD

      Date Time Period : 20120124

837 Deciphering Raw Data 2420C

LOOP 2420C SERVICE FACILITY LOCATION NAME

       Billing Provider Information: NM1*77*2*BEST LAB COMPANY*****XX*1124157821

       NM101    Entity Identifier Code : Service Location “77″

       NM102    Entity Type Qualifier : Non-Person Entity “2″

       NM103    Organization Name : BEST LAB COMPANY

       NM108    Identification Code Qualifier : National Provider Identifier “XX”

       NM109    NPI: 1134125736

        Service Facility Address: N3*505 Main Street

        N301     Street Address: 505 Main Street

        Billing Provider City, State, ZIP Code: N4*ANAHEIM*CA*92802

        N401     City: ANAHEIM

        N402     State: CA

        N403     Zip: 92802

Revenue Codes Descriptions and Charges IN UB04 CLAIM FORM

All medical services provided to patients, whether inpatients or outpatients, have costs associated with them. This chapter covers form locators 42-49, lines 1-23, which are used for recording and totaling the cost of each service received for the billing period reflected on the claim (see Figure 12.1). To help the payer understand what services were received by the patient, how much each service costs, and when each service was received, the billing provider must fill in FLs 42-49 carefully and precisely.

According to the current revenue code system defined by the National Uniform Billing Committee (NUBC) for the UB-04 claim form, every service is assigned a revenue code and description. Each revenue code and corresponding description reflects an item, accommodation, or service that is billable by providers. Because revenue codes and descriptions provide the exact details of the service received, they play a key role in determining the final reimbursement amount.

The original NUBC revenue code system used three-digit codes numbered from 001 to 999. To accommodate the need for more codes, the coding system was expanded to a four-digit system. A leading zero was added to the original three-digit codes to make them four-digit codes.
Revenue codes are grouped into major categories, such as Room and Board—Private (011X), Pharmacy (025X), and Physical Therapy (042X). This chapter lists all revenue codes. Descriptions and usage guidelines are provided for the major revenue code categories. Billing tips help explain revenue codes that are often reported incorrectly. For quick reference, Appendix A contains a numerical list of all revenue codes as well as an alphabetical list of selected codes.

Describe the use of the two types of revenue codes that are reported in FL 42 (Revenue Code) on the UB-04: accommodation revenue codes and ancillary service revenue codes.
Become familiar with the narrative description or standard abbreviation that accompanies each revenue code for FL 43 (Revenue Description).
Understand the use of FL 44 (HCPCS/Rate/HIPPS Code) for reporting either the required HCPCS codes on outpatient claims or the charge for accommodations on inpatient claims.
Understand how to report the date of service in FL 45 (Service Date) and the units of measure in FL 46 (Service Units).
Understand how to report total charges and noncovered charges in FL 47 (Total Charges) and FL 48 (Noncovered Charges).

What is diffrence CDA/CCR/CCD/CCDA

If you have been following HealthCare Interoperability Standards at all you will know its loaded with acronyms and is rapidly evolving with the onset of Meaningful Use adoption requirements. I took a specific Deep Dive into unraveling the confusing

CDA/CCD/CCR and CCDA acronyms and feel I now have a pretty good grip on the definition of each, including the backstory on adoption of the standards and where they are headed. Read on as I attempt to break these down with a simplicity I think you will appreciate. Taking a step back for comparison, the DICOM standard accomplished healthcare interoperability in the mid-nineties, when PACS was replacing film workflow in Radiology. Outside of the workflows for patient care, Radiology Films were able to be transported by patients between facilities. Though primitive, an x-ray from one hospital could be “read” between light boxes at another facility. PACS needed to accommodate this workflow as film use declined and accomplished this through the DICOM standard Part 10. The standard allowed Study information to be exported to removable media, most frequently to CD, which could be taken to another facility and imported into the Hospital PACS. It has its problems, but all in all, the solution is beautiful. DICOM provides transmission capability, document capability, and interoperability capabilities all in one nice standard. Efforts to provide similar patient workflow for EMR’s by making the entire patient story portable have been in the works for quite some time, but have been slow to adoption in the United States. Most of the effort in the healthcare space over the last 10 years has been replacing workflows in hospitals with little attention to the interoperability components until recently. One could argue the HL7 standards are solid and provide quite a bit to the workflow component for care givers. In retrospect, I guess we could of handed an HL7 message to a patient and sent them on their way right ? However, the message would have to be all inclusive of the patient snapshot, or embed some sort of document in it to be reviewed on the potential downstream system. The transmission was taken care of, but you’d still run into a format problem of the document embedded. If you look at it that way, this is an interoperability problem the Clinical Document Architecture is trying to accomplish. Rolling up the transmission, export format, and interoperability all in one shot… So to tell you my interpretation as to where we are at,

I want you to meet some acronyms: CDA-Clinical Document Architecture CCR-Continuity of Care Record CCD-Continuity of Care Document CCDA-Consolidated Clinical Document Architecture Most works I have reviewed to come to this conclusion have done a pretty good job of explaining these guys to me, so Im going to take the approach of letting them explain who they are by introducing themselves one by one.
CDA For those of you who don’t know me, I am commonly mistaken for a document. I take pretty big offense to this as I am a complete architecture that should be used to create documents and template methodologies. My parents are from the HL7 Standard, and my stewardship is through the Health Level 7 organization. I was born in 1999, with the release name of CDA Release 1, and my adoption has been pretty steady in the all but United States markets where I was a foreigner for about 8 years. As you will quickly find out, I accommodate more than just summaries and snapshot stories for patients, I am in fact a methodology for all types of medical documents. My DNA is the HL7 Reference Information Model (RIM), but I am flexible enough to accommodate user defined fields (typical HL7), and I can store complete documents, binary data, and multimedia as well in my body. My legitimacy was consummated in 2010 by ANSI.
CCR I’m CCR, short for Continuity of Care Record. I was born in 2004 as the CCR Release 1a, and my DNA is not the CDA. I don’t like to do much, but I do serve a single purpose pretty well. I was initially created as a word document that helped interoperability between PCP’s for patient summary information. I am a document only, and don’t ask me to do anything else like story binary data or multi-media information. I do support interoperability though in regards to what I do, and the ASTM standards group has got my back. I was cool enough for absolute adoption with EMR’s and PHR’s and was the document of choice for the now deprecated Google Health.
CCD Hi, Im CCD, the Continuity of Care Document. I am the product of a huge “fist bump” between ASTM and HL7 to help kick start interoperability in the United States and get along. My DNA is a subset of the CDA, with a lot of the great ideas the CCR had implemented, so I am a comprise of the two. Since my birth in 2007, I have never actually been overseas, but hope to some day. Like CCR, I am just a document. You cant store any binary data in me I can however support user-defined fields. I’ve been cloned to meet different purposes, which makes me a bit of a template derived from the CDA, but I am by no means an architecture.

CCDA
Starting December 2011, I am the new architecture in town, the Consolidated Clinical Document Architecture, and I will cleanup this mess that CCD/CCR created without discounting their feelings. Im all about making CDA Templates, and guess what? CCD is one of my templates! I will be adopted by the United States through Meaningful Use efforts, and I will make it incrementally easy to achieve through attrition. Someday the world will all use me hopefully, and deliver the promise of persistence, stewardship, potential authentication, context, wholeness and human readability I promised out of the gate in 1999.
In my humble opinion though, the coolest thing about CDA is its attention of the ability for human consumption.  If everybody has their own way of reporting the “patient story” and sends the patient down the road with it, it would take an enormous amount of attention to getting to the point quickly for another care giver (think book comprehension here).  So, enter the idea of templates, which at the end of the day is all about aiding human consumption too, so caregivers will know where to go for the information they are specifically looking for.  Still though, these types of documents are really just about a bunch of facts.  Some facts are chronologically presented which gives them some sort of context, but really a bunch of facts is more like a really bad set of cliff notes in relation to a sometimes huge patient story that needs to be interpreted.  The Clinical Document Architecture gives us context by promoting a clinical document that tells a specific story about the care provided to the patient for the problems.  The Clinical Document Architecture also promotes wholeness between the facts it provides, by supporting relation between the facts and statements contained in the document.  The Clinical Document Architecture supports human readability too, for both patient and provider, and you’d probably be surprised the CDA supports video and audio too complete with interoperability between systems.  You cant even do that with your social networks yet.