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.

User definr split function in Sql Server

The purpose of split function (table valued function) is to split a delimited value into multiple values based on delimiter and display in tabular form.

split function takes two parameters

• Delimited Value: The delimited value to be split in multiple values.
• Delimiter: The delimiter like comma, colon, semicolon, pipe etc. on the basis of which delimited value to be split.

and returns table of multiple values delimited on the basis of delimiter.

 

CREATE FUNCTION split(
    @delimited NVARCHAR(MAX),
    @delimiter NVARCHAR(100)
) RETURNS @t TABLE (id INT IDENTITY(1,1), val NVARCHAR(MAX))
AS
BEGIN
    DECLARE @xml XML
    SET @xml = N'<t>' + REPLACE(@delimited,@delimiter,'</t><t>') + '</t>'
    INSERT INTO @t(val)
    SELECT  r.value('.','varchar(MAX)') as item
    FROM  @xml.nodes('/t') as records(r)
    RETURN
END

Step wise explanation of split Function

1. Converting the delimited value into XML using replace function, where all delimiters are getting replaced with tag to make it as XML and assigning the same to XML Variable
2. Reading the Node from XML variable and storing the values in table variable @t. Refer related blog post, XML Node into Tabular Form
3. Returning the table variable @t

Let's take an example to split a comma delimited value into multiple values on the basis of delimiter (comma) using split function.

 

SELECT * FROM dbo.split('val1,val2,val3', ',')

 

 Now let's take another 
example where you have multiple delimited value stored in a table 
against an ID and each value needs to split on the basis of delimiter.




We would be using Cross Apply clause in the example.



Refer related post, Apply Operator in SQL Server

DECLARE @TAB TABLE(
    id int, list varchar(100)
)
INSERT INTO @TAB
SELECT 1, 'apple;banana;grapes;orange'
UNION ALL SELECT 2, 'potato;onion;carrot;brinjal'

SELECT * FROM @TAB

SELECT    t.id, s.val
FROM    @TAB t
CROSS APPLY dbo.split(t.list, ';') s