encounters (visit_dimension) and observations (observation_fact)

[ELI]

We're up and running on i2b2 1_3 RC5. Up until now, the i2b2 UI/
application layer hasn't leveraged the visit_dimension, but it appears
to be starting down that road now with the export cell / plugin on the
fat client.

As I've discussed the data model (basically a star schema) with other
groups, it appears very few are leveraging the visit_dimension (either
inpatient encounters or outpatient visits). How imperative is it
that an observation (within the observation_fact) have a corresponding
encounter/visit (within the visit_dimension)?

For example, we could load the billing information at the diagnoses
level in the observation_fact, but it wouldn't have a corresponding
visit (it would NOT be included at the visit_dimension). To get the
base of my question, what value is missing (from a researcher's
perspective) by NOT having the encounter/observation relationship
fully defined? Up to this point, I see very little penalty at the UI
level, but perhaps future releases will leverage this more
aggressively if there is a need within the research community to have
this defined.

Thoughts?

[Aaron Abend]

Brian,

I did some research and spoke with Dr. Shawn Murphy at i2b2 about the
visit dimension table.

In the prototype for i2b2, there was a checkbox that allowed a query to
constrain two or more groups to concepts occurring in the same visit.
The visit dimension table contains inpatient/outpatient status and, also
in the prototype, the visit dimension identified the primary diagnosis.

Dr. Murphy indicated that these functions are planned for i2b2, though a
date for inclusion of these specific features has not been set.

One issue with the visit dimension is that it is not always possible to
associate records of different types with the same visit. So a patient
visits a doctor who orders a lab test for strep throat at a point in
time. The symptoms are entered into the EMR, and an order for the lab
test is created. The lab test is performed at a separate location at a
second point in time (possibly not within the hospital) (the test record
may not even have the same date). Finally a medication of penicillin is
prescribed at a third point in time, and could be in a separate system
that is tied to a pharmacy system.

Therefore, to leverage the visit dimension effectively we need a model
for "encounters" that can tie these disparate records together logically
and create a visit that means something. I think it will take some
work on this model for the visit dimension to become meaningful in the
i2b2 query environment.

In the meantime, we create visits for our implementations using each
patient-date in the fact table. Alternatives include
patient-date-location and patient-date-provider. This is a weak
surrogate, but it gives some ability to relate data without making too
many assumptions (such as would be required if an encounter model were
to include data from different dates).

Best!


Aaron Abend
Managing Director
Recombinant Data Corporation
391 Totten Pond Road
Waltham, MA 02451
office: +1 781.996.4345 x210
mobile: +1 978.621.7745
www.recomdata.com