Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#1515 closed enhancement (fixed)

Query past medical and family history from Epic for ambulatory and inpatient

Reported by: rwaitman Owned by: mhoag
Priority: major Milestone: heron-council-grove-update
Component: data-repository Keywords: public-web
Cc: dconnolly, ngraham, mnair Blocked By:
Blocking: #1688, #1696 Sensitive: no

Description

Also desired by Brooke for cancer research

Change History (18)

comment:1 Changed 8 years ago by rwaitman

Milestone: heron-melvern-updateheron-council-grove-update

Relevant Changelists and Descriptions

ChangelistDateCommitterComment
r187512/17/12MattInitial SQL code for pulling medical history obs from epic
r187612/17/12MattBranch Update
r187712/17/12MattFix up
r188112/18/12Daninitial context doc/tests for epic_medical_history
r188212/18/12Danuseful encounter_ide for family_hx
r188412/18/12Danpep8 whitespace fixes
r188512/18/12Daninitial cut at load_epic_medical_history paver task
r190701/03/13Mattnew concept/modifier creation added to epic_concepts_load.sql
r190901/03/13Mattmerge with default
r191001/03/13Matttweaks to make load_epic_concepts work
r192501/08/13MattFixed Concept and modifier Hierarchy and bugs preventing etl from running.Smoked tested both medical history (/w modifier) and family history(sister having cancer)
r192601/08/13Mattmerge with default

comment:2 Changed 8 years ago by dconnolly

Owner: changed from badagarla to mhoag
Status: newassigned

Example queries (use cases) from Russ:

How many people have

  • had their appendix taken out?
  • parent who had cancer?
  • or hypertension?
  • diabetes in their past medical history?

We should get Matt an Epic web user account, ...training materials for HospitalEpicSource#clarity

recent precedent: procedure orders: #1212

comment:3 Changed 8 years ago by dconnolly

Matt,

I happened to ask Russ about whether ICD9 facts from past medical history should be integrated with the existing Diagnosis hierarchy (using a modifier) or be in their own tree, and we're leaning toward integrating them.

comment:4 Changed 8 years ago by mhoag

Status: assignedaccepted

comment:5 Changed 8 years ago by mhoag

Analysis

Two primary epic tables were needed to meet the threshold use-cases outlined in comment:2.

For:

  • had their appendix taken out?
  • or hypertension?
  • diabetes in their past medical history?

The MEDICAL_HX table was transformed into the i2b2 star schema. This transformation leveraged epic_diag_tx.sql's icd9 translation [dx_avoid_icd9_synonym] and also requires an additional modifier 'DiagObs:MEDICAL_HX' to indicate a diagnosis made as a part of the patients' medical history.

For:

  • parent who had cancer?

The FAMILY_HX table was transformed into the i2b2 star schema. In order to accurately represent the data in FAMILY_HX it was necessary to add a new set of modifiers, namely "Family Relations". The Family Relations modifiers can be selected in the i2b2 client allow the user to query which subset of family members had the specified illness.
It is important to note that the diagnoses identified in the FAMILY_HX table did not correspond to any standard diagnosis template (e.g. icd9). They seemed to be fairly general diagnoses like "Cancer, Anxiety, Fatigue" and may, in some cases, be too generalized to refer back to a specified icd9 code. There was 376 of these general diagnoses and after speaking with Russ it seems that we should just add them as their own concepts. While this does add some slight dissonance to the standard ontology for diagnoses, back mapping the concepts could range from a headache to an intractable problem.

Implementation

As is, the current implementation construct the transformed view for the MEDICAL_HX and FAMILY_HX table as well as the view for adding Family Relations to the modifier_dimension and Family History Diagnoses to the concept dimension.

TODO

  • Add the loading of the views to epic_etl.py
  • Address TODOs in epic_medical_history.sql
  • [Design Decision] Decide if it is appropriate to introduce dependencies with source:heron_load/epic_diag_tx.sql@1626:de042061c702#22.
  • [Design Decision] Decide if the concept/modifier dimension additions should be in separate file.

Test

A select statement was made against the appropriate transformed table for each of the identified use cases.

Changelist

Initial Commit: [4a3ff8dd4b4c]
Branch Update: [8af2a2134c74]
Follow on fix up: [35d9dd63a077]

comment:6 in reply to:  5 Changed 8 years ago by dconnolly

