ETL for Diagnosis.DX_SOURCE

[writetoritu]

Some notes on this field:

• In PCORnet v2 and v3, DX_SOURCE is a mandatory field (it was optional in v1).
• acceptable values: AD=Admitting; DI=Discharge; FI=Final; IN=Interim; NI=No information;UN=Unknown; OT=Other
• field description: Classification of diagnosis source. We include these categories to allow some flexibility in implementation. The context is to capture available diagnoses recorded during a specific encounter. It is not necessary to populate interim diagnoses unless readily available. Ambulatory encounters would generally be expected to have a source of “Final.”

The OMOP-PCORnet subcommittee has adopted the following convention to populate this field:

• To record diagnosis source in the OMOP CDM, two records will be created: one in the OBSERVATION and one in FACT_RELATIONSHIP table.
  1. The OBSERVATION record should have observation_date equal to the corresponding condition_start_date. The observation_concept_id should contain 4021918 (‘Qualifier for type of diagnosis’) and the value_as_concept_id should be set to one of the concepts (x,y,z...).
  2. The FACT_RELATIONSHIP record should have domain_concept_id_1 = 19 (‘Condition’) and domain_concept_id_2 = 27 (‘Observation’). Fact_id_1 should be equal to the respective condition_occurence_id and fact_id2 to the respective observation id. Concept ID for relationship_concept_id has been requested.

The absence of an Observation and FACT_RELATIONSHIP table for the respective CONDITION_OCCURENCE record will be interpreted as “field is not available at the source”.

@mgkahn @baileych We were wondering whether we should have a similar convention in PEDSnet or just populate this as NI?

[baileych]

I'm happy to discuss implications further, but for cases like this where our requirement is essentially to add a new value to every row in condition_occurrence, I've come to favor just adding an extra column to that table, on the theory that fact_relationship is going to get really big if we follow the OMOP-canonical approach of stashing these qualifiers in observation and linking to them.

For this specific case, though, I wonder whether we get what we need straight from condition_type_concept_id, or could do so with small extensions to that attribute?

[toanong]

I agree that we should avoid using fact_relationship whenever we can. The subgroup always opted to not alter the OMOP table but we don't have to follow that principle. It's really fortunate if we already have what is needed to populate dx_source in condition_type_concept_id. If not, the extension @baileych was referring to would require a change in the PEDSnet CDM convention.

[baileych]

@toanong I think we've probably got what we need in the short term in condition_type_concept_id, since we've by convention agreed that we're only capturing final diagnoses. So I think - @toanong @mgkahn @writetoritu check me on this - that we can map inpatient discharge diagnoses to DI, outpatient diagnoses to FI, problem list entries to another table, and any other condition_type_concept_id to OT.

I understand the subgroup's concern about integrity of the OMOP CDM, but I think as long as we stick to non-breaking extensions we have a lot of flexibility.

[mgkahn]

Can somebody explain why the OMOP-PEDSnet group felt that using the condition_type_concept_id, as Charlie articulates above, was not acceptable, resulting in the highly inefficient use of two additional rows (one in observation and one in fact_relationship) for each diagnosis? If a field exists that has the semantics we want, we should use it. If that field has the right semantics but does not have all of the terminology terms we need, then we should advocate for the missing terms. In this case, I do not see why condition_type_concept_id isn't sufficient to meet the need without any change in the model and without resorting to using fact_relationships.

Long way of saying that I strongly agree with Charlie's condition_type_concept_id mapping. And if we feel we need an additional term/value for this field, we should ask for that to be added.

Charlie -- I didn't understand your statement: "problem list entries to another table". I'm assuming you mean to another table in PCORnet CDM. If so, why are you not advocating putting into PCORnet's Diagnosis table with DX_SOURCE = OT?

[writetoritu]

I agree with all of you on simply using condition_type_concept_id to populate PCORnet's Diagnosis.DX_SOURCE for the PEDSnet->PCORnet transformation.

• @mgkahn The OMOP - PCORnet group (Did you mean PCORnet instead of PEDSnet in the previous comment) chose the other alternative (i.e. create records in observation and fact_relationship). This group uses condition_type_concept_id to populate the DIAGNOSIS.PDX (principle discharge diagnosis flag) field. Their conventions on populating condition_type_concept_id are different from PEDSnet in that they only allow two values: 44786627 (primary condition) and 44786629 (secondary condition). @toanong please correct me if I am wrong or if I missed any meeting where this was being discussed.
• In PEDSnet, here are more details on using condition_type_concept_id to derive DX_SOURCE
  • There are 98 valid values (domain_id of "Condition Type") for this field in condition_occurrence (as per the PEDSnet conventions document). Most sites use the following values: EHR problem list entry, inpatient header (primary position), inpatient header (2nd position), outpatient header (1st position), outpatient header (2nd position), primary condition, secondary condition
  • The "EHR problem list entry" is not applicable in this case because those records would not be used to populate the PCORnet.DIAGNOSIS table and will instead be used to load the PCORnet.CONDITION table.
  • So, a suggested mapping would be: All outpatient types would map to "FI" and inpatient types would map to "DI" and rest will map to "OT". Correct?

[mgkahn]

Got it. Let's "institutionalize" the use of only "EHR problem list", "inpatient header (primary position)", "inpatient header (2nd position)", "outpatient header (1st position)", "outpatient header (2nd position)" as the only valid PEDSnet values from the 98 valid values in the OMOP terminology. Do you see any reason why we need primary condition, secondary condition that cannot be fulfilled by the other values. I can't look at the conventions document while writing this comment. If there is a separate semantics that make sense, then include these two also but make it clear when we expect to use primary/secondary condition over the other values.

Regarding the suggested mapping -- I say "go with what you wrote until we have a reason to revisit".

[mgkahn]

I also appreciate that our decision to deviate from the larger group's approach means we will also be on our own for our PEDSnet --> PCORnet mapping code. Sorry to see that happen but I think we cannot afford to have such a large blow-up on the size of our database just for this reason.

[writetoritu]

Thanks all - we will wait for a decision in https://github.com/PEDSnet/Data_Models/issues/157 and then update the mapping table and the ETL code for PCORnet.diagnosis