Adding "Present on Admission" as a Fact_Relationship

[fitznmn (Fern FitzHenry)]

Continuing the discussion from Inclusion into vocabulary - Codes for Point of origin, priority of admission and patient discharge status:

@Gowtham_Rao

There are these code-sets that are very valuable but are not on OMOP vocabulary:

Point of Origin for Admission or Visit (Form Locator 15 on UB04) - useful to describe where the patient came to receive care, e.g. from home, or clinic etc

Priority(type) of Admission (Form locator 14 on UB04) - indicates if the admission/visit was emergency, urgent, elective, newborn, trauma etc.

Patient Discharge Status (Form locator 17 on UB04) - indicates where the patient was discharged to; useful for readmission calculation (e.g. discharged from one hospital into another hospital vs. discharged to home/self care).

Type of Bill (Form locator 04 on UB04) - useful for inpatient vs outpatient; skilled nursing; and a lot of financial analysis.

Present on admission (Form locator 67 on UB04) - did it develop during care, or before?

Occurrence Codes (Form locator 31-34) - last menstrual period, onset of symptoms

These are small code sets - is it possible to include them in the vocabulary?

Thank you!

Interested in adding “present on admission” as a concept originating from claims data. There is a similar concept shows in the diagram but the class indicates origination in survey data. We would also want to profile concepts for all the Center for Medicare Services (CMS) profiles for the attribute of whether a condition is present on admission (see diagram and below). In the US, this data is abstracted at discharge for inpatients and is high quality as it is in part a basis for reimbursement as well as a flag for hospital acquired conditions. I am not sure if this is part of transitions of care.
Code Reason for Code
Y Diagnosis was present at time of inpatient admission.
CMS will pay the CC/MCC DRG for those selected HACs that are coded as “Y” for the POA Indicator.
N Diagnosis was not present at time of inpatient admission.
CMS will not pay the CC/MCC DRG for those selected HACs that are coded as “N” for the POA Indicator.
U Documentation insufficient to determine if the condition was present at the time of inpatient admission.
CMS will not pay the CC/MCC DRG for those selected HACs that are coded as “U” for the POA Indicator.
W Clinically undetermined. Provider unable to clinically determine whether the condition was present at the time of inpatient admission.
CMS will pay the CC/MCC DRG for those selected HACs that are coded as “W” for the POA Indicator.
1 Unreported/Not used. Exempt from POA reporting. This code is equivalent to a blank on the UB-04, however; it was determined that blanks are undesirable when submitting this data via the 4010A.

[Gowtham_Rao]

Thank you for this post. DRG computation requires the present on admission information.

There seems to be two components for the request.

1. Where to put this information
2. What vocabulary to use to put this information.

For need 1, would condition_status_concept_id be an option instead of fact_relationship? Presently it is recommended that we use this field to identify primary, admitting or preliminary diagnosis.

For need 2, may be we could create a vocabulary with hierarchy? E.g. primary present on admission, secondary present on admission Etc.

Please advise

[Christian_Reich]

@Gowtham_Rao:

This is a Themis 3 item: Clean up Condition Type Concepts (line 17 in the tracking sheet). That’s where this should go. Can you reach out to @Asha_Mahesh and figure out who it is to talk to?

DRG: I am wondering whethere there is a way to split the Cost and the Condition information and make it available. Is that possible?

[fitznmn (Fern FitzHenry)]

It sounds like the condition_occurrence table is the preferred location for POA. Also, that within that table that condition_type_concept_id would be the preferred field. That field is already used to designate patient type and header position (e.g. primary, secondary…diagnosis). We revised our design diagram above to match these preferences. It will require some vocabulary additions (at least 75 concepts). Could you comment if we misunderstood anything?

[mmatheny (Michael Matheny)]

As an add to @fitznmn 's comments, from our understanding, the concept_relationship table would also need to be updated to reflect aggregation to inpatient present on admission or any present on admission, etc, to reflect consistency with other roll-ups.

I edited this post as it was flagged as advertising. I apologize, but it seemed relevant to the conversation, and Dr. Rao seemed to agree with the content and expanded on it.

[Gowtham_Rao]

Please see this post too

Primary dx vs Secondary dx

We want to distinguish primary diagnosis from secondary diagnoses in our EHR data. The condition_type_concept_id seems like the appropriate place for this data. However, we also distinguish between Encounter vs Billing diagnosis and the data goes into the condition_type_concept_id column. We need both. What do others do?

Handling in the vocabulary is probably the best option, especially because we can manage relationship and ancestry. One concern, is that we already have many concept options for conition_type_concept_id. http://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&vocabulary=Condition+Type&page=1&pageSize=15&query=

Many of these are probably not commonly used. I think we could probably remove the numeric position information - or handle them in vocabulary hierarchy. In general, I think the numeric position of the secondary diagnosis does not have inherent value. So, we probably don’t need all that concepts for conition_type_concept_id.

I would take out any visit information, e.g. Inpatient vs outpatient vs other, because they are attributes of Visit captured using visit_concept_id of visit_occurrence table. Visit_occurrence and condition table may then be linked.