Uploaded image for project: 'i2b2 Documentation'
  1. i2b2 Documentation
  2. DOC-2

Upgrade scripts install ICD9-ICD10 ontology heirarchy

Details

    • Task
    • Status: Backlog
    • Minor
    • Resolution: Unresolved
    • None
    • None
    • None

    Description

      The upgrade script for 1.7.07 adds a CA pointer in TABLE_ACCESS to the new ICD10_ICD9 shard. Unless you're using i2b2 for a very specific clinical application, this creates an unusable "Diagnoses (ICD10)" folder in Navigate Terms which just returns an error when clicked. Our i2b2 doesn't have diagnoses at all so I had to hide this after upgrade.

      The script Metadata/scripts/table_access_insert_data.sql should be part of the Demo Data package, not the standard upgrade. You might say the same for schemes_insert_data.sql, but that's not as annoying.

      Attachments

        Activity

          "The script Metadata/scripts/table_access_insert_data.sql should be part of the Demo Data package, not the standard upgrade."
           I dont understand your distinction between the demo data package v the standard upgrade. Can you explain this better? The data package contains the demo data package, so the upgrade path is intended to upgrade the demo data. Also, if you ran the complete upgrade, the ICD10_ICD9 table would have been created and the navigation error would not have occurred.
          lcp5 Lori Phillips added a comment - "The script Metadata/scripts/table_access_insert_data.sql should be part of the Demo Data package, not the standard upgrade."  I dont understand your distinction between the demo data package v the standard upgrade. Can you explain this better? The data package contains the demo data package, so the upgrade path is intended to upgrade the demo data. Also, if you ran the complete upgrade, the ICD10_ICD9 table would have been created and the navigation error would not have occurred.
          Sorry I must have created a false mental distinction between "demo data package" and "standard upgrade". They are both part of the i2b2create_db_*.zip, but there is a distinction in the workflow between NewInstall and Upgrade. You say that the Upgrade Path is intended to upgrade the demo data. That seems like an error in itself since it would not provide a way to upgrade for users with actual in-production i2b2 instances. (and not demo data)
          My assumption was that Upgrade is for in-production i2b2 instances, and that Upgrade must work even if you didn't follow the last step in the install of each cell, which is typically running the "db_*_load_data" target in data_build.xml. In the particular case of Metadata, there are two steps:
          ant -f data_build.xml create_metadata_tables_release_1-7
          ant -f data_build.xml db_metadata_load_data
          This second step (db_metadata_load_data) should be optional. As the install guide says, "If you have your own Metadata and wish to load it instead of the i2b2 sample Metadata you can do it at this point of the installation."
          It's only that second step that runs table_access_insert_data.sql and schemes_insert_data.sql. Therefore the lone upgrade_metadata_tables_release_1-7 target should not be running those scripts, since you may or may not have installed the demo data and it is not a requirement to run i2b2. (but it IS necessary to run this upgrade script to update i2b2)

          The simplest fix to my specific problem would be defaulting ICD9_ICD10 to 'CH' instead of 'CA'. I didn't encounter any problems with upgrade besides that.

          Generally it would be logical to split the Demo Data install package out of the createdb package, and instead of "upgrading" Demo Data, have the script (optionally) wipe everything and install the data fresh for each release.

          Thanks.
          zabeus Joseph Applegate added a comment - Sorry I must have created a false mental distinction between "demo data package" and "standard upgrade". They are both part of the i2b2create_db_*.zip, but there is a distinction in the workflow between NewInstall and Upgrade. You say that the Upgrade Path is intended to upgrade the demo data. That seems like an error in itself since it would not provide a way to upgrade for users with actual in-production i2b2 instances. (and not demo data) My assumption was that Upgrade is for in-production i2b2 instances, and that Upgrade must work even if you didn't follow the last step in the install of each cell, which is typically running the "db_*_load_data" target in data_build.xml. In the particular case of Metadata, there are two steps: ant -f data_build.xml create_metadata_tables_release_1-7 ant -f data_build.xml db_metadata_load_data This second step (db_metadata_load_data) should be optional. As the install guide says, "If you have your own Metadata and wish to load it instead of the i2b2 sample Metadata you can do it at this point of the installation." It's only that second step that runs table_access_insert_data.sql and schemes_insert_data.sql. Therefore the lone upgrade_metadata_tables_release_1-7 target should not be running those scripts, since you may or may not have installed the demo data and it is not a requirement to run i2b2. (but it IS necessary to run this upgrade script to update i2b2) The simplest fix to my specific problem would be defaulting ICD9_ICD10 to 'CH' instead of 'CA'. I didn't encounter any problems with upgrade besides that. Generally it would be logical to split the Demo Data install package out of the createdb package, and instead of "upgrading" Demo Data, have the script (optionally) wipe everything and install the data fresh for each release. Thanks.
          Perhaps something should be in the 1.7 upgrade doc to indicate that the metadata update is optional.
          lcp5 Lori Phillips added a comment - Perhaps something should be in the 1.7 upgrade doc to indicate that the metadata update is optional.
          zabeus Joseph Applegate added a comment - - edited
          You're right. It was only Metadata causing the issue and I could have skipped it.

          My comment above was more theoretical than specific to 1.7.
          zabeus Joseph Applegate added a comment - - edited You're right. It was only Metadata causing the issue and I could have skipped it. My comment above was more theoretical than specific to 1.7.
          Changed the issue from bug to documentation.
          jmd86 Janice Donahoe added a comment - Changed the issue from bug to documentation.

          People

            jmd86 Janice Donahoe
            zabeus Joseph Applegate
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated: