OHDSI Home | Forums | Wiki | Github

Will customizing concept.concept_name break anything in Atlas or when sharing JSON?

#1

Doing analyses on measurements can be complicated when users don’t know what units are used for those measurements.

We are toying with updating our ETL to change the concept.concept_name value for Measurements and Observations so that we append a comma-separated list of the standard units actually present in our data. For example: Zinc [Mass/volume] in Red Blood Cells (ug/dL, mg/L).

We would not be changing any of the other fields in the concept table.

Will customizing the concept_name in this manner likely break any Atlas functionality?

#2

It won’t break, but it will show you the name of the concept that is embedded in the concept set expression and not the value from your vocabulary.

We’re thinking about a feature where you can open a concept set and then ‘refresh’ concept information in the embedded concept set so it can refresh concept names to a local source vocabulary…but for now, it doesn’t do that. But as long as the concept IDs mean the same thing, it won’t break.

1 Like
#3

@Chris_Knoll:

Actually, meant to ping you on that. The conceptset JSON now lists not just the concept_id, but all fields. However, it doesn’t really care about them. I noticed from exporting and importing between Atlantes and scripting the generation of JSON files that you have to provide the concept_code and concept_id, but you can omit the other fields. The concept_code could be anything you want, but you cannot omit it. The concept_id has to be the correct one.

Would be probably good to make that explicit in the documentation. Plus, remove the need for the concept_code (which I just set to “1”). Or, revise the JSON specs and the writer and loader to only take the concept_id (plus of course the flags isExcluded, includeDescendants and includeMapped).

Thoughts?

#4

It’s a bit of a backwards compatibility issue: the current object model describes a full-fledged concept object as part of the model. We remove fields or rearrange the structure, it breaks backwards compatibility.

This is something we can do when moving from CIRCE 1.x to the 2.x line. That is also when we’ll switch our supported CDM versions.

t