Stream: conformance
Topic: Concept Map Resource
Grahame Grieve (May 18 2016 at 07:05):
Michael and I spent some today at the Australian terminology connectathon working on ConceptMap
Grahame Grieve (May 18 2016 at 07:06):
there's a very definite problem with ConceptMap related to size - we repeat system for both source and target codes every time.
Grahame Grieve (May 18 2016 at 07:06):
if you have a map of 20000 elements.... this is pretty exorbitant.
Grahame Grieve (May 18 2016 at 07:07):
we could sort this by grouping mappings into source/target system pairs
Grahame Grieve (May 18 2016 at 07:07):
or we could define default source and target systems
Grahame Grieve (May 18 2016 at 07:07):
either of these would make a large difference for large concept maps
Grahame Grieve (May 18 2016 at 07:08):
or we could manifest the systems - give them codes, or even set up a prefix system for the codes
Grahame Grieve (May 18 2016 at 11:30):
Further, I'd like to relax the rules for $translate and let the client just specify target system, not target value set. And no source valueset
Peter Jordan (May 18 2016 at 21:24):
That last point makes sense to me as much of the concept mapping we require in NZ is at the Code System, rather than Value Set, level.
Grahame Grieve (May 18 2016 at 21:55):
well, don't be so sure. You can map at the level of the code system by using the value set for the whole code system, but many maps are narrower in scope - we've mapped the codes we used, at our granularity.
Grahame Grieve (May 18 2016 at 21:55):
what kind of maps do you have?
Peter Jordan (May 18 2016 at 22:13):
Read to SNOMED CT; NZMT to a SNOMED CT Extension (in design) and mapping between 3 versions/levels of Ethnicity coding. SNOMED CT to ICD-10-AM would be another if/when developed. There are plenty of others and Code System, rather than Value Set, is more commonly-used nomenclature in the NZ-specific terminologies.
Grahame Grieve (May 18 2016 at 22:48):
can you share any of these?
Grahame Grieve (May 18 2016 at 22:59):
Alternatively, @Michael Lawley proposes a csv format for concept map
Grahame Grieve (May 18 2016 at 22:59):
any thoughts about that?
Grahame Grieve (May 18 2016 at 23:00):
anyone interested in this can look at http://local.healthintersections.com.au:960/open/ConceptMap/3395ca80-a57d-4f2e-a158-4dbaad17fe to get a sense of the scale involved
Peter Jordan (May 18 2016 at 23:29):
The Read to SNOMED CT maps were developed in the UK by HSCIC (NHS Digital) and can be found at https://isd.hscic.gov.uk/trud3/user/guest/group/2/pack/9/subpack/9/releases (you need to register first). These are genuine SNOMED CT artifacts. The other stuff is under design/construction. That link appears to be broken, but much might depend on the size of the mapping exercise at hand - whether one is trying to do small numbers of translations in one exchange or passing the entire map to a client for local processing. In the later case, CSV might be preferable - but would there be a common structure within that format?
Michael Lawley (May 30 2016 at 00:57):
@Grahame Grieve Anything further on the idea of default source/target systems or (my preference) grouping mappings into source/target pairs?
Grahame Grieve (May 30 2016 at 00:59):
no but let's push that along this week with the intent to provide a proposal for vocab call next week
Grahame Grieve (May 30 2016 at 01:01):
we could:
A) group mappings into source/target system pairs
B) define default source and target systems
C) manifest the systems - give them codes
C.a) set up a prefix system for the codes and use a qname for the codes
Rob Hausam (May 30 2016 at 01:03):
The next Vocab call is a week from this Thursday (9th) - we had one this past Thursday
Grahame Grieve (May 30 2016 at 01:03):
which is best depends on whether we care to make product/dependsOn efficient as well
Grahame Grieve (May 30 2016 at 01:05):
there's also my proposal: to change from ConceptMap.element.target.dependsOn.element : uri to ConceptMap.element.target.dependsOn.property : uri where property is a property defined in a code system resource (e.g. system#property)
Michael Lawley (May 30 2016 at 01:05):
A with a single group gives the "same result" as B (put another way, A is a generalisation of B) and A is also similar to the way ValueSet.compose.include works
Grahame Grieve (May 30 2016 at 01:06):
so A has an ordering implication that b doesn't have - under b, you can order the mappings anyway you like, but under A, you have to group them
Grahame Grieve (May 30 2016 at 01:07):
So A is not a generalization of B, because it *defaults* (Unless you think A should involve defaults as well, which I didn't mean)
Michael Lawley (May 30 2016 at 01:08):
I assumed A meant each group has fixed source/target systems
Grahame Grieve (May 30 2016 at 01:08):
right. so it's different to B which involves defining *defaults*
Grahame Grieve (May 30 2016 at 01:08):
A would be more efficient than B for mixed maps, but would impose order implications
Grahame Grieve (May 30 2016 at 01:09):
C or D handle the dependsOn/product better
Michael Lawley (May 30 2016 at 01:09):
I don't understand where order comes in? CM's don't have order AFAIK
Grahame Grieve (May 30 2016 at 01:10):
in the existing approach, you can order the mappings in any order you want. In (A) you have to firstly group by source/target, then you can map in any order you want
Michael Lawley (May 30 2016 at 01:11):
mm, then I would have A use defaults rather than fixed (so an individual element can override the system)
Grahame Grieve (May 30 2016 at 01:12):
that starts to sound pretty complicated to generate efficiently then. I can group stuff together by ther default, but then override...
Michael Lawley (May 30 2016 at 01:12):
So a single group can act exactly as the current approach does, but also with the addition of B-like defaulting
Michael Lawley (May 30 2016 at 01:13):
The terminology server can re-org things (internally only) itself (make it all explicit, for example), if it needs efficiency / optimisation
Michael Lawley (May 30 2016 at 01:15):
I still don't have a good handle on dependsOn to evaluate that, but I can see product also has potential verbosity
Grahame Grieve (May 30 2016 at 01:16):
well, they have very overlapping use cases.
Michael Lawley (May 30 2016 at 01:16):
How does C scale? C.a (D) could probably be applied in many places, but I worry about it being like the XML namespace mess
Grahame Grieve (May 30 2016 at 01:18):
well, I think C.a is quite a bit more scoped that XML namespaces, so doesn't have the capacity to be quite as big a mess. But there's something to worry about, yes
Grahame Grieve (May 30 2016 at 01:19):
as for how C scales - it's not so effective, because you still have to have system = [code] but code is much shorter than URL. but A and B are more efficient again for target and system
Rob Hausam (May 30 2016 at 13:09):
Not sure where we're landing with this? B seems probably simplest, A is more flexible. Not sure about C and C.a, but they would work. Are you thinking of proposing all equally for discussion, or first state a preference?
Grahame Grieve (May 30 2016 at 13:10):
I'd like to take a single proposal to vocab
Grahame Grieve (May 30 2016 at 13:10):
but we haven't landed anything. I guess I should do some stats...
Rob Hausam (May 30 2016 at 13:15):
I agree it would be best to bring a single proposal
Grahame Grieve (Jun 02 2016 at 22:02):
to push this along a bit, I prepared a few examples, at http://www.healthintersections.com.au/conceptmap-alternatives.zip
Grahame Grieve (Jun 02 2016 at 22:07):
A) group mappings into source/target system pairs = 45% volume reduction
B) define default source and target systems = 45% volume reduction
C) manifest the systems - give them codes = 25% volume reduction
C.a) set up a prefix system for the codes and use a qname for the codes = 43% volume reduction
defaulting the relationship to 'equivalent' - a further 14% volume reduction
Grahame Grieve (Jun 02 2016 at 22:07):
that's in XML. JSON numbers would be similar
Grahame Grieve (Jun 02 2016 at 22:07):
I prefer the prefix system, after seeing it in practice
Grahame Grieve (Jun 02 2016 at 22:10):
so, I'd bring the following proposal to vocab:
- change ConceptMap.element.target.dependsOn.element to ConceptMap.element.target.dependsOn.property to remove the dependency that refers outside the terminology system
- introduce a prefix system to concept map to reduce the size of the final resource
- default the relationship to equivalent to reduce the size of the final resource
Michael Lawley (Jun 03 2016 at 00:47):
I think A and B work better for editing - that is, for my ConceptMap editor it would be much simpler to expose default source & target systems in the UI than to clutter it with explicit ones for every code
Grahame Grieve (Jun 03 2016 at 00:47):
wouldn't all options be behind the UI?
Michael Lawley (Jun 03 2016 at 00:53):
With A, I can easily display a panel per group, with a source and target system field at the top, then a table of code-equiv-code mappings; much easier to read & interpret & is information-dense.
With current and C, because ever row in the mapping table could have different source/target systems, I need to display/edit them there & that consumes lots of screen realestate; information-sparse
Grahame Grieve (Jun 03 2016 at 00:55):
I think that you're saying that (A) is a useful constraint for authoring systems, and that it's better, from a user pov, to group them, than to allow arbitrary order
Grahame Grieve (Jun 03 2016 at 00:55):
so what would you do if you were importing a spreadsheet that contained mappings in arbitrary order with intermixed source/target?
Michael Lawley (Jun 03 2016 at 03:52):
Good question, and one we will natirally face. I think we'd just auto-group them
Grahame Grieve (Jun 08 2016 at 22:02):
of course, you could just have a group for each. That would be as efficient as it is now
Grahame Grieve (Jun 08 2016 at 22:03):
so the problem with grouping system/target is that it offers no efficiency for dependsOn/product maps. I guess we decide not to worry about that so much
Grahame Grieve (Jun 13 2016 at 23:39):
One problem with the re-org of ConceptMap: you must nominate a system when you are saying 'unmatched'
Michael Lawley (Jun 13 2016 at 23:57):
That seems maybe okay - you're saying "unmatched in this system", but if there are multiple systems in play does that require you to make separate unmatched claims for each system?
Grahame Grieve (Jun 14 2016 at 00:05):
yes that's the problem
Michael Lawley (Jun 14 2016 at 00:42):
Regarding the vocab minutes - I would dispute that the common equivalence relationship is 'equivalent' -- in my experience with 'in the wild' maps, the much more common relationship is 'inexact'.
Michael Lawley (Jun 14 2016 at 00:42):
re unmatched, what about a group with no default system?
Grahame Grieve (Jun 14 2016 at 02:09):
well, maybe. if you have no target system, can you have targets?
Michael Lawley (Jun 14 2016 at 03:45):
no, you can't, so all entries would be source-only.
however, I'm wondering about the use-case of recording that a target code is unmatched -- no source system (or code)
Grahame Grieve (Jun 14 2016 at 03:53):
I don't think we have that case
Grahame Grieve (Jun 14 2016 at 22:49):
back to Concept Map - should we rename "element" to "concept" now that we scoped ConceptMap to terminologies?
Lloyd McKenzie (Jun 14 2016 at 22:59):
So if I want to map Questionnaire's questions to a set of data elements, I'd need to use StructureMap?
Grahame Grieve (Jun 14 2016 at 23:04):
I'm not sure about that. I considered that when looking at this, and we've always said that the models and data elements are a 'vocabulary'
Grahame Grieve (Jun 14 2016 at 23:05):
further, we've said that if all you're doing is establishing equivalence, then you're mapping concepts, and so the faciliites that ConceptMap have are appropriate for that
Grahame Grieve (Jun 14 2016 at 23:06):
but we could formalise that notion in the resource, or somewhere - that is, how to treat structure definitions and data elements as a code system
Peter Jordan (Jun 15 2016 at 08:05):
As we're mapping concepts, "concept" appears a better match, than "element", for a property that's described as the "Mappings for a concept from the source set".
Michael Lawley (Jun 16 2016 at 01:29):
I'm not sure why you'd choose 'concept' - this is the actual mapping relationship which references the source and target concepts; I would be inclined to call it 'relationship'
Michael Lawley (Jun 16 2016 at 01:35):
I'm also becoming concerned about the need to represent maps where the source / target is a (potentially large) set of concepts. The use-case I see is one where the map represents some kind of aggregation. For example from a large ValueSet like all SNOMED Problem Diagnosis concepts to a small ValueSet that represents a dozen or so reporting categories. e.g., I'd like to be able to say 'all members of ValueSet A' map to (narrower) 'Infectious Disease'
Grahame Grieve (Jun 16 2016 at 02:19):
how common is this? it sounds a little niche to me
Peter Jordan (Jun 16 2016 at 06:28):
@Michael Lawley, maybe mapping would be preferable as the relationship is expressed in the equivalence property?
Michael Lawley (Jun 21 2016 at 04:43):
The $closure operation cannot return specializes or generalizes, but only the less precise and potentially non-transitive equivalences: narrow and wider.
This seems a pretty severe and less than helpful restriction.
Grahame Grieve (Jun 21 2016 at 23:04):
do you want to make a task to cahnge to the other 2 codes? That's how it's defined, so that would appear to be just an error
Grahame Grieve (Jun 23 2016 at 22:47):
@Michael Lawley - I looked at this. I'm using specializes or generalizes, not narrow and wider. I can only think that this is an error in the spec - can you create a task for it? and use specializes or generalizes in our implementation
Michael Lawley (Jun 24 2016 at 00:17):
10232 and 10233 (regarding the extra doc in your blog post) created
Grahame Grieve (Jun 24 2016 at 03:28):
thx. I've upgraded my server to return a ConceptMap on creation. It should work - but maybe you were caught out by a rule on my public server - if you are not authorized via smart on fhir, the name must be a GUID
Grahame Grieve (Jun 24 2016 at 03:28):
@Michael Lawley please test
Michael Lawley (Jun 27 2016 at 05:01):
/ConceptMap/$translate?source=http://snomed.info/sct?fhir_vs&system=http://snomed.info/sct&code=90260006&target=http://hl7.org/fhir/ValueSet/substance-category
Returs a 500 - "Unable to find concept map to use" which should be a 4xx
Grahame Grieve (Jun 27 2016 at 05:02):
on my server?
Michael Lawley (Jun 27 2016 at 05:02):
yes
and a POST to /$closure gives me a "Unknown operation /$closure"
Grahame Grieve (Jun 27 2016 at 05:03):
post to /ConceptMap/$closure ?
Michael Lawley (Jun 27 2016 at 05:03):
http://hl7-fhir.github.io/conceptmap-operations.html#closure says [base]/$closure
Michael Lawley (Jun 27 2016 at 05:04):
If I POST to /ConceptMap/$closure I hit your business rule about naming
Grahame Grieve (Jun 27 2016 at 05:04):
well, so it does
Michael Lawley (Jun 27 2016 at 05:09):
ooh, I see you've added the grouping changes - will have to catch up to those now
Grahame Grieve (Jun 27 2016 at 05:12):
well I have in the current, yes, but that's not what we're using for the connectathon
Grahame Grieve (Jun 27 2016 at 05:12):
?
Michael Lawley (Jun 27 2016 at 05:14):
that's right, but I'm hankering to improved the ConceptMap editing UI in Snapper and that's contingent on picking up these changes
Grahame Grieve (Jun 27 2016 at 05:14):
hah well, I'd rather go with the current version...
Grahame Grieve (Jun 27 2016 at 05:16):
all right, I'll release and update shortly that moves the $closure operation to the right place.
Brian Postlethwaite (Jun 28 2016 at 00:31):
Which version are we using at the Connectathon?
(assuming you mean the NEHTA one on Monday)
Michael Lawley (Jun 28 2016 at 01:02):
Tuesday - Ontoserver will be supporting the pre-grouping changes version of ConceptMap
Grahame Grieve (Jun 28 2016 at 01:02):
right 2016May version
Last updated: Apr 12 2022 at 19:14 UTC
