Stream: implementers
Topic: Decision support tool
Erich Schulz (Jun 28 2016 at 04:01):
Hiya - this one is for @Donna Truran but I think it may interest others as an interesting test case:
Erich Schulz (Jun 28 2016 at 04:01):
http://riskcalculator.facs.org/RiskCalculator/index.jsp
Erich Schulz (Jun 28 2016 at 04:01):
this took is getting a lot of buzz from my colleagues currently
Erich Schulz (Jun 28 2016 at 04:02):
several have indicated that they will take the time while with patients to sit down and enter in the data to generate the risk profile for proposed procedures
Grahame Grieve (Jun 28 2016 at 06:59):
they are severely in violation of their CPT license, but ok. Other than that we could FHIR-ise that - worth doing as an example, @Bryn Rhodes ?
Erich Schulz (Jun 28 2016 at 07:05):
CPT license?
Erich Schulz (Jun 28 2016 at 07:06):
oh the procedure codes...
Erich Schulz (Jun 28 2016 at 07:06):
drives me bonkers when folk try to own the ontology
Grahame Grieve (Jun 28 2016 at 07:07):
y. I haven't got a license for it yet, since i don't live in USA
Donna Truran (Jun 28 2016 at 08:18):
Interesting.... but not what excites me as an example of CDS. This resembles a lot of 'eligibility for xyz", used commonly in CRT cohort identification and sign up protocols.... and to be quite narrow (and self interested) about it, there is very little dynamic use of terminology here (and nothing of SNOMED) , mostly radio buttons yes/no choices and only one 'descriptor' that is free to vary, and that's a proscribed drop down list... (and of CPT..... ) I'm sure it's useful, but so are a lot of 'guidelines and protocols' whether they are in widgets like this or not
Erich Schulz (Jun 28 2016 at 08:19):
so that is our challenge :-)
Erich Schulz (Jun 28 2016 at 08:20):
but even to do something "boring" like this is very hard
Erich Schulz (Jun 28 2016 at 08:20):
the challenge is to be able to express/derive those values from FHIR observation/condition resources
Erich Schulz (Jun 28 2016 at 08:20):
very hard
Erich Schulz (Jun 28 2016 at 08:23):
being able to do the automated transformation would tax FHIR, CQL and snomed/whatever to the limit
Donna Truran (Jun 28 2016 at 08:25):
Not boring if someone finds it helpful.... but I think it's possible (perhaps not immediately probable tho') to achieve something a bit more sophisticated.... I'm not yet convinced it's as hard or as taxing as you imagine
Erich Schulz (Jun 28 2016 at 08:35):
two elements that leap out at me as challenging to reliably extract are "Disseminated Cancer" and "Hypertension requiring medication" - but on second look I agree that none is too bad
Erich Schulz (Jun 28 2016 at 08:35):
the challenge is to build a system that reliably captures the unpderpinning data
Pascal Pfiffner (Jun 28 2016 at 11:16):
While you can't fully automate filling an NSQIP, there's a lot that can be prefilled. We're doing that in a medical calculator tool on iOS, "LOINCifying" the input we can and leaving the rest to fill manually.
Erich Schulz (Jun 28 2016 at 11:21):
my thought is to try use CQL to attempt to standardise (and make shareable) the necessary transformations
Erich Schulz (Jun 28 2016 at 11:23):
and i get excited (i need to get out more) about idea of using this kind of risk-stratification dataset allow comparison between different institutions
Pascal Pfiffner (Jun 28 2016 at 11:25):
Yes, that use-case is definitely exciting!
As for NSQIP it will be rather hard to automate "ASA Class" of a patient, though, if that's not been clinically evaluated.
Erich Schulz (Jun 28 2016 at 11:26):
well its not hard really...
Erich Schulz (Jun 28 2016 at 11:26):
(that's my day job)
Erich Schulz (Jun 28 2016 at 11:27):
if you can quantify someones functional capacity that goes a long way...
Erich Schulz (Jun 28 2016 at 11:28):
but I guess your probably looking at a few hundred lines of CQL...
Bryn Rhodes (Jun 28 2016 at 14:31):
@Grahame Grieve Yes, that would be a great example, I'll work something up.
Grahame Grieve (Jun 28 2016 at 19:41):
thx!
Supriya Arora (Jul 27 2016 at 21:14):
Hi.. I am new to FHIR standards. I need urgent help to create CLAIM FHIR request. I am facing issue to co-relate procedure (CPT codes) with diagnosis(ICD Codes) while create the sample request.. Apprciate help.
Paul Knapp (Jul 27 2016 at 21:19):
Each Claim line item, claim.item, contains the billing code, claim.service, and a link to the relavent diagnosis, claim.item.diagnosisLinkId which matches by value into the claim.diagnosis list in the body of the claim (claim.diagnosis.sequence == claim.item.diagnosisLinkId).
Supriya Arora (Jul 27 2016 at 21:22):
Thank you so much Paul.. do you have any sample json for claim which has ICD and CPT code co-related...
Supriya Arora (Jul 27 2016 at 21:27):
I am using STU3 version and don't see billing code in item
Paul Knapp (Jul 27 2016 at 21:47):
claim.item.service
Paul Knapp (Jul 27 2016 at 21:48):
I'll try to put up an example on the current build in the next few days or on the weekend - can you send me some sample ICD and CPT combinations
Kenny Blanchette (Mar 07 2019 at 21:35):
@Paul Knapp Thanks for the explanation above. I know this thread is old, but I had a follow-up question.
What is the conceptual difference between claim.item.service and claim.procedure.procedure?
My current understanding is that these elements would often reference the same code for many types of billed services; e.g. a new patient visit (CPT 99201) where the provider performed a colonoscopy (CPT 44389). Is it correct that the primary case where you would include something in claim.item.service and not claim.procedure.procedure is when the billed code is not semantically a procedure (e.g. many CPTII codes)?
Andy Stechishin (Mar 09 2019 at 22:22):
@Kenny Blanchette if you look at R4 the claim.item.service is now called productOrService, as well the description has also been improved, so hopefully this will make the differentiation more clear.
Even when the claim.items are only for services there may not be a one to one correlation between the procedure and the claim.item.productOrService. The claim.procedure.procedure[x] is the clinically significant item whereas the claim.item.productOrService is the billing code from the fee schedule. As an example, the procedure would differentiate between a laproscopic versus an abdominal appendectomy whereas there may be only a single billing code for all appendectomies. This will also vary from payor to payor and jurisdiction to jurisdiction.
Kenny Blanchette (Mar 11 2019 at 19:30):
Thanks @Andy Stechishin - that helps!
David Riddle (Jun 24 2019 at 18:01):
@Andy Stechishin
Even when the claim.items are only for services there may not be a one to one correlation between the procedure and the claim.item.productOrService. The claim.procedure.procedure[x] is the clinically significant item whereas the claim.item.productOrService is the billing code from the fee schedule. As an example, the procedure would differentiate between a laproscopic versus an abdominal appendectomy whereas there may be only a single billing code for all appendectomies. This will also vary from payor to payor and jurisdiction to jurisdiction.
On claims for physician billing in the U.S., is it appropriate to include all of the line level HCPCS codes as claim.item.productOrService instances and not include them in claim.procedure.procedure[x]? Or does each line level HCPCS code need to be semantically evaluated to determine if it is ‘clinically significant’ and should instead (or also) be included in claim.procedure.procedure[x]? In the @Kenny Blanchette example, should colonoscopy (CPT 44389) be considered ‘clinically significant’ and thus only be include/expressed as claim.procedure.procedure[x] vs. claim.item.productOrService? Or is it acceptable to just map any line level HCPCS code only to claim.item.productOrService, agnostic of the specific code’s meaning?
Andy Stechishin (Jun 25 2019 at 16:44):
Hi @David Riddle, the quoted section was to answer the question, why would these items be different. The question "Can these two things contain the same value?" would be answered with YES. Next let me state, I am not authoritative on the coding for products or services for professional claims in the US but I think the answer can be derived from going back to the primary purpose of the claim which is to request a payor to determine the amounts to be reimbursed for a list of products and services. This list of products and/or services is in my experience finite (you don't get to send your own made codes, there is a list and it is THE list). The payor specifies the list, though a national organization is often responsible for the definition of the list, the payor will adopt and then further restrict if necessary. The list may be very broad such 'all of HCPCS and ICD-10-PCS' or it could be very specific such as 'these 200 values from ICD-10-PCS'. The Claim.item.productOrService is the attribute that will most tightly constrained (and may be further constrained by business rules tied to practitioner, their specialties and their location). The Claim.procedure is additional information for the items on the Claim, it provides context. It tells the story to enable you to understand the individual items. If I could provide an analogy, submitting a list of items: 10 hours labour, 2 boxes of nails, and x sheets of plywood you may not have enough information. But if I provide a 'procedure' of 'Build a garden shed', you can understand the list of claim items.
The question of whether you would repeat the HCPCS code that appears in the Claim.item.productOrService in the Claim.procedure can only be answered by the entity that you are submitting the Claim to. If you are submitting for adjudication purposes, and the payor requires the inclusion of Claim.procedure, then you would provide the values that you have, even if it is a duplicate. To provide a ludicrous example, if the entity that you are submitting the Claim to requires the colour of the shoes the practitioner was wearing when the services were provided, you will submit that information. Fortunately, I have not come across any payors that have added practitioner shoe colour to their adjudication engines, so we don't submit it and if you did try, I think the payor might reject the claim.
Hopefully this addresses your questions but don't hesitate to follow up
Last updated: Apr 12 2022 at 19:14 UTC
