Concepts domain should support other mapping types

[brandones]

Right now, the concepts domain only supports SAME-AS mappings. It should support others, such as NARROWER-THAN.

I propose that the headers should be changed to Mappings|SAME-AS, Mappings|NARROWER-THAN, etc. Same as mappings would be interpreted as Mappings|SAME-AS for backwards compatibility.

[mogoodrich]

+1 thanks @brandones

[mseaton]

Instead of cluttering up the headers, which could make for some very noisy and hard to read csvs, what about keeping the existing concept csv mapping headers to assume SAME-AS, and recommend use for things we consider codes and consistent across all concepts (like the PIH and CIEL mappings). Then, we'd have a new domain - conceptreferenceterm (or similar), which would have a CSV with columns:

concept | source | term | type

This would allow multiple csvs (one per source) or a single CSV that contains multiple source/mapping pairs.

@mks-d / @rbuisson thoughts?

[mks-d]

@mseaton very much like with concept names I believe the two options can certainly coexist. Especially if implementers see value in @brandones's suggestion. Your proposal is definitely better for being more complete at properly addressing the details of those mapping types in the data model.

A bit of a non-answer I know, which means that we're supportive of both options and leave it up to you to implement first (and perhaps only) the one that you prefer.

[mseaton]

That makes sense to me. I'll create a new ticket around the conceptreferenceterm domain as needed. Leaving this ticket as enhancing the concept domain, I'd like to modify the existing proposal on this ticket to support the following as supported header formats:

MAPPING-TYPE

• If the header just contains the mapping type (SAME-AS, NARROWER-THAN, etc), then this would lead to the exact same behavior as now (the existing "Same as mappings" would be mapped to "SAME-AS"). This is basically the original proposal in the ticket, with the exception that Mappings| is removed from the column header, as it can be implied by the inclusion of the mapping type.

MAPPING-TYPE|SOURCE"

• Optionally, the header can contain the specific source. So you might have headers for "SAME-AS|CIEL", "SAME-AS|PIH", and "SAME-AS|RxNorm". In this case, each of these would be expected to contain a single mapping.

MAPPING-TYPE|SOURCE|UNIQUE-KEY

• If a particular source has multiple mappings of the same mapping type, this would allow these to be added as independent columns. So, for example, PIH typically adds 2 same-as mappings in the PIH source to all of it's concepts - one that is a numeric code and one that is more of a human readable name. To continue to support this, one might add columns: "SAME-AS|PIH|CODE", "SAME-AS|PIH|NAME". The UNIQUE-KEY can be anything, it's only purpose is to ensure column headers are unique in the csv.

@brandones / @mogoodrich happy to discuss and brainstorm these thoughts further.

[mseaton]

I have a PR open and linked above. @brandones would you be able to build and test this out with the work you are currently doing, and @ibacher or @mks-d would one of you be able to review?

I implemented things as I laid out above, except I ended up keeping Brandon's original suggestion of having a "Mapping" prefix on each column. This seemed a bit safer.