-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: move ground wire information into its own procedures #1243
base: release-v2.0.0
Are you sure you want to change the base?
refactor: move ground wire information into its own procedures #1243
Conversation
protective_material: ProtectiveMaterial = Field( | ||
..., title="Protective material", description="New material being applied" | ||
procedure_type: Literal["Ground wire implant"] = "Ground wire implant" | ||
ground_electrode_location: MouseAnatomicalStructure.ONE_OF = Field(..., title="Location of ground electrode") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be valuable to have a sublist of structures that we anticipate using for the ground electrode. We currently use BODY_PARTS for the EMG ground wire position, could we make a list called something ~ GROUND_WIRE_PARTS or GROUND_WIRE_LOCATIONS that has all of those plus brain? The full list of anatomical structures is super long and for people using the GUI it will be impossible to navigate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need a subselection of body parts used for ground wires.
These PR refactors ground wire information out of the protective material replacement procedure and fixes a mistake in the
ProtectiveMaterialReplacement.procedure_type
field.I also added a structure target so that this procedure can be used alongside, e.g. the EMG muscle implant procedure instead of embedding that information in that same procedure. This does imply that procedures might need to reference each other, which suggests we need a name field in
DataModel
potentially...