Opened 3 years ago

Closed 2 years ago

#191 closed problem (duplicate)

represent PCORI CDM 2.x terminology as i2b2 metadata

Reported by: dconnolly Owned by: dconnolly
Priority: major Milestone: data-domains3
Component: data-stds Keywords:
Cc: gpc-dev@…, Jeff.Klann@… Blocked By: #109
Blocking: #317

Attachments (2)

Transitive Closure Paper_20150311final.pdf (517.5 KB) - added by campbell 2 years ago.
Paper on i2b2 metadata functionality to be presented fall AMIA
PCORI network query interoperation.pptx (897.5 KB) - added by campbell 2 years ago.
Talking points for Tuesday 9/29 discussion on CDM V2 compliance

Download all attachments as: .zip

Change History (20)

comment:1 Changed 3 years ago by dconnolly

  • Milestone changed from morning-star to bariatric-study-data

prompted by mention of labs in the bariatric study survey (#278) I noticed that our i2b2 representation of CDM2 has terms/concepts such as RESULT_DATE that belong elsewhere in the i2b2 data model.


comment:2 Changed 3 years ago by dconnolly

At the June 23 i2b2 meeting, Jeff Klann presented the SCILHS i2b2 PCORnet Common Data Model Ontology.

He said they're working on v2 and v3; ETA next couple months.

comment:3 Changed 3 years ago by dconnolly

  • Milestone changed from bariatric-study-data to data-domains3
  • Priority changed from minor to major

Replying to nateapathy:

Does the SCILHS CDRN CDM ontology and CDM transformation code effectively replace the comparable subject areas that are on the GPC_TERMS table?

Since we have been pretty well aligned with SCILHS on goals and high level design, I expect the changes to be fairly small, but yes, this may involve updates to our design for demographics (#67), vitals (#23), and diagnoses (#63) and perhaps enrollment (#229). It should address our outstanding issues on procedures (#243).

As SCILHS addresses CDM v2 and v3, it may impact our design for meds (#78) and address labs (#158).

We are starting this effort and don't want to pursue the GPC_TERMS work if we will be adopting the ontologies from SCILHS instead.

Feel free to skip to the SCILHS ontology and let us know how it goes, but please don't let this stall your work. As I say, I expect the changes are small, and if you start work with the current GPC_TERMS, migrating should be a manageable effort.

The major benefit to offset the cost of this disruption is filling in gaps in our CDM ETL (ticket:240#comment:6), as well as shared development costs with SCILHS going forward.

comment:4 Changed 3 years ago by dconnolly

  • Description modified (diff)
  • Milestone data-domains3 deleted
  • Priority changed from major to medium
  • Type design-issue deleted

Batch update from file sam-the-eagle-plan - Sheet1.csv

comment:5 Changed 3 years ago by dconnolly

  • Blocking 317 added

comment:6 Changed 3 years ago by dconnolly

  • Type set to problem

I finally got the SCILHS ontology on babel.

"PCORnet Demographics" shows up twice, as do the other top level folders because I inserted the TABLE_ACCESS rows twice. I hope that's not too much of a distraction.

Last edited 2 years ago by dconnolly (previous) (diff)

comment:7 follow-up: Changed 3 years ago by nateapathy

Following up on the discussion from 8.11.15 GPC Dev call:

c) how cost effective to switch to SCILHS terms from GPC?
   i) Dan : feedback from Cerner folks? (not here today). I’ll try to catch up with
   ii) PR/UTSW: vote to not switch, prefer to maybe map between the two, but our
   GPC terms cover more granular and we’d lose that if we switch
   iii) DC/KUMS: maybe adopt SCILHS terms for things we haven’t settled for GPC
   yet, e.g. use SCILHS for procedures but not diagnoses
   iv) RW/KUMC: obesity & adaptable trials drive timeline (for Sept.) to implement new
   CDM terms

The most significant improvement that the SCILHS ontology provides is that it aligns with best practices for i2b2 design and comes with CDM creation scripts using the "PCORNET_CD" field. The most obvious design improvements are how demographics are stored in the database and how modifiers are structured. The transition from the Cerner standard i2b2 ontology to the SCILHS ontology was relatively straightforward, largely thanks to the use of best-practice designs for i2b2. For example, storing patient demographic data as observations in the OBSERVATION_FACT table is not a standard design practice, and the SCILHS ontology resolves this.

As for granularity, it can always be added back in later versions, and I would like to see us pursue that with SCILHS as a partner rather than creating a hybrid which will undoubtedly be more convoluted for the end user.

It also gives us significant ability to leverage other groups' work, and decreases the distance between "proprietary" i2b2 design and something moderately resembling a standard, at least across i2b2-using PCORnet CDRNs. It would behoove us to tack as closely as possible to any repeatable standards emerging from other groups, as it only increases our economies of scale. My understanding from comment3 on this ticket is that we would be adopting the SCILHS ontology as a group - I did not think the decision was still up for debate.

I also recognize that other groups are focusing on the Obesity terms and ADAPTABLE terms. As CMH will not be participating in ADAPTABLE, we've had cycles to focus on the SCILHS effort that other teams won't have for some time.

Last edited 2 years ago by dconnolly (previous) (diff)

comment:8 in reply to: ↑ 7 Changed 3 years ago by dconnolly

