The author mainly made improvements to LandmarksStep.py of this project.We proposed the concept of the Pedicle Tirangle, which refers to the three points of the same vertebral body: the Vertebral Anterior Point (VAP) and the Pedicle Isthmus Point(PIP) of the left and right, formed by As shown in the figure below: the VAP refers to the anterior midpoint of the vertebral body, and the PIP is based on the largest transverse diameter of the vertebral canal as the coronal plane, and the midpoint of the pedicle on both sides of the plane. According to these three points, the plug-in forms the axis of the pedicle by connecting the VAP and the lPIP and rPIP, respectively. In addition, we also designs a preliminary estimate of the length and radius of the pedicle screw.
The extension was originally developed for pedicle screw placement training (for example, measurement of the screw length is intentionally not developed - that is one of the skills that the trainees have to learn), but obviously with some changes the module can be adapted to become a surgical planning tool. We need figure out a way how to manage these two variants:
Option A: convert the current training module to a surgical planning module (the module could no longer be used for training)
Option B: develop the planning module completely separately from the training module (two separate modules that do not share any code)
Option C: have a separate training and planning module, but share some code
Option D: keep a single module but let the user choose between “training” or “surgical planning” modes
It seems that you have now implemented Option A, which means that we lose a number of features. I would particularly miss the beautiful screw models and animated screw insertion. I believe this sophisticated graphics and animation is that makes so many people like this module.
Option B. would be the easiest short-term solution. It would mean that we would have full training and planning modules, without losing any features or having to invest time into refactoring. The disadvantage is that this would double the cost of long-term maintenance (each bug and enhancement would need to be implemented twice, in both modules).
Option C. Would be similar to B in term of user experience but it would require some work right now to refactor the modules. Unlike option B, this option would not double the maintenance effort in the long term.
Option D. Would require significant redesign now (introducing the two operation modes), it might be a bit confusing for users, and it may make a bit more difficult to optimize the user experience in the long term (for example, each change to make the module more friendly for surgical planning may make the module less optimal for training).
@jumbojing What are your long term plans with this extension? Do you plan to continue using and developing it? What features do you plan to add? Do you plan to use it with surgical navigation (tool guidance with optical tracker)? Do you plan to add real-time imaging (ultrasound or surface scanner)? Do you plan to use it on patients?
@ungi Do you think it would be important to preserve a training module (with visual alignment and insertion of realistic screw models)?
This extension is part of the percutaneous three-dimensional guided puncture system developed by us. The guiding system also includes a guiding device and a directional template. With this system, it is our goal to achieve precise intraoperative positioning for minimally invasive surgery.
This part of the current sharing is exploring a new concise and unified imaging solution for percutaneous pedicle puncture.
Well… because of time and ability issues, I gave up those measurements and “the beautiful screw models and animated screw insertion” as you said. Regarding the measurement part, our plug-in gives a solution, including screws Estimation of length and diameter. That “beautiful animation”, after calculating the puncture axis, it seems that “beautiful screw dynamic insertion” is not that difficult.
For the option, I prefer D. After all, the purpose is different, and I don’t know much about training…
I haven’t used this module, and I don’t know anyone actively using it. So I don’t know how important it is to preserve the original training functions.
Thanks for the additional information. If you don’t want to deal with the training use case then option D will not work, because that would mean a tight integration of training and planning/guidance module.
Based on what you describe, C seemed to be the best option - have two separate modules that share some of the code. I’ve updated your pull request and merged your changes accordingly (creating a new PedicleScrewPlanner module, which shares implementation of some steps with the simulator module).
