Shrine Core Ontology:
Adaptermappings for i2b2 Demo Data:
Ontology tips, do's and don'ts
No forced formatting through additional text in metadata field C_NAME
- Most importantly, leading spaces should not be used for forced order of terms, and will result in errors when such terms are included in queries.
- 1 exception: "zz " can be used as a prefix in C_NAME and will not be displayed. A term can be forced to appear last in order of appearance by adding prefix “zz “ to the C_NAME string. This is useful for terms like ‘unknown’ or ‘other’ which may not otherwise appear last in certain demographics categories.
Mapping Ontology to Local Site:
- Mappings can be loaded as xml file or csv file (see mapping files for Demo Data)
- Mappings should be from SHRINE term to local site term, mapping C_FULLNAME fields with 'SHRINE' prefix for SHRINE terms and prefix from TABLE_ACCESS.C_TABLE_CD for Site terms.
- Example: "\\SHRINE\SHRINE\Demographics\Age\0-9 years old\0 years old\","\\i2b2_DEMO\i2b2\Demographics\Age\0-9 years old\0 years old\"
Mapping details for specific data elements:
Modifier Terms should be mapped in the same format as other terms. Mappings are not necessary for various M_APPLIED_PATH values, only for C_FULLNAME.
- The Demo Ontology includes diagnosis modifiers for Admit, Primary, and Secondary Diagnosis. While each modifier is represented in multiple rows for each M_APPLIED_PATH value, each Modifier only requires a mapping from SHRINE C_FULLNAME to i2b2 C_FULLNAME:
"\\SHRINE\Admit Diagnosis\","\\i2b2_DIAG\Admit Diagnosis\"
Query By Values: For SHRINE terms where value based queries are enabled, the mapping should again follow the same format as a standard mapping, however it is also necessary to check the SHRINE.C_METADATAXML against the local i2b2 C_METADATAXML
In order for value based queries to work correctly, the <NormalUnits> represented in the SHRINE.C_METADATAXML must be represented in the local i2b2 C_METADATAXML in one of the follow ways:
Match local <NormalUnits> to SHRINE <NormalUnits>
Include SHRINE <NormalUnits> as local <EqualUnits>
If units are not equivalent, include Shrine <NormalUnits> using <ConvertingUnits><Units></Units><MultiplyingFactor></MultiplyingFactor></ConvertingUnits>, listing Shrine units in <units> and the multiplier needed to convert to local i2b2's <NormalUnits> as <MultiplyingFactor>.
Example: Albumin SerPl-mCnc (Albumin in Serum or Plasma) - LOINC:1751-7
- The Mapping included in the mapping file will map shrine C_FULLNAME to local i2b2 C_FULLNAME, as with a standard mapping. For the Shrine demo ontology and i2b2 demo data, such a mappings will look like:
- "\\SHRINE\SHRINE\Labs\LP31388-9\LP15838-3\LP6118-6\LP43038-6\1751-7\","\\i2b2_LABS\i2b2\Labtests\LAB\(LLB16) Chemistry\(LLB21) General Chemistries\ALB\LOINC:1751-7\"
The C_METADATAXML for the Shrine term includes the following unit specifications:
In the Shrine C_METADATAXML, <EqualUnits> and <ConvertingUnits> are used to enable display options in the shrine Webclient. Any value based query will only send the units listed in <NormalUnits>, as part of the query message sites receive.
Following that, the local C_METADATAXML must be aligned with SHRINE C_METADATAXML for any mapped term in one of the three options listed above and detailed below:
If the local site uses unit with the same format, then <NormalUnits> should look the same for the local C_METADATAXML as for SHRINE.
If the local site uses a different but equivalent unit, (or the same unit but formatted differently), such as gm/dL, then the unit listed for SHRINE in <NormalUnits>, should be included locally in <Equal Units> (g/dL). So the local units within the C_METADATAXML would look like:
If the local site uses a non-equivalent, but convertible unit, such as mg/dL, then the local C_METADATAXML should include the SHRINE terms <NormalUnits>, as Converting Units, with the appropriate multiplier. For the above example the local C_METADATAXML units could look like:
Ontology Load Checklist:
- Ontology navigation for each data element in webclient
- Ontology search by code in webclient works for each data element
- Ontology search by name in webclient works for each data element
Ontology navigation for each data element in webclient
Open Webclient, navigate ontology hierarchy for each data-type
Ontology search by code in webclient works for each data element
Search in webclient for each datatype by code of term. Expected term should return.
Ontology search by name in webclient works for each data element
Search in webclient for each datatype by name of term. Expected term should return.
AdapterMappings Load Checklist
- Queries should execute with expected mapped/unmapped responses
- All mapped terms should return patient count for each mapped site
- Unmapped terms return ‘no mappable local items’
Confirm query returns via small sample test prior to programmatic test
Run sample of basic queries to confirm response
All mapped terms should complete query for each mapped site
Run Scan tool to programmatically test all ontology terms. Compare pre-generated list of mapped local terms to Scan tool results.
Unmapped terms return ‘no mappable local items’
Compare pre-generated list of unmapped local terms to Scan tool results
Data Update Load Checklist:
- Data/Counts should return for new dates added
- Counts for old dates should remain consistent
- Total counts for all dates should increase
Data/Counts should return for new dates added
Execute single term queries with new dates specified.
Counts for old dates should remain consistent
Execute single term queries with previously loaded dates specified. Compare results with previously returned counts (prior to data update).
Total counts for all dates should increase
Execute single term queries with previously loaded dates specified. Compare results with previously returned counts for all dates (prior to data update).