Stream: implementers
Topic: Uncoded procedures from external providers
Daniel Tam (Jun 24 2021 at 23:14):
How are people handling uncoded procedures in FHIR?
My organization receives faxes from other provider systems, with the details of the procedures for the patients we have referred out. However, these faxes rarely contain a CPT or SNOMED code. Yet US Core requires the procedure.code to be filled out (1...1 cardinality).
How are others filling out this code field for US Core when missing a code?
Are you planning to include these uncoded procedures if an external app requests patient data?
Will you provide these uncoded procedures if an external provider requests patient data, such as via an HIE or interoperability connection?
Lloyd McKenzie (Jun 25 2021 at 16:05):
CodeableConcept allows .text for a string. However, to meet the binding requirement, you'll also have to send a generic SNOMED code (likely 71388002) because the binding requires that a code be sent if one applies - and because of the nature of the value set, 71388002 at minimum always applies.
Eric Haas (Jun 25 2021 at 16:43):
We describe this in the latest soon to be published version of us core. Lloyd is technically correct but it adds little value and we recognize this. Extensible bindings allow for text only.
Lloyd McKenzie (Jun 25 2021 at 16:47):
Extensible bindings allow for text only only when what's in the text isn't covered by the value set. If it is covered by the value set, you must send a code to be conformant (regardless of whether sending the code has value).
Daniel Tam (Jun 25 2021 at 18:21):
Thanks Lloyd and Thanks Eric. This is helpful.
@Eric Haas : When will the next version of US Core be published -- and am I able to see the draft of this online? And any guidance on whether or not these should be shared via interoperability connections; or are most health providers not sharing out data if it's uncoded?
@Lloyd McKenzie : I'm also considering setting up a shortened list of CPT's and SNOMEDS that my primary care clinic generally sees, but then calling that code set something like "CPT Guess" or "Possible CPT". The values would mirror actual CPT's and SNOMEDS, but then I could use the code set name to identify this as an uncoded procedure, and to exclude from HEDIS metrics.
What are your thoughts on this approach?
Lloyd McKenzie (Jun 25 2021 at 21:03):
If you put that code in the Procedure.code element, it's going to be treated as the valid code - even if you include an extension indicating that there's some uncertainty. You could send a 'guess' code as a completely separate extension element, but that's not going to satisfy the profile constraint.
Daniel Tam (Jun 25 2021 at 22:22):
Any idea how other health systems are dealing with these in terms of interoperability? My understanding is that many providers are putting in their own "local organization" codes into that field -- which do not necessarily map to CPT or SNOMED. Are providers planning to go ahead and send these non-standard code systems and codes out via interop exchanges? Or would the receiving provider prefer to not receive these if they're uncoded?
Lloyd McKenzie (Jun 25 2021 at 22:26):
By definition, all procedures can be coded as SNOMED because 71388002 says 'Procedure' - and it's hard to say that any local code can't, at minimum, be mapped to that. FHIR binding strengths don't allow for "too expensive to map" or "can't be bothered to map". If it's possible for a human being taking 40 hours per code to figure out a mapping, then the implicit requirement is "a mapping is expected". There are some challenges in that the FHIR mapping strengths don't always communicate what the community that wrote the spec ideally wishes they did - which I think in this case is "do your best".
Daniel Tam (Jun 25 2021 at 22:36):
Thanks Lloyd! Really appreciate your advice. SNOMED 71388002 may end up being my default. I'm going to talk with my team about this SNOMED code, vs using local codes. But the SNOMED 71388002 seems like the safest option right now.
Eric Haas (Jun 25 2021 at 23:50):
here is the updated guidance in US Core 4.0.0 ( ci build ) and we have gone several rounds on this issue and I don't think it is settled.
Lloyd McKenzie (Jun 26 2021 at 02:18):
I've got a serious issue with that guidance. You're trying to relax the rules of the core spec, and IGs can't do that - regardless of how much they might want to. An instance that fails to send a code where there's an extensible binding to a value set that includes an over-arching SNOMED concept is non-conformant with FHIR and this is, by definition, non-conformant with US Core. Implying otherwise is simply misleading the implementer community.
Cooper Thompson (Jun 28 2021 at 13:49):
So your point is that the core spec has an error and needs updating, right?
Cooper Thompson (Jun 28 2021 at 13:54):
That US Core guidance is exactly what the implementer community (based on what I've heard) wants out of that binding type.
Lloyd McKenzie (Jun 28 2021 at 16:04):
My point is that US Core has an error.
Lloyd McKenzie (Jun 28 2021 at 16:04):
US Core can't change the meaning of the binding type
Lloyd McKenzie (Jun 28 2021 at 16:05):
They're free to propose adding a new binding type, though I'm not sure that what you're trying to do is actually appropriate as a binding at all. It seems you're actually trying to establish two different sets of conformance rules - which means two different profiles.
Eric Haas (Jun 28 2021 at 16:14):
These are trade-offs.
Lloyd McKenzie (Jun 28 2021 at 16:18):
Being non-conformant with the core spec isn't a tradeoff - it's being non-conformant. Extensible was defined with a particular purpose in mind. It meets that purpose. It's also normative. IGs can't override it to mean something different.
There are other tools that can allow you to express what you want, be that multiple profiles, warning invariants, best practice invariants and/or hand-wavy documentation in text. But using the 'extensible' binding and saying "in our IG, the rules for it are completely different" is not kosher.
Daniel Tam (Jun 28 2021 at 22:02):
Related to this -- what are people planning in terms of interoperability when they have uncoded procedures? Is it appropriate to include these when you receive a query for a patient's list of procedures from another health system, or from an HIE?
Or are people choosing to exclude these uncoded procedures from external requests?
If you are on the other end, and you are pulling records for a patient via an interoperability or HIE request, would you expect to see the uncoded procedures? Or would you only wish to see the procedures that have an actual CPT / SNOMED code?
Just curious what the community is thinking / expecting.
Vassil Peytchev (Jun 29 2021 at 02:39):
I am not clear how you have "uncoded procedures". I understand that you get a fax with a description of the procedure. Is that a report of a procedure that already took place? What happens next? Does your system record the procedure electronically?
Cooper Thompson (Jun 29 2021 at 13:03):
We include our "uncoded" procedures in the API response, we just don't include a standard code like SNOMED or CPT. We just include an local code (basically just the internal database identifier for our procedure), along with a text property. The local code is meaningless to the world (unless there is pre-coordination with the client), but it allows us to send the procedures (which is important) and still be US Core compliant.
Cooper Thompson (Jun 29 2021 at 13:07):
-
Cooper Thompson (Jun 29 2021 at 13:07):
1..1 with required or extensible binding basically prohibits a server from returning relevant uncoded clinical data. Or at least this is true for non-trivial value sets.
Cooper Thompson (Jun 29 2021 at 13:14):
Unless you use the US Core flavor where the "text" in the CodeableConcept meets the requirement.
Daniel Tam (Jun 29 2021 at 23:40):
Vassil Peytchev said:
I am not clear how you have "uncoded procedures". I understand that you get a fax with a description of the procedure. Is that a report of a procedure that already took place? What happens next? Does your system record the procedure electronically?
Hi Vassil -- the vast majority of faxes that we receive do not have the CPT of the procedure, though it does have a description. It is a report of the procedure that took place. I've noticed the same as a patient -- I rarely see codes in the documentation I receive. We then hand enter the info from the fax or image into the chart (though we are evaluating OCR and machine learning algorithms to do this in the future).
This is different from a C-CDA -- in those cases we receive structured data with the procedure code -- in those cases we have a definitive code from the originating institution, can enter a value into procedure.code, and we have everything we need for quality metrics.
Daniel Tam (Jun 29 2021 at 23:41):
Cooper Thompson said:
We include our "uncoded" procedures in the API response, we just don't include a standard code like SNOMED or CPT. We just include an local code (basically just the internal database identifier for our procedure), along with a text property. The local code is meaningless to the world (unless there is pre-coordination with the client), but it allows us to send the procedures (which is important) and still be US Core compliant.
Cooper, have you received any feedback from the receiving institution on these local coded procedures? Have they stated whether they use these or not, and whether or not they are valuable? Do they simply use the text description, and basically ignore the code if they notice it is a local code?
Vassil Peytchev (Jun 30 2021 at 12:17):
If there is a process to enter the procedure into the chart, it seems to me that at that point you could use a coding tool to add a code - SNOMED or CPT, if possible, or at least a local code, as Cooper suggests.
Cooper Thompson (Jun 30 2021 at 15:29):
Having end users add a SNOMED or CPT code sounds terrible. <Physician burnout>++ . It is much better to have those codes mapped to your procedure records so when a physician orders a procedure, the codes are just there. The issue comes from historical procedures, or unmapped procedures. Many organizations have goals to map all their procedures, but that is a big effort, and includes ongoing maintenance.
Cooper Thompson (Jun 30 2021 at 15:42):
@Daniel Tam - regarding feedback, we 100% expect that receiving institutions won't be able to do anything useful with local codes. I don't expect they are valuable. Unless that receiving institution has a business relationship and pre-coordinates the meaning of the local value set.
Daniel Tam (Jun 30 2021 at 16:22):
Vassil Peytchev said:
If there is a process to enter the procedure into the chart, it seems to me that at that point you could use a coding tool to add a code - SNOMED or CPT, if possible, or at least a local code, as Cooper suggests.
Hi Vassil, we would not want to add a CPT / SNOMED code. The reason is that the procedure was already coded -- we would want the original code from the institution, especially when it comes to quality / HEDIS metrics. Re-coding a procedure, while possible using mappings, would probably not stand up to an audit. We are going to see if the CPT/SNOMED can be pulled from an HIE like CareQuality -- will be trying that in the coming months. In the meantime the local codes would probably work -- we definitely would not have the end user add those -- Cooper is right that would result in physician burnout.
Daniel Tam (Jun 30 2021 at 16:24):
Cooper Thompson said:
Daniel Tam - regarding feedback, we 100% expect that receiving institutions won't be able to do anything useful with local codes. I don't expect they are valuable. Unless that receiving institution has a business relationship and pre-coordinates the meaning of the local value set.
Cooper Thompson : Yep, I agree, the local codes won't help the receiving institution. I was more curious whether the receiving institutions you worked with wanted to know about these uncoded procedures coming from a third party? Or should we as a community avoid returning uncoded procedures when others query our FHIR servers? I suspect it is helpful for receiving institutions to have these uncoded procedures but wanted to see what you had heard.
Cooper Thompson (Jun 30 2021 at 16:33):
Excluding clinical data from an API response just because it is not coded using the value set you want seems like a bad idea. I have the very strong opinion that all data should be returned regardless of the codes available, and that receiving systems MUST have some method of handling un-coded data, because such data exists and is common in the healthcare ecosystem. What systems do with un-coded data is really up to them. Some may treat it as just textual content. Some might log some sort of error or require an end user to do some reconciliation step. It really varies a lot based on the use case.
Vassil Peytchev (Jun 30 2021 at 17:44):
I agree that you would not want to re-code a previously coded procedure. It wasn't clear that the source actually had the information as properly coded discrete data. If that is the case, why on earth are you getting it as a fax? An HL7 v2 interface over HTTPS would work just fine, wouldn't it? Or a CDA document with discrete entries?
Daniel Tam (Jun 30 2021 at 18:36):
Vassil Peytchev said:
I agree that you would not want to re-code a previously coded procedure. It wasn't clear that the source actually had the information as properly coded discrete data. If that is the case, why on earth are you getting it as a fax? An HL7 v2 interface over HTTPS would work just fine, wouldn't it? Or a CDA document with discrete entries?
Vassil: Agreed, a CDA or HL7 v2 would probably be better! But not all health systems use those consistently -- sometimes the provider simply sends a fax, even if they have access to HL7 or CDA's. Also, there are times when we'll get a CDA on the surface but it's just a fax attached. I think it sometimes depends on the individual clinician, if if that clinician is working at a larger health system with access to HL7 and CDA's.
Last updated: Apr 12 2022 at 19:14 UTC
