Stream: implementers
Topic: Representing CPT codes for Encounters
Kenny Blanchette (Jul 31 2018 at 16:56):
Which Encounter attribute is most appropriate to include the billed CPT code for a given encounter? Our original intent was to include this as Encounter.type, which is a CodeableConcept that can support multiple CPT codes for an encounter. However, in the QDM->QICore mapping (http://build.fhir.org/ig/cqframework/qi-core/Encounter.html), the "EncounterPerformed.code" QDM, which typically requires a CPT code in many quality value sets, maps to Encounter.class. This attribute has a preferred binding to ActEncounterCode and can only support one code.
Is it more appropriate to include a CPT as part of Encounter.type? (CC @Bryn Rhodes )
Lloyd McKenzie (Jul 31 2018 at 17:50):
Charges are typically captured as separate instances using ChargeItem. (A given encounter could well have numerous charges associated with it.)
Paul Knapp (Jul 31 2018 at 17:52):
And a suite of ChargeItems may be rolled into a single billing code and therefore line item at the time of billing.
Bryn Rhodes (Jul 31 2018 at 18:26):
Yes, but for quality measurement using QDM, the CPT code is often used as the "code" in the Encounter, Performed. There is a tension in the QI-Core mapping between the way things are done now with quality measures, and the way we'd like to do them that aligns better with how data is actually stored in systems. We talked quite a bit about whether to use "class" or "type" in Encounter, but settled on "class" because it's more conceptually correct. However, it may be the "type" is more practical?
Bryn Rhodes (Jul 31 2018 at 18:35):
@Kenny Blanchette would it make sense to go with "type" for now and submit a tracker for the QI-Core mapping with a link to this discussion?
Kenny Blanchette (Jul 31 2018 at 18:42):
Thanks @Bryn Rhodes My perspective is that "type" makes more sense based on the current attribute definitions in QI-Core v3. Again, namely that "class" has a preferred binding to ActEncounterCodes and only supports a cardinality of 0...1. The "type" attribute is defined more flexibly to allow implementers to codify encounters as required by the use case (in this case, the quality value sets).
Kenny Blanchette (Jul 31 2018 at 18:42):
I'll submit a tracker for this change
Bryn Rhodes (Jul 31 2018 at 18:50):
Thanks!
Kenny Blanchette (Jul 31 2018 at 19:39):
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=17577
Trip Pognant (Nov 15 2019 at 19:00):
We are trying to represent balance responsibility at the ChargeItem level. For example, if we post a charge for $100 and the poster set the a $10 copay charge for that line item we are looking for a way say the insurance is responsible for $90 and patient responsible for $10. Any thoughts? We are using STU3 but creating extensions to mirror what may be available in 4. Thanks!
Grahame Grieve (Nov 15 2019 at 19:18):
sounds like an extension to me?
Brian Postlethwaite (Jan 30 2020 at 08:43):
@Paul Knapp isn't this done during the item processing to create an invoice or claim etc to go to the various people?
Last updated: Apr 12 2022 at 19:14 UTC