Thanks for the experience report.

On process...

Replying to nateapathy:

... My understanding from comment:3 on this ticket is that we would be adopting the SCILHS ontology as a group - I did not think the decision was still up for debate.

Well, your experience report aligns with my expectation that adopting SCILHS would be cost-effective overall, but where it overlaps with designs we have already adopted, for example demographics (#67), due process involves re-opening such tickets and then closing them again.

I probably should have started to do that by now but I have been reluctant on behalf of dev groups (such as KUMC!) that have investment in the existing design. (see also terminology evolution.)

This whole SCILHS business really shouldn't be hiding under this CDM 2.x ticket at all. I just haven't managed to re-organize tickets properly. Here's hoping for time to do so.

Last edited 2 years ago by dconnolly (previous) (diff)

comment:9 Changed 3 years ago by lv

Is the idea that we'll need CDM v3 compliance earlier than the SCILHS timeline (end of the year for v2.1/3), which could provide an opportunity to contribute our work?

Can either KUMC or NateA comment in a general way on the effort required to implement the SCILHS work?

I agree with following one standard rather than creating our own hybrid. If the level of granularity is requied, maybe we should advocate for including it in their later release?

comment:10 Changed 3 years ago by nateapathy

Our implementation effort estimation ended up being much more than the actual work effort, which was very reassuring. The SCILHS ontology, due to its limited granularity, is pretty straightforward to implement, and follows best practices for i2b2 design, which makes it easier to implement. In terms of mapping our hierarchies and terms to the SCILHS ontology hierarchies and terms, that effort which we thought would be monumental, was actually not nearly as cumbersome as we thought, largely because we were already fairly well aligned since (specifically for demographics) Cerner i2b2 uses the standard i2b2 demographic ontology, and the SCILHS ontology sticks fairly closely to that design. Granted, the ease of that transition was due in large part to our local standard following the i2b2 standard pretty tightly, so the degree to which on a site has deviated from the i2b2 standard ontologies will be a good proxy for work effort to align with SCILHS.

comment:11 Changed 3 years ago by dconnolly

  • Milestone set to data-domains3

oops... milestone got deleted in batch update (comment:4)

comment:12 Changed 3 years ago by dconnolly

  • Priority changed from medium to major

oops... "medium" priority should be "major"

comment:13 Changed 3 years ago by lv

How did sites that implemented SCILHS handle Procedures? Has anyone requested the CPT ontology yet?

comment:14 Changed 3 years ago by nateapathy

We propogated the procedures ontology with ICD9 procedure codes as SCILHS indicated. We have a default Cerner i2b2 CPT ontology, but have not had any requests or a need to request, so it only exists insofar as the Babel ontologies and those on the PCORnet Central Desktop.

comment:15 Changed 3 years ago by lv

Eric's notes from implementing SCILHS at MCRF:

\PCORI\DEMOGRAPHIC\HISPANIC\ - This was using Race_CD in Patient_Dimension. We fill race with race, not ethnicity (the Race codes were also using this column). I switch this over to use our local basecode and pointed at Concept_Dimension instead.

\PCORI\ENROLLMENT\ENR_BASIS\*\ - I thought the mappings in this section were a little odd…
Encounter-based: would pull a count of patients that had atleast one fact that had a start_date.
Insurance: would always be 0. (not available for selection in i2b2)
Geography: was based on having the code LOCATION_CODE:2. We don’t have any location codes, so this would never work (again not available for selection in i2b2)
Algorithmic: would be the same as Encounter-based.

I switch them to be based on \i2b2\Demographics\Enrollment\ terms
Encounter-based: Is in one of the two nodes: Face to Face Visit Within One Year or Two Encounters or Wellness Within 3 Years (Added two children to accomplish)
Insurance: Is in Insurance
Geography: Is in Patients Within 50 Miles
Algorithmic: Is in MCRF Catchment

\PCORI\ENROLLMENT\ENR_BASIS\ - This had a C_FACTTABLECOLUMN value of PATIENT_NUM, since I made the above changes to \PCORI\ENROLLMENT\ENR_BASIS\*\, I had to update this to concept_cd. (This node is also disable in the hierarchy)

I also didn’t do much with modifier’s in the ontology. I know the ‘\PCORI_MOD\CHART\’, which is applied to ‘\PCORI\ENROLLMENT\ENR_BASIS\*\’, is all hardcoded to be true or false. So Yes to chart will always be true and all the other modifiers will always be false. There may be more examples of this, but like I said, I didn’t spend much time on modifier’s.

Changed 2 years ago by campbell

Paper on i2b2 metadata functionality to be presented fall AMIA

Changed 2 years ago by campbell

Talking points for Tuesday 9/29 discussion on CDM V2 compliance

comment:16 Changed 2 years ago by campbell

I have attached talking points for Tuesday presentation and for those interested included a paper we will be presenting at AMIA on the development work we have been doing on i2b2 at UNMC pertaining to query functionality

comment:17 Changed 2 years ago by dconnolly

  • Blocked By 376 added

comment:18 Changed 2 years ago by dconnolly

  • Blocked By 376 removed
  • Resolution set to duplicate
  • Status changed from new to closed

I don't really have a next step on this; I suppose it's overtaken by #381.

Note: See TracTickets for help on using tickets.