FHIR Chat · CPT Code Modifiers · implementers

Stream: implementers

Topic: CPT Code Modifiers

Larry Shields (Mar 01 2019 at 15:40):

Anyone that is using CPT Codes, how are you storing the Modifiers? From the standpoint of a procedure resource, we are looking at using the Codeable Concept on the Code field on the Procedure but didn't see a good way to capture the Modifier on the Code.

Larry Shields (Mar 01 2019 at 18:02):

Anyone that is using CPT Codes, how are you storing the Modifiers? From the standpoint of a procedure resource, we are looking at using the Codeable Concept on the Code field on the Procedure but didn't see a good way to capture the Modifier on the Code.

Grahame Grieve (Mar 01 2019 at 18:52):

@Ted Klein @Rob Hausam can you comment?

Julie Scherer (Apr 04 2019 at 18:34):

We are also interested in the answer to this questions. @Ted Klein , @Rob Hausam , can you give us guidance on this? Thank you.

Rob Hausam (Apr 04 2019 at 18:52):

I think it is (or probably should be) a simple post-coordinated expression - most likely: <code>-<modifier>

Rob Hausam (Apr 04 2019 at 18:54):

like '23140-52' - that's how the coding manuals and the forms (that I've seen) show it

Grahame Grieve (Apr 04 2019 at 20:29):

this makes sense to me and it would be good to document it here - http://hl7.org/fhir/cpt.html

Robert McClure (Apr 06 2019 at 00:42):

@Rob Hausam @Grahame Grieve How would following that suggestion allow any sort of code system or value set operation to determine validity?

Grahame Grieve (Apr 06 2019 at 21:49):

code system sets compositional = true. We don't have a way to express the actual compositional grammar rules and I can't imagine one, so custom code is required on the part of terminology servers to support the code system.

for value sets, value sets can control whether such compostion occurs or is required if we define a filter that describes the presence of modifier like that (we don't have a generic filter for that). or if it's an extensional value set

Robert McClure (Apr 07 2019 at 19:30):

@Grahame Grieve That sounds like a serious mess. If you allow this then every FHIR terminology server will have issues figuring how to parse things. In the USA this makes use of CPT potentially a disaster in the making.

Grahame Grieve (Apr 08 2019 at 00:06):

I don't know why you say that. Are you saying that we need a general way to represent compositional grammar? Why would trying to do that make it easier to parse CPT codes?

Kenny Blanchette (Apr 15 2019 at 19:11):

We had the same question a few weeks ago, and based on several other threads, we represented modifiers in the Claim resource as claim.item.modifier, using claim.item.procedureSequence to link to the associated Procedure resource.

Bryn Rhodes (Apr 16 2019 at 21:14):

like '23140-52' - that's how the coding manuals and the forms (that I've seen) show it

I have a question on this, are we saying this string '23140-52' is a CPT code? Does CPT have a compositional grammar that supports that?

Grahame Grieve (Apr 16 2019 at 22:15):

we are proposing to document this - would be the same as how ICD-10 works

Yunwei Wang (Apr 17 2019 at 14:21):

Should this be discussed in terminology track?

Carmela Couderc (Apr 17 2019 at 19:01):

Agree with Yunwei that this should move to the terminology track. Should the code system steward be contacted about this topic - The American Medical Association?

Rob Hausam (Apr 17 2019 at 22:33):

I agree with moving further discussion to the terminology stream. And contacting AMA about it probably makes sense (although I don't have a good idea of who at AMA would be interested and available and most appropriate to involve in that).

Robert McClure (Apr 18 2019 at 00:02):

What are we asking the AMA? Even if they agree with a particular structure for adding modifiers into a single code representation, this means any terminology server will either report that any modified code as not in the code system or value set, OR will have to set up a server-specific implementation that supports identifying valid modified codes. Good luck with that occurring in "80%" of terminology servers. This basically turns a strictly managed data type - Codeable concept - into a text string.

Grahame Grieve (Apr 18 2019 at 02:11):

that's already how it works for the other terminologies.

Grahame Grieve (Apr 18 2019 at 02:13):

Coding.text contains a string which may be an expression in a grammar defined by the system. It's been that way since V3 Data types R2 (CD.code), and replaced a crude attempt to define a grammar in V3 data types R1 - which actually only worked right for CPT (perhaps that's the source of the pain?). The grammars are so variable in syntax and semantics that I don't see the point of trying to define a language with which to define the various grammars.

