OHDSI Home | Forums | Wiki | Github

Adding "Present on Admission" as a Fact_Relationship

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

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.

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

@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?

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?

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.

Please see this post too

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.

t