Stream: terminology
Topic: semantic grouping
David Hay (Dec 19 2016 at 23:45):
Had a question about wanting to be able to group Conditions 'semantically' eg a diagnosis of 'thyrotoxicosis' and 'graves disease' would be represented in a UI as 'hyperthyroidism'. The needs to be independent of the terminology being used. Assuming we have some service that actually does the grouping, the question is how to represent that in FHIR. I was imagining an extension on Condition.code...
Grahame Grieve (Dec 19 2016 at 23:51):
wouldn't it be an extension on Condition, not Condition.code?
Rob Hausam (Dec 20 2016 at 00:01):
Since we've now made Condition.category a 0..* CodeableConcept with an example binding, I think you could use that. The definition for category is just "A category assigned to the condition" and the comments are "The categorization is often highly contextual and may appear poorly differentiated or not very useful in other contexts", so I don't see any reason that you couldn't use it for your use case.
David Hay (Dec 20 2016 at 00:47):
I was thinking of code because it 'specialies' (or generalizes :) ) the code, but not hung up on it. But is category correct? It's not so much as 'kind' of Condition (eg it's still a diagnosis for example) as another Condition.code (sort of)...
Eric Haas (Dec 20 2016 at 04:48):
"The needs to be independent of terminology" So is concept mapping out of the picture?
David Hay (Dec 20 2016 at 16:55):
Would Concept maps help here though? They are more about how equivalent concept are represented in different terminologies rather than 'roll-ups' of more detailed into less detailed concepts AFAIK...
Eric Haas (Dec 20 2016 at 17:50):
Maybe I misiunderstand the issue. When you say "to group Conditions 'semantically' eg a diagnosis of 'thyrotoxicosis' and 'graves disease' would be represented in a UI as 'hyperthyroidism'. " you are rolling up stuff aren't you?
Grahame Grieve (Dec 20 2016 at 19:37):
It it's not a category, why isn't it a translation?
Robert McClure (Dec 20 2016 at 22:17):
I'd lean to what Eric is saying as the best way to do this. @David Hay you seem to want to find some sort of "more general" way of representing a collection of more specific "sub-types" of conditions. I'd suggest using mappings from any code system you want to support into SNOMED CT, then walk up the SNOMED CT hierarchy to a code you like. Then you can display the SNOMED CT code, or use a mapping back to a different code system. You can designate concepts in SNOMED CT as your "target top level" in the hierarchy you want to walk up to via a couple of different methods but essentially it would be a value set of "general conditions".
Grahame Grieve (Dec 20 2016 at 22:57):
right but then David wants to put it in the resource itself, and want's to know where
David Teirney (Dec 21 2016 at 07:33):
The groupings being discussed are defined at https://vsac.nlm.nih.gov/. There are groupings defined by various stewards, with each grouping having a value set made of codes from SNOMED, ICD9 or ICD10. Each grouping appears to be defined by an OID with associated metadata like name, description etc. I'm not actually sure how each group would be modeled as a CodeableConcept though. The OID defines the group so more like a value than a system.
Grahame Grieve (Dec 21 2016 at 08:36):
sounds like a value set, yes.
Robert McClure (Dec 21 2016 at 16:01):
Well, since I came up with the "grouping value set" idea for VSAC, I can tell you why it's there - it was to make initial VSAC development of value sets simplier. Honestly I'm no longer a fan and it confuses the reality that value sets construction can be more complex. This is defined in the VSD HL7 spec and implemented most places including FHIR, where a single value set can have multiple code systems, can include another value set by reference, can include singlely identified concepts plus concepts identified via an expression. Each "clause" can be "locked" to a specific code system version so a value set can include concepts from multiple code system versions. All of that can be included in one Content Logical Definition (CLD) for the value set version.
Initial VSAC development restricted value sets to enumerated lists of singlely specified concepts drawn from one code system version. That is as restrictive a CLD as you can get. To support the creation of a value set with multiple code systems, or to allow the combination of value sets with more specific scope into a larger more general value set, VSAC GROUPING value sets are also created. Grouping value sets in the VSAC can only group other value sets. While humans certainly can review multi-code system grouping value sets and decide they each"map" to a similar scope (and they almost always do in that case), there is no explicit mapping defined in VSAC Grouping value sets.
It makes no sense to me that these value sets would align with a codableConcept. As Graham noted, they are VALUE SETS.
David Hay (Dec 21 2016 at 18:51):
Our plan is to create an extension on Condition (I guess the root) that is of type CodeableConcept and bound to a ValueSet representing the VSAC. Still some challenges to go with determining the content and URL of the ValueSet for which we need to have discussions with the Service Provider who is actually doing the grouping...
Thanks for all the input guys...
David Hay (Dec 21 2016 at 22:01):
Actually - looking further - each 'group' is identified by an OID, so I wonder if an Identifier is a better choice of datatype?
from the datatype page:
"If the identifier value itself is naturally a globally unique URI (e.g. an OID, a UUID, or a URI with no trailing local part), then the system SHALL be "urn:ietf:rfc:3986", and the URI is in the value (OIDs and UUIDs using urn:oid: and urn:uuid: - see examples)."
Rob Hausam (Dec 21 2016 at 22:36):
I'm not thinking that really makes sense, David. From what I can gather from the prior discussion, I think you are describing another terminology to "group Conditions 'semantically'" (and semantic grouping at various levels is what terminologies are mostly about). So I don't think that being "independent of the terminology being used" is correct - this is just another terminology (undoubtedly at a different level of granularity) that you want to use alongside the other terminology(ies) already being used. So I think, as Grahame said, that if it isn't a category then it would be a translation, and it can be just another Coding in the Condition.code codeableConcept. And ConceptMap can represent the mappings/translations, if needed. I'm still not seeing the need for an extension.
David Hay (Dec 21 2016 at 22:41):
So there is a 'terminology' that is the set of VSAC groups, and the OID is the 'code' within that 'system' ? and it is represented by another Coding{} within the Condition.code value?
David Hay (Dec 21 2016 at 22:41):
(this stuff hurts my head :( )
Grahame Grieve (Dec 21 2016 at 22:44):
I think you're saying that what what you want to identify is a value set that contains the Condition.code, because you do some [thing] based on which value set it is in?
David Hay (Dec 21 2016 at 22:45):
yes - that's what pointed us at identifier (plus the fact that they use OID's to represent the value set)...
Grahame Grieve (Dec 21 2016 at 22:46):
so I don't think that's a coding in Condition.code. But you were unclear, earlier, about what you were actually recording, so I think that's where the confusion comes from
Grahame Grieve (Dec 21 2016 at 22:47):
you can use either Coding or Identifier this; technically, this is an 'appelation' - concept of which there is only one instance.
Robert McClure (Dec 21 2016 at 23:03):
@David Hay , I think we'd be better off if you provoded an explicit example/use case. I'm still not convinced I'm seeinga discussion that fits together. Your "terminology of OIDs" comment worries me, you should not think of things that way. Also you seem to be focused on what is in VSAC and I'm deepy familiar with that yet am confused as to what you think you'll be doing there. I don't think there is anything in VSAC that fits whatyou are talking about. Are you suggesting you'll be making value sets in VSAC to meet the need you describe?
Also, to be clear on "translation" vs "mapping", a code from a different code system that is more general should not be considered a "translation" unless there is no more exact match available, and translations are best thought of when changing languages. Yes, they can be used generally when sending two different code system concepts for a single instance exchange, but when you create a defined set for multiple codes to codes in another code system for use across multiple instances - you should represent that using a mapping, not a series of translations.
Grahame Grieve (Dec 21 2016 at 23:06):
much confusion of instance and definition here. if you are representing what concepts are equivalent, that's what a concept map is for. If you've done a translation using a concept map, then it *may* be appropriate to add it into the translations in a CodeableConcept. There is no way to define whether that's valid or not in a simple fashion; all we can do is provide guidelines, some of which Rob has above.
Grahame Grieve (Dec 21 2016 at 23:07):
but David's doing something else
Grahame Grieve (Dec 21 2016 at 23:08):
using a terminology service to test membership of a specific code against multiple value sets, and then wanting to remember which value set(s) it is in so as to avoid having to the do the set membership test (computationally expensive) repeatedly.
Grahame Grieve (Dec 21 2016 at 23:08):
the fact that the value sets are on VSAC is only relevant in as much as part of the question is 'how would the value set be identified'
Rob Hausam (Dec 21 2016 at 23:17):
Yes, that seems to be what David is doing. And with that understanding, if that's actually something that needs to be done, then I do agree that it should be an extension. And for representing the value set OIDs, I think that Identifier probably is the best choice.
David Hay (Dec 22 2016 at 00:07):
Hmm I will try to be clearer.
Our system receives v2 messages containing Problems from different sources, and sometimes the same problem is represented in different ways at different levels of detail. For example one source might have the SNOMED code 389145006 (Allergic Asthma) and another may use 195967001 (Asthma - disorder). Then a third sends 493.0 (ICD-9). They're all representing Asthma, so we want to be able to show in a UI as just 'Asthma', and allow the user to drill into details if needed. We're calling this (rightly or wrongly) 'semantic grouping'.
Our current thinking is that we use an external service that tells us that all these 3 conditions are very similar - similar enough to be 'grouped' as a single line in a display. When the client requests the patients conditions, the server sends all 3 resources, but the 'group' to which each Condition belongs is included in the resource (possibly as an extension) so that the UI is able to generate a summary display with just the group name showing, and support 'drill down' to more detail.
The external service potentially uses the VSAC set of valuesets (or some other) to determine which group each Condition belongs to (if any). In the example above, there would be a group/ValueSet (with the name Asthma - identified by an OID in this case) and all of the 3 conditions (2 SNOMED, 1 ICD) are members of that ValueSet. Thus the service can 'assign' each Condition to that group.
We're not tied to VSAC - though that seems to have something close to what we're after - we were looking at https://vsac.nlm.nih.gov/. I can sent a screen shot if that will help.
Absolutely open to better sources / alternatives, and we do need to discuss this in detail with our service provider.
Is that better?
Grahame Grieve (Dec 22 2016 at 00:23):
how many different groupings might you have? sounds like 1000s
David Hay (Dec 22 2016 at 00:46):
I'm not sure - I believe it's in the hundreds rather than the thousands - in our case it's really only the common ones that we'd want to group in this way.
Grahame Grieve (Dec 22 2016 at 00:47):
I said above that there's no hard and fast rules for what should and shouldn't be translations. This is in the grey zone. But it's probably more convenient to use an extension so you don't have to sort through the translations
David Hay (Dec 22 2016 at 00:55):
thanks, appreciate the input...
Rob Hausam (Dec 22 2016 at 01:04):
Yeah, I think the way you're describing it, it could go either way. But you actually are using the "semantic grouping"as if it is a terminology itself, with the individual grouping value sets serving as the mappings. :)
David Hay (Dec 22 2016 at 01:09):
Yes - that was my initial thought, that the 'set' of all possible groups was a 'terminology', and each of the groups equated to a single 'concept' within that terminology - but it all got a bit too hard!
Rob Hausam (Dec 22 2016 at 01:09):
Understand!
David Hay (Dec 22 2016 at 02:32):
and my last question (in this stream :) )
If we use Coding (because it has a display property), then the code will be the OID and the system will be 'urn:ietf:rfc:3986' - right?
Grahame Grieve (Dec 22 2016 at 02:34):
yes. though the OID has to be urn:oid:[oid]
David Hay (Dec 22 2016 at 02:35):
ta
Robert McClure (Dec 22 2016 at 19:52):
Ok - I understand better the use case. Honetly I'm uncomfortable with the implicit clinical knowledge you are assuming will be correctly crafted when creating these "semantic groupings" and you've not been clear as to how you also might need to include multile codes from a single code system. There are 100s (1000s?) of more detailed SCT descendant concepts below asthma (195967001) in SCT - would your value set include all of them, plus similar sets from ICD? I'd have to assume it would. That said, the way VSAC (and any VSD-compliant system) would do this is to asign an identifier (OID for VSAC) to the "grouping" value set (remember, in some systems, and eventually VSAC - maybe 2017 - you could put all of this into a single value set and not have to "group" other value sets if you don't want to,) _and_ give that "semantic collection" value set a name. Given what you have described, you would then send this value set name and the identifier as "the general way of saying all the things about this condition." But I'm still worried this is not the best solution and it has the potential to improperly treat the value set as "a concept". I can't say this too strongly - IT IS NOT! I see that Rob H and Graham seem to be encouraging you to think that way but I would strongly disagree and urge you to not proceed in this way - it's not maintainable, confusing, and improper based on all current practices. @David Hay perhaps we should talk by phone. I'm fine with creating value sets that collect similar detailed concepts - all the asthma concepts across multiple code systems - and then collect condition instances based on finding that they all describe a condition inside that value set. So my concern is how you frame what you are doing I think, more than the approach you use. But there are some gatcha's, like how to name that value set and how you treat that name in systems - it's NOT a concept.
Grahame Grieve (Dec 22 2016 at 20:05):
why is it not concept? I think you should say 'it is not a well maintained concept'
Robert McClure (Dec 22 2016 at 20:16):
Because a "Codable.concept", to my understanding those must come from a code system. Code systems are "defined collections" that have a common stewardship. Now I'll admit that FHIR is throwing lots of stuff under the bus and one might argue that "all OIDS are in a common collection and are stewarded" but I'd disagree at the moment. I don't see why this has to be a FHIR concept for the process to work - show me that it MUST be and I'll consider the impact.
Grahame Grieve (Dec 22 2016 at 20:22):
I think you are talking about a defined collection that has a common stewardship, actually - a list of value set OIDs. You might well argue that this is a use of a collection for which it is not intended - and I'd agree. But i'm not saying it has to be a concept, or that is the only way to do it.
Last updated: Apr 12 2022 at 19:14 UTC