Grahame Grieve (Apr 18 2019 at 02:15):

in my server I (partially) support grammars for ICD-X, SCT, UCUM, jurisdictions, mime types, and languages

Robert McClure (Apr 19 2019 at 20:29):

@Grahame Grieve where is coding.text in the description of coding? Was I wrong in assuming you all were saying that this expression would be placed incoding.code?

Grahame Grieve (Apr 19 2019 at 20:33):

typo. I meant Coding.code

Robert McClure (Apr 19 2019 at 20:33):

And let's assume you really did mean coding.code, then who are the 80% that are creating value sets that support identifying valid expression-based members? Because if this is the expected standard behavior, how will folks, like say CMS, validate submitted bills where the CPT code is expected to only be a subset of all "valid CPT expressions?"

Grahame Grieve (Apr 19 2019 at 20:36):

I'm not sure what the 80% bit is about. Nor am I sure what the problem is for validation. Are you saying that what we are specifying is ambiguous, so that it can't be validated? if so, how?

Robert McClure (Apr 19 2019 at 20:38):

just using this as a dig on the 80/20 - sorry... Yes, my concern is validation, particularly for code systems that are used frequently in value sets where the value set is a subset of all the codes in the code system - hence validation is a requirement. Say like CPT.

Grahame Grieve (Apr 19 2019 at 20:40):

so I understand the grounds for concern, but not the actual concern. What is that we have specified (or at least, agreed to in this topic) that is unclear?

Grahame Grieve (Apr 19 2019 at 21:01):

ok, off-line discussion with @Robert McClure clarified the issue for me:

• current practice is to specify extensional value sets that do not include modifiers (and extensional value sets that include modifiers would be prohibitively large due to permutational explosion)
• current practice is to validate just the base CPT code, and ignore any modifiers
• also people select codes by the same value sets (e.q. quality measures)
• so the simple case, just use the extensional value set to validate the code
• putting the modifier in the Coding.codebreaks the simple case

Grahame Grieve (Apr 19 2019 at 21:03):

I believe that CPT codes may appear in the following places:

• Encounter.type
• Procedure.code
• Claim.procedure.type

Grahame Grieve (Apr 19 2019 at 21:03):

is that list correct?

Grahame Grieve (Apr 19 2019 at 21:07):

Rob is going to clarify here how (and where) CPT codes are represented in CDA

Grahame Grieve (Apr 19 2019 at 21:43):

ok so here's a way to do this. Let's assume that I have a value that is an extensional list of CPT base codes, and it has a URL of http://acme.org/fhir/ValueSet/my-cpt-codes. We bind the element (let's say Encounter.type) to the following value set:

<ValueSet>
  <!-- metadata -->
  <compose>
    <system value="http://www.ama-assn.org/go/cp"/>
    <filter>
      <property value="base"/>
      <op value="member-of"/>
      <value value="http://acme.org/fhir/ValueSet/my-cpt-codes"/>
    </filter>
  </compose>
</ValueSet>

This says: the base element (the non-modifier bit) must be a member of the extensional value set