Replying to mhoag:

... new set of modifiers, namely "Family Relations".

Note that when finding patients in i2b2, using modifiers is optional. I wonder if this design will make it look like patient X has a history of cancer, when in fact only X's parent does.

Maybe "parent had cancer" should be its own concept? On second thought, maybe that's unwieldy; maybe "family history of cancer" is clear enough as as a concept, with modifiers for father/mother/etc.

... [35d9dd63a077]

Looks good so far. I made a couple tweaks:

comment:7 Changed 8 years ago by rwaitman

comment:8 Changed 8 years ago by rwaitman

Blocking: 1688 added

comment:9 Changed 8 years ago by mhoag

Replying to dconnolly:

Note that when finding patients in i2b2, using modifiers is optional. I wonder if this design will make it look like patient X has a history of cancer, when in fact only X's parent does.

This should not be a problem because the diagnoses associated with family medical history will be different from standard diagnoses. Family medical history diagnoses will live in the 'Family History Diagnosis' tree with the potential modifier '\Family History\...' or 'No Family History'.

An example i2b2 concept+modifier path might be:

\i2b2\Family History Diagnosis\Cancer\Family History\Parent

returning all of the patients that have had a parent who has had cancer.

Note that the 'Family History Diagnosis' tree will be slightly limited in usefulness until hierarchy is created for the diagnoses (See #1666).

comment:10 Changed 8 years ago by mhoag

Changelists

cb427a6ef5dc - new concept/modifier creation added to epic_concepts_load.sql
055966b83b21 - merge with default
d9d4a9e78077 - tweaks to make load_epic_concepts work

comment:11 Changed 8 years ago by ngraham

Blocking: 1696 added

comment:12 Changed 8 years ago by mhoag

Owner: changed from mhoag to ngraham
Status: acceptedassigned

Notes on latest changes (r1925)

There was an issue with the reference table zc_medical_hx in that there was duplicate entries for the same name on two diagnoses: Heart Disease and Arthritis. Since the names of the diagnoses are *supposed* to provide uniqueness (since they are added to concept dimension) the medical_hx_c was appended to these two diagnoses to establish uniqueness.

TODO

Still need to integrate Tamara's Ontology for the family history diagnoses.

Ready for code review. (Sending to Nathan)

comment:13 Changed 8 years ago by ngraham

Owner: changed from ngraham to mhoag

It looks pretty good to me! A couple comments:

  • epic_concepts_load.sql: I wonder if it's worth factoring out the common stuff from the concept paths. I think we've done it sometimes and not others. Though, if it ain't broke...
  • I would suggest adding an automated test or two to source:heron_load/test_heron_query.py. At least something that tests to make sure that some rows are returned for an i2b2 query. Or maybe something that makes sure there are more history facts for "Cancer and Tumor" than there are when you search the same concept with "Sibling".

comment:14 in reply to:  13 Changed 8 years ago by mhoag

Replying to ngraham:

  • epic_concepts_load.sql: I wonder if it's worth factoring out the common stuff from the concept paths. I think we've done it sometimes and not others. Though, if it ain't broke...

This definitely occurred to me while I was refactoring some other things, but my trepidation was the same as noted ("if it ain't broke"). That said, I will start a changelist to refactor the common stuff and if it passes a smoke test, I will commit otherwise I will shelve it.

  • I would suggest adding an automated test or two to source:heron_load/test_heron_query.py. At least something that tests to make sure that some rows are returned for an i2b2 query. Or maybe something that makes sure there are more history facts for "Cancer and Tumor" than there are when you search the same concept with "Sibling".

This seems like a very good idea. Maybe we can sit down together for 10-15 mins and come up with some good test queries.

comment:15 Changed 8 years ago by mhoag

Resolution: fixed
Status: assignedclosed
  • Added a test to test_heron_query for both medical history and family history
  • Shelved refactoring now as Nathan and I discussed in person

Status Change

Resolving as fixed since the main bug has been merged to the default branch

All subsequent updates to the family history diagnosis ontology will be done to the default branch.

comment:16 Changed 8 years ago by dconnolly

comment:17 Changed 7 years ago by dconnolly

Keywords: public-web added

comment:18 Changed 7 years ago by kcrane2

Approved for public release

Note: See TracTickets for help on using tickets.