Page History

New Assumption

NHOID can be used in other specimen-based findings domains to represent the unique identifier for the non-host organism of interest, without the need to develop a separate OI dataset. In other words, users are not required to create OI records, in order to use NHOID in other specimen-based, findings domains.

Related Jira Issue: 

Email thread on adding an assumption to the OI domain

Kathleen: Thursday, April 14, 2022

In many TAUG examples and even in examples available in CDISC’s SDTM IG 3.3 and SDTM IG 3.4, NHOID variable is used in MS, PF/GF (and even some legacy LB) datasets without showing the OI dataset. So my question is, can you use NHOID variable in a findings domain without having the OI domain? I may have overlooked an explicit rule that this is an absolute requirement….Are the examples just incomplete or do sponsors have the flexibility to choose whether or not OI has added value?

For the analogue domain DI & SPDEVID variable there seems to be much more stricter rules specified (if SPDEVID is used anywhere, you MUST have DI domain)….

Jon: Thursday, April 14, 2022

When we drafted the domain, we intended NHOID to be an available identifier without the need for the OI dataset. I don’t see where any conformance rules are published or in process for this, but no one has reached out to us yet. I guess what I’m getting at is that SDS *could* eventually decide that we can’t make it available without OI, but we’d push back on that as it was not our intention.

The original use case for OI (and there are probably other use cases as well) was drug sensitivity testing when you want to parse out which strains/subtypes, etc of a given bug either are or are not susceptible to a drug. In that case you’d need OI to explain the different strains represented by the various NHOIDs.

The only requirements (as I see it) are that :

1. The name must be some intuitive representation of the name of the organism, such as*

1. The name of the bug as reported by a lab or specified by the investigator, or
2. The name of the bug from published references/databases where applicable and appropriate. See OI domain assumption 2b (and I realize assumption 2a explains this in the context of OIPARMCD/OIVAL, which is probably where the confusion comes from).

1. NHOID has to represent bugs that are functionally identical for the purposes of the observations being made, since all records with the same NHOID are assumed to be observations on the same organism. In other words, if, for example, two varints of SARS-COV-2 may behave differently in the observation being made, they cannot share an NHOID.
   If it doesn’t matter, then they can both be called simply “SARS-COV-2”.

Jordan: Thursday, April 14

This is great, honestly it wasn’t clear to me as whether an OI dataset is absolutely required for generating the NHOID, you just cleared any doubts about this subject. Would it be helpful for us to add an additional assumption into the OI domain to really drive that point, for the SDTMIG v4.0?

Something like: NHOID can be used in other specimen-based findings domains to represent the unique identifier for the non-host organism of interest, without the need to create a separate OI dataset. In other words, users are not required to create an OI dataset in order to use the NHOID in other findings domains.

Jon: Friday, April 15, 2022

Yes I think it might help to add that assumption. That will at least get people to weigh in with any complaints they might have if nothing else. I will also check in with Kit Howard about how she feels about that same issue regarding SPDEVID, and whether or not there are specific rules explicitly mentioned for needing the DI dataset. I suspect she will say yes, there is…but their use case is a little different.