OHDSI Home | Forums | Wiki | Github

How to capture 'status' for an observation e.g. on admission, on discharge, during admission

We are mapping our source data to the Observation table and have some observations where we would also like to capture whether the observations are on admission, on discharge, during admission.
Which field in the Observation table could we store this in?
Is there an equivalent of the ‘condition_status_concept_id’ in the condition_occurrence table, for the observation table?


Right now, we don’t have that resolution: Do you have a scientific use case for querying this?

VISIT_DETAIL is likely where you should be tracking longitudinal progression, e.g. from ED to floor to ICU back to floor to discharge, so that you can do the comparison between the observation time and where the patient was in the course of the admission. In other words, you ETL the ADT data into VISIT_DETAIL, then tell your analyst what your rules are for classifying observations as “on admission,” “on discharge,” “during admission” etc based on where they fall in between the VISIT_DETAIL timestamps.

Thanks @Christian_Reich, @esholle.

The operational use-case is to document all the diagnoses, observations and procedures that occur during an inpatient stay (and in their sequential order) and to be able to link to and use these for Diagnosis-Related Groups (DRG, classification for admitted patients that links patient casemix to hospital resourcing) and funding.
The status type that denotes whether, for example, the diagnosis, was present on admission or a complication that arose during the inpatient stay is also required along side each diagnosis code.

Would it be acceptable to use the fields:
and populate, for instance, with the following concepts (LOINC codes) in the OBSERVATION domain?
ID Code Name Class Concept Validity Domain
1031359 LP73900-0 Admission diagnosis LOINC Component Non-standard Valid Observation
1014252 LP199486-4 Discharge diagnosis LOINC Component Non-standard Valid Observation

Generally, that is not the prime use case for the OMOP CDM. The OMOP CDM measures what happens to the patient and what effect that has. If you want to go further you may want to expand the model.

We only have something like that for the diagnosis stored in CONDITION_CONCEPT_ID: the field condition_status_concept_id. It allows to qualify the type of diagnosis and when it was derived. The concepts used to characterize the diagnosis are here.

You could, except nobody would know you did. You’d have to go to Themis and register this as a convention. If you want to do it exclusively for your own research you can do whatever you want.

Thanks @Christian_Reich @duwaynewillett
Great to learn of Themis also.

In the US, many electronic clinical quality measures use “Present on Admission” as inclusion or exclusion criteria. One example is eCQM # 1028: Severe Obstetric Complications (https://ecqi.healthit.gov/ecqm/eh/2023/cms1028v1)

For OHDSI logic, it would be much more convenient and efficient to mark the status of a condition as “Present on Admission” rather than having to use fact relationships or separate observations.

Could “Present On Admission” be added as a valid member of the Condition Status domain?

Since this is different from Primary Admission Diagnosis and Secondary Admission Diagnosis, one might consider adding two copies of a diagnosis for a given person on a given date – one indicating whether it is present on admission, and other indicating whether it is a primary or secondary admission diagnosis. Although potentially cumbersome from an ETL perspective, that might still likely be easier for an end-user to represent in Atlas.

And the difference between “Admission diagnosis” and “Present on admission” is what?

I think you alluding to symptoms present on admission, not diagnoses. Symptoms are facts. Diagnoses can change. From that perspective you have a point. But instead of making the poor ETL wretch make the decision whether something is a symptom or a diagnosis, why not rename the statuses and remove the word “diagnosis”. So, it becomes “on admission”, “on discharge”, etc.

@Christian_Reich “Present on Admission” and “Admitting Diagnosis” are quite different. See my explanation in this July 2018 post: Present on Admission vs Admitting Diagnosis - #7 by aostropolets

You could have a POA condition (diagnosis) that is unrelated to the reason you were admitted. For example, you could have a pre-existing active decubitus ulcer, which would be a POI but be admitted for community-acquired pneumonia (admitting diagnosis).

@mgkahn: I know that distinction. But we should think of how we model that, so it works for the ETLer and the analyst:

Everything is pre-existing at admission. I know the usual narrative: patient has chronic problems, and then developed something acute that led to the admission. It is obvious to the physician. But we are not the physician.

How about the following rules (to be Themissed):

  • Everything stated the day of admission, or declared “at admission”, gets the “on admission” status.
  • Everything the patient got admitted for, i.e. the primary or first problem, gets the “primary” status.
  • Everything “pre-condition”, or POA, or secondary, or 2nd, 3rd, 4th, 5th etc., gets the “secondary” status.

We also need to permute them to “on admission - primary” and “on admission - secondary”.

Makes sense?

That is close, but may not be sufficient. A big focus of such logic is hospital acquired conditions. Some bad events could happen on the day of admission that would not be considered POA. For example, if on their first hospital day a person had a fall, or a complication of a procedure (such as stroke), those would not be considered POA.

If it were easier to represent logic using datetime (e.g. for EHR data), that might help (e.g. detecting that an adverse event happened at least X minutes after admission). However, even that might be brittle, depending upon how robustly the EHR (or ETL) distinguishes between the time an event happened vs. when it was recorded.

By contrast, the medical coders and clinicians partner to determine what should truly be considered POA, regardless of when the conditions (and their start time) are documented. The coders ensure that the clinical notes document and justify the POA status, given their importance in quality & safety measures and associated payment or penalties.

I see. Well, I am not doubting the coders. I am protecting the ETLers and analysts. They need something that works universally, even in a non-US hospital. How about:

  • Everything declared “at admission” or “admitting” gets the “on admission” status, meaning, it developed prior to the visit.
  • Everything the patient got admitted for, i.e. the primary or first problem, gets the “primary” status.
  • Everything “pre-condition”, or POA, or secondary, or 2nd, 3rd, 4th, 5th etc., gets the “secondary” status.

If something happens on the admission day and doesn’t have “admission” status it just stays with no status.