Stream: argonaut
Topic: Proposal: HCPCS to Procedure/ICD to Condition
Eric Haas (Oct 10 2019 at 18:39):
The Standard for Trial Use (STU) update of US Core version 3.1.0 (continuous build) , which is based on FHIR R4, is in the home stretch for a planned publication later this month.
During the review this week, participants brought forward two additional items for Structured Documents to consider:
Add HCPCS to US Core Procedure.code value set (GF#24925)
Add ICD to US Core Condition.code value set (GF#24924)
The US Core Condition Profile, and US Core Procedure profile were not in the original proposed scope of the STU update.
Structured Documents discussed theses updates and approved proceeding with the expansion of scope. A final decision on these trackers will occur on the next Structured Documents call, on 10/17/2019.
Peter Muir (Oct 10 2019 at 23:36):
Does addition of ICD to Condition include ICD-10 (mandatory) plus ICD-9 for data elements entered prior to Oct 2015 since electronic history goes back to ICD-9? VSAC oids typically contain SNOMED, ICD-9, ICD-10 for quality measurement. Procedure codes need to contain SNOMED, CPT, HCPCS and also recommend HCC codes to cover the essential data elements. Of course, LOINC and RxNorm also need to be included in oids for quality measures (but they have already been included in standard) @Eric Haas
Eric Haas (Oct 10 2019 at 23:53):
ICD-10-CM
Eric Haas (Oct 10 2019 at 23:54):
and HCPCS II
Peter Muir (Oct 11 2019 at 00:27):
Obviously needs ICD10 but also needs ICD9 to meed operational needs of clinicians and patients. C-CDA contains ICD9. Items recorded by ICD9 are not going to come through to patient record? If FHIR does not have the capability of pulling previous diagnosis by ICD-9 from record then you are requiring providers to edit medical history of items entered prior to Oct 2015 across the US which would significantly increase clinician burden. Some quality measures will pull information from more than 10 years ago. For example CMS124 refers to an VSAC oid that contains ICD-9 that cover conditions that may have occurred 20 years ago and have been entered 10 years ago. According to the 80:20 rule, if FHIR can not meet an 80 need ....
Grahame Grieve (Oct 11 2019 at 01:49):
80:20 rule relates to resource design and when to include content. It doesn't apply to terminology selection in IGs. Sounds like ICD-9 should be legal too.
Eric Haas (Oct 11 2019 at 04:13):
regs say ICD-10 for encounter diagnosis
...the same argument could be had for SNOMED RT and READ everywhere we have SNOMED CT.
Grahame Grieve (Oct 11 2019 at 05:29):
what do the regs say about legacy data?
- don't send it
- recode it in ICD-10?
- ... what else?
Rob Hausam (Oct 11 2019 at 06:12):
The ability to handle legacy Read coded data would be important if we were in the UK (or probably New Zealand). And both Read and legacy SNOMED (alphanumeric) coded data should have readily available direct 1 to 1 mappings to SNOMED CT (at least in nearly all cases), if that's needed, which isn't the situation for ICD-9-CM or ICD-10-CM to SNOMED CT.
Brett Marquard (Oct 11 2019 at 12:04):
The tracker title 'Add ICD to US Core Condition.code value set.' was intentional to see what discussion it generated. I see no problem adding both ICD-9 and ICD-10...
Brett Marquard (Oct 11 2019 at 12:11):
Although since I am standards developer I can argue with myself -- we want to point people to use SNOMED CT and ICD-10. Systems likely won't be forced to certify on ICD-9 so no need to include....and since no validator exists to properly test the 'extensible' binding (that I am aware of) folks will just send ICD-9 when that's all they have and not get dinged.
Brett Marquard (Oct 11 2019 at 12:11):
Maybe a compromise is to include ICD-9 and state 'for historical data only'
Brett Marquard (Oct 11 2019 at 12:12):
also not testable without providing new test data :yum:
Lloyd McKenzie (Oct 11 2019 at 14:38):
Might be best to qualify 'historical' with "coded before year X", to avoid those trying to find a loophole by saying that 10 seconds ago is technically historical...
Rob Hausam (Oct 11 2019 at 15:58):
This came separately from Avinash at ONC:
During the 2015 Edition ONC Certification, ONC had requested feedback from the stakeholders, and the recommendation was to use ICD-10 rather than ICD-9. Here’s the link to the relevant discussion at the time:
https://www.federalregister.gov/d/2012-20982/p-265
So it sounds like his position is that we don't need to include ICD-9-CM here (although I'm still not entirely sure of the rationale for that conclusion when dealing with historical data).
Grahame Grieve (Oct 11 2019 at 16:42):
that depends on what you think 'use' means
Eric Haas (Oct 11 2019 at 18:02):
Is there really no translation between 9 and 10?
Eric Haas (Oct 11 2019 at 18:03):
What part of standard coding system am I missing.
Lloyd McKenzie (Oct 11 2019 at 18:17):
They're really totally different code systems
Lloyd McKenzie (Oct 11 2019 at 18:18):
That doesn't mean there aren't mappings, but the mappings definitely aren't exact. ICD10 is more granular in lots of places
Jenni Syed (Oct 11 2019 at 18:23):
@Eric Haas ICD 10 is 4x as large as ICD 9
Jenni Syed (Oct 11 2019 at 18:24):
And the easiest example as to why it's not easy to do 1:1 is the concept of giving info like "Struck by orca, first encounter"
Jenni Syed (Oct 11 2019 at 18:24):
much more specific than what ICD 9 often had contained in the actual code
Jenni Syed (Oct 11 2019 at 18:25):
In ICD9 this would have been "Other specified injury caused by animal"
Jenni Syed (Oct 11 2019 at 18:26):
if it even got that specific, I guess :)
Rob Hausam (Oct 11 2019 at 18:27):
it's that second encounter with the orca that you really have to worry about :)
Jenni Syed (Oct 11 2019 at 18:28):
There really are some awesome ICD 10 codes
Peter Muir (Oct 11 2019 at 20:36):
@Rob Hausam Avinash sent link which dates back to 2012 and was looking forward to ICD-10 transition in Oct 2015.
Bottom line is that FHIR should be able to pass all code systems contained in VSAC oids (ICD-10, ICD-9 and SNOMED for condition/diagnosis and CPT, HCPCS and SNOMED for procedure). LOINC and RxNorm are also found in VSAC but they are already included as code systems. Clinical and payer systems would be ICD-10 and CPT/HCPCS since 10/2015 (but still have pertinent ICD-9 data from before that). The spec should include code system and code value for a resource similar to how CQL manages VSAC oids.
Clinical systems must deal with patient information going back in time. Cross-mapping between coding systems is extremely difficult and usually gets dropped on the shoulders of clinicians. If code system and value are passed, then comparing to data sets such as the VSAC oids are the way to go for CQM, CDS, etc.
ps my personal favorite for ICD-10 was V97.33XD: Sucked into jet engine, subsequent encounter.
Lloyd McKenzie (Oct 11 2019 at 21:20):
On a Da Vinci call today, we learned that there are HCPCS codes for medications too - and those don't necessarily have clean mappings to RxNorm. It's possible that more generic (ingredient-level) mappings + HCPCS translations will meet the need, but more investigation is required. Not something we can (or probably should) try to fix in this next release, just a note that there will probably be additional adjustments required after this release is out.
Rob Hausam (Oct 11 2019 at 21:22):
@Peter Muir Yeah, that one is definitely a classic! I'm trying to imagine if anyone has ever used that code, and I'm trying to avoid imagining the situation if they did. :) I agree with you - but Avinash did seem to be making at least some degree of a counter-argument (my interpretation). But probably what you have suggested is most likely to cover what is needed.
Rob Hausam (Oct 11 2019 at 21:27):
@Lloyd McKenzie The most common way that I have used HCPCS codes personally in practice is to document charging for specific medications that were administered in the office - so I didn't even think to mention it specifically. And I agree that they might not always map easily to RxNorm. I'm not quite sure what you are thinking that "more generic (ingredient-level) mappings + HCPCS translations" would look like.
Eric Haas (Oct 11 2019 at 21:32):
The door is closed to looking at any more change requests.
Lloyd McKenzie (Oct 11 2019 at 21:35):
My understanding is that the HCPCS codes reflect a specific administration dose. As such they don't necessarily map nicely to the medication strength level of RxNorm. However, they should theoretically still be expressible at the 'ingredient' level of RxNorm.
Rob Hausam (Oct 11 2019 at 21:40):
That's true. Probably the majority of the time the medication being administered will be from a standard unit dose vial, and when that is the case there likely would be a clean map to RxNorm. But I agree that is not always the case. When it isn't, certainly the ingredient level at least should work, as you say.
Peter Muir (Oct 11 2019 at 21:46):
Avinash and I had further communications to clarify
Also Clem McDonald @NLM.
CQI added comment
/pm
Grahame Grieve (Oct 12 2019 at 00:25):
.. and?
Avinash Shanbhag (Oct 15 2019 at 16:31):
.. and?
@Grahame Grieve It was just @Peter Muir explaining some of the reasons why historical data was needed for some of the quality measure calculations. Nothing pertinent to bring to this thread.
Grahame Grieve (Oct 15 2019 at 17:03):
well, he said he had further communications, but nothing about what came out of them.
Last updated: Apr 12 2022 at 19:14 UTC
