Request | Notes | Status | Fixed/Updated/Removed from SDTMIG v4.0? |
---|---|---|---|
This is sponsor inquiry. How do you model pre-specified ANA tests? | Question about how to model ANA data that are collected, and therefore should be molded differently from the example that's shown in the SDTMIG 3.4. | RESOLVED | UPDATE COMPLETE 2023-03-24: Added to SDTMIG v4.0. |
User Inquiry:
"I wanted to revisit this discussion on ANA pattern reporting. We also deal with testing labs where they pre-coordinate the pattern result into the test name and perform a call of whether the pattern is observed or not. For example, the 'test' the lab performs evaluates each staining pattern as listed below:
Anti-Nuclear Antibody Centromere Pattern, Char |
Anti-Nuclear Antibody Centrosome Pattern, Char |
Anti-Nuclear Antibody Cytoplasmic Pattern, Char |
Then, the result for each of these tests is 'POSITIVE' or 'NEGATIVE', affirming presence or identity of the specific pattern in question. "
In cases like these and the study is submitting under SDTMIG v3.4, should we simply add each of these patterns as sponsor-extended ISTEST/TESTCD terms? Or, would it be acceptable that these remain in LB (MI is also another possible consideration...)?
Our Recommendations and Rationales:
For modeling Open-ended Findings Question vs. Prespecified Findings Question, analogy can be drawn from the MB domain modeling principles. For modeling pre-specified findings vs open-ended findings in MB, the approach has been:
- When asking an open-ended “what bug do you have in the culture” question, MBTEST = Microbial Organism Identification; MBORRES = Name of the Microorg (from the Microorg codelist).
- When asking for a pre-specified finding “do you have this particular named bug in the culture” type question, MBTEST = Name of the specific Microorg, MBORRES = positive/negative, present/absent.
The MB example is to illustrate that the result of an open-ended findings question becomes the test or a test qualifier for the pre-specified findings question. This modeling principle applies consistently in IS as well.
Therefore for the pre-specified ANA Stain Pattern tests,
- ISTEST = Autoantibody; ISBDAGNT = Nuclear Autoantigens; ISTSTDTL = Centromere Pattern/ Cytoplasmic Pattern/or other specific ANA Patterns; ISOORES = Positive/Negative. In this case, the ANA pattern results are mapped to ISTSTDTL, because they are “pre-specified” findings, and you are asking the question “do you observe this ANA pattern?”
- The IS example 10 in the SDTMIG 3.4 where ISTSTDTL = Staining Pattern, essentially serves to asks the “open-ended” question of “what ANA pattern do you observe?” - the specific ANA patterns are then treated as results.
- Additionally, having the values of “Staining Pattern”, “Centromere Pattern/ Cytoplasmic Pattern/or other ANA Patterns” mapped to IS Test Detail, is also the consistent use of this variable.
Open-ended findings modeling: What antinuclear antibody staining pattern(s) do you observe in the specimen? (This is the IS Example 10 in the SDTMIG v3.4)
Con: This approach would only allow people to report the positive findings - ANA patterns that have been observed and reported as results. Patterns that are not observed will not be reported.
Supporting LOINC codes:
- https://loinc.org/14722-3/ Presence
- https://loinc.org/29953-7/ Titer
https://loinc.org/14611-8/ Pattern
Example: IS Example 1
Pro:
- This approach allows the users to report both the "specific, pre-specified" positive and negative patterns.
- This is also almost a 1:1 mapping to LOINC codes.
- Consistent modeling approach across specimen-based domains.
Supporting LOINC Codes:
- https://loinc.org/53994-0/ Presence
https://loinc.org/96921-2/ Titer
Example: IS Example 2
Decisions and Additional Notes/Action Items:
- Team is happy with both approaches, this "reciprocal" modeling approach provides flexibility and allows sponsors to accommodate different data collection schemas. It is also highly consistent with LOINC, both example have LOINC codes corroboration.
- Jordan already added this one to the SDTMIG v4.0.
Resolution Status: | Date |
---|---|
APPROVED |
|