Stream: implementers
Topic: slicing by value set
Eric Haas (Jul 21 2016 at 05:17):
I need to say "must use the core 5 race code and you can also have as many additional race codes as you want as translations all from the same code system. So I am assuming I need to slice the us-core-race extension by 2 differene valuesets that are all derived from the same code system. for this I'll need to use the value set reference extension on coding as a discriminator. Does that sound correct?
Grahame Grieve (Jul 21 2016 at 05:18):
no
Eric Haas (Jul 21 2016 at 05:18):
good cause that sounded like a lot of work
Eric Haas (Jul 21 2016 at 05:19):
how do I slice it?
Grahame Grieve (Jul 21 2016 at 05:21):
well, the question is what you want to achieve here
Grahame Grieve (Jul 21 2016 at 05:21):
are you saying that you can't have translations from other code systems?
Eric Haas (Jul 21 2016 at 05:22):
got 900+ race code all from the same code system , 5 of which need to report, the other 895 you may use
Eric Haas (Jul 21 2016 at 05:23):
so first slice required for reporting one of the 5 codes, second slice is optionally for one ot the others
Eric Haas (Jul 21 2016 at 05:24):
I have a pair of valuesets for each slice
Grahame Grieve (Jul 21 2016 at 05:24):
I think that's a yes
Eric Haas (Jul 21 2016 at 05:24):
yes to my original question?
Grahame Grieve (Jul 21 2016 at 05:25):
yes "you can't have translations from other code systems"
Grahame Grieve (Jul 21 2016 at 05:25):
but I don't think that should be a yes
Nagesh Bashyam (Jul 21 2016 at 05:26):
@Eric Browne : Why not have 2 codeable concepts within the race extension
one to report the 5 race codes with the right value set , a second one where they can record as many as they want....using the 0..* coding from the 895+ race codes
Nagesh Bashyam (Jul 21 2016 at 05:26):
meant @Eric Haas
Nagesh Bashyam (Jul 21 2016 at 05:27):
Is slicing really required for this ?
Grahame Grieve (Jul 21 2016 at 05:29):
I'm not sure what rules you're being driven by, but if it was me, this would be a required binding to the 5 codes, and a text note saying that you have translations from the same code system for greater granularity.
Eric Haas (Jul 21 2016 at 05:29):
I'm not clear what you are saying - these codes are all from the same code system? the system is heirarchical the other codes all roll up into one of the 5. the translations would be more granular.
Grahame Grieve (Jul 21 2016 at 05:29):
or if the answer to my question is yes, just fix the code system as well
Eric Haas (Jul 21 2016 at 05:30):
What is the discrimonator?
Eric Haas (Jul 21 2016 at 05:30):
What is the discriminator?
Grahame Grieve (Jul 21 2016 at 05:31):
don't slce it. just a single CodeableConcept
Nagesh Bashyam (Jul 21 2016 at 05:34):
@Grahame Grieve If you use a single codeableconcept - will you bind the element to the value set containing 5 codes or the value set containing the 895+ codes (excluding the 5 aggregate codes) or a valueset with all codes included ?
Eric Haas (Jul 21 2016 at 05:34):
Dragon may have something. Does the freeze apply to us race extensions? (i'll post on comitters)
Nagesh Bashyam (Jul 21 2016 at 05:36):
For reporting purposes - the 5 aggregate codes are used , for other purposes having more granularity is desirable, so systems may capture only the detailed one and roll it up or may capture only the aggregate or both (multiple)
based on their workflows and UI preferences
Lloyd McKenzie (Jul 21 2016 at 05:56):
You have a fixed binding to the 5 codes. As a CodeableConcept, implementers are always free to send as many translations as they like - from any code system, including the one the 5 codes are from. So you don't need to do anything more than that. For greater clarity though, you can add a descriptive note reminding them that they're free to include translations drawing from the same code system that provide greater granularity.
Robert McClure (Sep 01 2016 at 20:38):
@ericHass - See I can’t edit in a proper @-mention
While I assume Lloyd is correct (always!) I'm also confused as to why this would not be solved by using two codeableConcepts in the Race Extension wherein one is bound to a value set with only the 5 blessed codes and the other is bound to a value set with all the codes (you might want to make that value set less the blessed 5). You can use terminology service to detemine which granular code rolled up to the blessed 5. This approach is actually doirectly consistent with how C-CDA is doing it and is the way most consistent with the US race coding expectation as defined in the ONC ISA. It is important to note that in the USA you can have multiple race codes but must report one blessed 5 so the approach I've noted makes that easy.
That said, if you want to pack everything into one CodeableConcept then I don't see an advantage to this and you have a MAJOR disadvantage in that you can not properly capture multiple different race codes because use of the translation demands that the translation be another concept meant to represent the main concept provided so you would not be able to use that to communicate multiple different races.
Grahame Grieve (Sep 01 2016 at 21:26):
could you have translations on those 2 CodeableConcepts? what would they be?
Eric Haas (Sep 01 2016 at 21:29):
@Robert McClure Yes could have sliced it by valueset. But, instead we chose to have all this crazinesslive in the extension as a complex extension. So you have a single extension element in patient that defines it all - two codings, two valuesets. no translations. kind of a deconstructed codeable concept. Will map 1 to 1 to ccda.
Last updated: Apr 12 2022 at 19:14 UTC
