XML - CCR

Continuity of Care Record (CCR) format

This format is a standard for sending/receiving patient information. For example, Google Health will accept this format.

If you are interested in storing and/or managing health information with Google Health or other organization, we may be interested in supporting your effort. For more information about Google Health go here: http://www.google.com/intl/en-US/health/tour/index.html If this link is broken, you can 'google' for the correct link with something like 'Google health'

A Google Health Account is free (at least it was when this was written)

This format is XML.

A patient's medication might be coded like this (example from Google API)

<ProductName>

<Text>GLYBURIDE 2.5 MG TAB</Text>

<Code>

   <Value>23490563801</Value>

   <CodingSystem>NDC</CodingSystem>

</Code>

</ProductName>

A diagnosis code might be coded like this: (example from Google API)

<Description>

<Text>Diabetes, Type 2</Text>

<Code>

   <Value>250.92</Value>

   <CodingSystem>ICD9</CodingSystem>

</Code>

</Description>

We use a similar XML format. It is different from Google Health. It would be great for tax payers if the different formats could be eliminated and everyone would use one format. There is not enough difference to justify all the different formats. It could save billions of dollars. The government is always talking about the need to save money. This is such an obvious example.

There is another example, somewhat related. The HIPAA law mandates that all payers accept one format for EDI. Currently that is X.12 v4010 A1. Soon it will be replaced by v5010. Even though this has been a federal law since 1966, there are still hundreds of different variations on the 'standard'. It seems like every payer has a 'companion document' which is really just a different format. X.12 v4010 A1 is no more of a standard than the old NSF flat file. In order to save money, they must not be similar, they must be the same. We have been in business, doing EDI for over 30 years. It is easy for us to support whatever the payer wants. As long as their requirements are within 10 miles of what it should be, we can probably manage to do it. Can you believe that the specs for the government mandated X.12 formats costs more than $2,700.00 (as of the date this is written). Those costs must be passed on to clients which in turn get passed on as a cost of medical care. The government has thousands of files for free download on cms.gov. Why don't they put the 8 format files on their free download web site and lower healthcare costs? Probably some legislator's relative would lose some money?

Medicare will not accept claims by Internet connection. That requires billions of dollars to be spent to support and maintain modems and phone lines to transfer information over unreliable connections at slow speeds. The difference between supporting DSL Internet FTPs file transfer and dial-up is beyond comparison. Dial-up doesn't work well enough to continue using it. DSL Internet FTPs is fast, reliable and rarely needs any support at all. Does someone still think that dial-up is better or more secure? How old is that person? How about checking out some of the easy, free encryption methods. There is a lot of information available for someone willing to learn and keep up with the times.

Medicare will not accept payments other than by a stamped envelope containing your credit card information or a check. That means there must be machines and people opening those envelopes and doing data entry. Anyone remember the 1960-1970's? Medicare may be the last 'business' that doesn't have a way to pay online. Why not auto-pay online by credit card? How many billions of dollars could be saved? That does not even mention the aggravation of the Medicare subscribers.

This is a big issue for the tax payers. We would like to help, but finding someone willing to listen is not easy.