Add iacuc function to utils

[dougollerenshaw]

Adds a function to utils to allow us to pull the iacuc protocol for a given mouse.

Claude Code discovered for me that the trailing portion of the "Group name" field returned by the the labtracks subject endpoint in the metadata service encodes the IACUC protocol. It's not clear to my why it's encoded this way, but I verified that for over 700 mice the protocol returned by this method matches the protocol in the procedures metadata. There were only an handful of exceptions and these seem to be due to the mouse having been transferred to a different protocol after the procedure was performed. So this method seems reliable for giving us the current iacuc protocol.

Use would be:

from aind-metadata-mapper.utils import get_iacuc_protocol
protocol_id = get_iacuc_protocol(subject_id=818908)
print(protocol_id)

Which would return 2414 for this subject.

Confirming:

This should be a step toward resolving these two issues:
#415
#431

[dbirman]

Did you check w/ LAS/NSB if this is consistent? The group_name in my experience varies across mice and over time, I don't think there's a guarantee that this value shows up there. My instinct is to wait until dataverse...

[dougollerenshaw]

@dbirman that's a valid concern. No, I don't know how stable that field will be going forward.

But see @mekhlakapoor's comment here: https://github.com/AllenNeuralDynamics/aind-scientific-computing/issues/787#issuecomment-4684107364. She and Jon are going to add a new table join that will be returned by the labtracks endpoint in the metadata service that will join the actual IacucProtocol table in labtracks, giving us direct access.

And importantly, I also learned that there are currently no plans for keeping the iacuc protocol info in dataverse automatically synced w/ labtracks. We'll be relying on people updating it in both places when mice are transferred (which doesn't happen for every mouse, but it does happen). It's not clear to me if anyone will actually be responsible for doing that. But since LAS/NSB is already interacting regularly with labtracks when transfering mice across protocols, it's likely that labtracks will remain the more reliable source for the current protocol id for a given mouse.

I'm logging an issue with the dataverse team requesting that a system be built to keep labtracks/dataverse in sync automatically without human intervention so it will be on their roadmap. But I don't think we should wait for this to implement this function here. I'll only wait until we have a more reliable labtracks endpoint (within days).

[dougollerenshaw]

@dbirman, see:
AllenNeuralDynamics/aind-labtracks-service#22

I rewrote the function to use the actual protocol_number field. Demo:

>>> from aind_metadata_mapper.utils import get_iacuc_protocol
>>> get_iacuc_protocol(780346)
'2201'
>>> get_iacuc_protocol('780346')
'2201'

Mind a re-review? I actually think this is better than querying dataverse since dataverse will be carrying the same information, but will be relying on potentially fragile processes to stay in sync. labtracks will be the source of truth for the foreseeable future. We can revisit this function to pull from dataverse in some future world where dataverse has become stable and trustworthy.

[dbirman]

The logic here seems right. I noticed you're not actually using it for anything, did you mean to patch this into one of the acquisition mappers or is this future-proofing?

[dougollerenshaw]

Thanks! This is future proofing. I plan to resolve this issue with this new function. But I figured that should be a separate PR.