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
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 https://atlas.ohdsi.org/#/cohortdefinition/139
_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.
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.
