If you are a site with COVID data, consider representing properly the result of the test. For covid-tested-characterization study and for prediction study, detecting properly patients tested with negative results is important. In measurement table, you may have this test represented
The guidance is to put into value_as_concept_id the following SNOMED CT codes (for positive and negative)
in OHDSI concept id world that means Athena for positive Athena for negative
If you think this guidance is wrong, please post an opposing view and justification.
Note that the current definition (PhenoID 30) is working with MANY positive codes:
see a list here (in italic and in picture)
_PhenoID 30 on final server it is ATLAS
_to see all values better, use this corresponding definition on covid19 dev server _
_h_ttp://atlas-covid19.ohdsi.org/#/cohortdefinition/451
Vojtech, this is a good point. LOINC says how it should be, but it cannot force users to use these values in their ETL. So what we did was creating a comprehensive list of positive results. It will catch whatever was used in a ETL and will not hurt anybody.
Perhaps we can use a scenario (or patient story) and a preferred way to represent it in OMOP. Let me offer one scenario
John Doe had dry cough starting on March 1. (at home) He had fever 37.9C on March 2nd. (at home) He had outpatient visit on March 4th. On March 4th, he got tested using RNA test (nasal swab) (date of specimen collection) On March 5th, the result came back and it was positive. To facilitate return the work, he was tested again (same approach, RNA test, nasal swab) on March 16th and the result was negative.
His EHR record had covid19 added to problem list as a result of positive test on March 5th.
Thinking about this further - in Condition_occurrence table, it would be good to distinguish covid19 asymptomatic patient from a severe covid19. One trial used a covid severity scale. I also found this mdcalc site (Brescia-COVID Respiratory Severity Scale (BCRSS)/Algorithm)
There are pre-release codes (not found in Athena) for covid-pneumonia and covid-ARDS. Maybe we should embrace those. (will be released in July 2020) (looks like SNOMED now embraced pre-release notion (like LOINC) (Yay!)
How sites doing NLP sites (in OMOP model) are dealing with a note indicating fever 39C three days prior outpatient visit start date. Do you populate measurement table (with some special value in measurement_type_concept_id indicating “inferred from NLP”. and using the measurement_date of [visitDate-3days] ?
Currently, we have a rich hierarchy of COVID forms (under this concept). It includes pneumonia, ARDS and asymptomatic. I’d not add SNOMED pre-release concepts since they may change the identifiers. Once SNOMED released them, we will remap temporary OMOP Extension concepts to SNOMED. Sounds good?
SNOMED UK added the following. Should than be enough?
concept_code
concept_name
symantic_tag
1300671000000104
COVID-19 severity scale
(assessment scale)
1300631000000101
COVID-19 severity score
(observable entity)
1300681000000102
Assessment using COVID-19 severity scale
(procedure)
1300591000000101
Low risk category for developing complication from COVID-19 infection
(finding)
1300571000000100
Moderate risk category for developing complication from COVID-19 infection
(finding)
1300561000000107
High risk category for developing complication from COVID-19 infection
There is a good question about PROCEDURE vs DEVICE_EXPOSURE for representing many care steps in the care for covid19. Korea notes are on the github. If there are US sites that adopted certain approach, posting you design choices here would help other sites.
This initiative will use OMOP (among others): https://covid.cd2h.org/N3C
@krfeeney@cukarthik@andrew@clairblacketer@Christian_Reich Have you listed out common data elements for N3C-- it doesn’t seem OHDSI’s typical working style, but it seems that it is one of the requirments for this project. THanks! Lisa
We keep adjusting to the way COVID-related facts are described in the data. Addressing such things as suspected vs real Conditions, Emergency codes, Timing context, Lab tests hierarchy, pre-coordinations and many others, we’re happy to announce COVID-19 v2.0 Vocabulary Release that is already in Athena.
If you are involved in ETL or data analysis, please make sure to take a look at the changes. After the first version we updated some rules. It’s highly recommended to re-run ETL with the recent version since the interim vocabulary versions are not supported by current or initial instructions.
Sure we can, just provide one concept to represent ‘positive’ and don’t give them any other choices.
I have to disagree with this: it leaves us to do what Vojtech is showing: we have to put in every possible code that represents ‘present’. Why not just have ‘Positive’ and ‘Detected’ map over to ‘Present’? Or any other combo where there’s one ‘standard’ way to represent something is present.
Don’t think we can’t force people to do things, that’s what ‘use the standard’ means. But if we give them multiple standards to choose from, we miss the whole point of standardization.