Making this work requires, on the definitional side:
* that we define the property base for CPT to mean the unmodified code (though we could call it something else, I don't care about the name)
* that we add "member" as an filter.op code (note that we have in already, but it is normative and says that the value is a comma separated list of codes. hence, add a new operator)

Making this work on the implementation side, if you are using a terminology server:
* the terminology server needs to know about the CPT syntax, the base property and the member operator

making this work on the implementation side, if you are not using a terminology server:
* you can decompose the CPT syntax, and the value set syntax

For a non-terminology server implementation, this appears more complex, but as soon as you add the requirement to also validate/select by modifiers.... then it is no longer more complicated. And that seems like an inevitable place to go to me

nicola (RIO/SS) (Apr 20 2019 at 05:32):

We discussed this topic some time ago - https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Procedure.20.26.20CPT.20modifier

My preferences as an engineer to keep CPT code and modifiers separated and structured.
@Grahame Grieve can we have structured post-coordination built-in in Coding (at least for simple cases like CPT):

rt: Procedure
code:
coding:
  - system: CPT
    code: 23140
    coord?:
    - system: CPT-modifiers
       code: 52
       axis: modifier?

Grahame Grieve (Apr 20 2019 at 11:16):

every terminology that defines a post-coordination grammar defines their own; there's no general structure that we can put in coding to handle all the variants (or, correction: the super set of snomed, cpt, icd-X, and the various other post-coordination grammar is wonderfully complex)

Paul Knapp (Apr 24 2019 at 10:33):

@Grahame Grieve @Kenny Blanchette The CPT code could also appear in the productOrService element in ExplanationOfBenefit. or Claim. .item, .item.detail, .item.detail.subDetail as well as the addItems.item, and detail and subDetail. These are the billable or reportable lines in the claim structure so if CPT is being used to code the billable service it should appear on the service line in the productOrService element.

Grahame Grieve (Apr 24 2019 at 10:35):

does subDetail have any use other than for CPT?

Paul Knapp (Apr 24 2019 at 10:50):

CPT is just the service codeset, other jurdisdictions, including the US, use different product and service codesets.
The purpose of detail and subDetail is to provide a tiered structure for tiered products and services independent of what codes are used for those products and services.
Generally CPT covers non-tiered procedures so you may not see it used in a tiered fashion now, but in the future when there is a greater desire for example to link the professional services (often called procedures) with any other procedures or goods (supplied or implanted) then a group may be created at the .item level with the services and products presented at the detail or subDetail level.

Michelle (Moseman) Miller (Mar 04 2020 at 14:49):

Just checking back to confirm the guidance remains using an expression in Procedure.code since I don't see any updates to http://build.fhir.org/cpt.html to confirm that. It might go without saying, but that assumes that the code systems are the same between the code + modifiers. Since we allow modifiers in some non-billing workflows, we do have a few isolated examples where the modifier code system differs from the code's code system (i.e. CPT procedure code + SNOMED modifier and ICD-9 procedure codes + CPT modifiers). If we proceed using expressions, then I assume that means that those modifiers with differing code systems would still need an extension to adequately convey their code system.

Grahame Grieve (Mar 04 2020 at 19:36):

@Corey Smith does AMA define a modifier syntax?

Corey Smith (May 14 2020 at 18:56):

Hi all. I'm clearly a newbie on Zulip and am just seeing this now. Has this question been answered?

Grahame Grieve (May 14 2020 at 19:10):

no @Corey Smith it would be good if it could be

Corey Smith (May 14 2020 at 21:52):

The CPT modifiers are considered part of the CPT code system. @Matt Menning would like reconnect to talk this and other topics @Grahame Grieve

Grahame Grieve (May 14 2020 at 22:02):

right. but do you describe a literal syntax to use when using the modifers. e.g. if the code is XX and the modifier is YY, do you say that the literal format should be XX/YY or XX-YY? I'm going to guess that you've never done any such thing, only defined how they work logically

Vassil Peytchev (May 15 2020 at 03:41):

If I remember correctly, on the paper forms, there was a designated spot for CPT modifier codes. Which makes me think that most systems store the code and modifier in two discrete fields

MaryKay McDaniel (May 15 2020 at 15:21):

Hi all,
depending on where the cpt is used... it can have up to 4 modifiers 'attached'.
15120 99 23 25 62
Epidermal autograft
99 takes more than 1 modifier to describe
23 Unusual Anesthesia
25 Significantly separate svc on same day
62 2 surgeons involved

Eric Whitley (May 18 2020 at 14:20):

MaryKay McDaniel said:

Hi all,
depending on where the cpt is used... it can have up to 4 modifiers 'attached'.
15120 99 23 25 62
Epidermal autograft
99 takes more than 1 modifier to describe
23 Unusual Anesthesia
25 Significantly separate svc on same day
62 2 surgeons involved

I had always been directed that when you express a concept with a modifier, the modifier itself becomes a component of the concept (EX: "15120-99") and that multiple modifiers would be manifested as separate instances of a coded concept. (15120-99, 15120-23, 15120-25, etc.). The relationship was 1:many on the logical model, but 1:1 on the physical.

If the idea is that it's 1:many and that "modifier" is now more a relationship between one coded concept and another where they potentially cross terminologies (CPT term using a paired SNOMED CT term as a "modifier"), then it would seem that you'd treat coded concept has potentially having child coded concepts with some sort of relationship type indicator.

This is really timely for me. We're revisiting this yet again internally and it's been really hard to have this conversation when bridging the clinical and billing mindsets. My personal experience has been that the clinical side sees a thing like a dx as being one instance with multiple coded terms, while the billing side seems to see a single dx as being exploded out to each line item. Within the latter there seem to be two schools within our team - each modifier is a separate line item vs. there's a related modifier array. It's interesting to see how the application of the data have shaped the perception of their structure and relationship.

I'd love to really understand how people are approaching this.

Paul Knapp (May 19 2020 at 17:33):

I would expect, unless there are terminology-specific rules for post-coordination, that the Billing code (CPT) would go in .productOrService and the modifiers would go in .modifiers at the .item, .item.detail or .item.detail.subDetail levels.

Eric Whitley (May 19 2020 at 20:27):

Paul Knapp said:

I would expect, unless there are terminology-specific rules for post-coordination, that the Billing code (CPT) would go in .productOrService and the modifiers would go in .modifiers at the .item, .item.detail or .item.detail.subDetail levels.

Looking at the definition of Procedure on the FHIR documentation. Is it your understanding that only SNOMED CT concepts are appropriate for code?

Grahame Grieve (May 21 2020 at 11:26):

we don't make that rule; there are many business contexts that make their own rules about that, and CPT codes are widely used in procedure.code where we need terminology specific rules for post-coordination of CPT. The way the codes work seems clear, but it seems that there's no standard format to follow

Grahame Grieve (May 21 2020 at 11:26):

so we should define one here. If AMA is ok with that @Corey Smith

Rob Hausam (May 22 2020 at 03:37):

I agree with @Grahame Grieve that we should define the syntax for this (for use in Coding.code). I expect that likely it will be that one or more modifiers are appended to the CPT code separated by a '-' (hyphen). This page gives a brief description. Usually there wouldn't be more than 2 modifiers (but the CMS 1500 and UB-04 forms do allow up to 4). I also think it is important to note that the sequence of the modifiers may be and often will be significant, as it can affect reimbursement. Using a "post-coordinated expression" with a defined syntax in the 'code' element easily supports representing and preserving the modifier sequence (whereas Claim.item.modifier used with Claim.item.productOrService does not).

Grahame Grieve (May 22 2020 at 03:41):

ok. let's go with '-'. We should add that to the CPT page

Stuart Cox (Jan 08 2021 at 21:28):

With up to 4 modifiers, and the position of the modifiers being material, appending with the addition of -mod to the end of the codes leads an explosion of code combinations to be considered. On the consumption side of things (measure logic against the procedure codes), we often need to be able to consider the codes with or without modifiers, depending on the measure requirements. That requires stripping off the modifiers, etc. Also makes binding and terminology checks, code validatation, etc more complex to handle all the permutations.

In my opinion this is not a good implementation method. Appending codes on the end with a -mod is a bit of a hack. Was very surprised to see the modifiers not supported natively with their own CodeableConcept field. Would prefer it be native to the procedure and other resources where CPT codes may be used, but we are planning to add an extension internally as needed to carry modifiers.

Grahame Grieve (Jan 14 2021 at 19:34):

every code system has different semantics around qualifiers/modifiers/post-coordination; we therefore have a choice:

• define a single rough abstraction for all of them that is a variably wrong in all cases
• define a permutational explosion of modifier grammars
• delegate the problem to the code system to define a syntax.

We chose the last as the least worst approach. it does produce a nested syntax that you have to parse, if you want to work with the code, but mostly people just delegate this to a terminology server

Last updated: Apr 12 2022 at 19:14 UTC