Valutare lo stato del software per l'imaging medico
Uno sguardo dettagliato sulle pratiche attuali del software di imaging medico e aree di miglioramento.
― 4 leggere min
Questo articolo parla di come si stanno comportando attualmente i Software di imaging medico. L'imaging medico è importante perché aiuta i dottori a vedere dentro il corpo senza dover fare un'operazione, usando tecnologie come le risonanze magnetiche e le TAC. Ci sono molti programmi software che elaborano e analizzano queste immagini, e volevamo vedere come vengono sviluppati e mantenuti.
Selezione del Software da Rivedere
Abbiamo esaminato 48 diversi progetti di software di imaging medico e ne abbiamo scelti 29 da valutare. Abbiamo controllato 10 qualità per ciascun progetto, come facilità di installazione, correttezza, affidabilità, usabilità e qualità della Documentazione. Per ogni software, abbiamo risposto a un insieme di 108 domande. Abbiamo anche intervistato otto team che hanno sviluppato alcuni di questi prodotti software per avere approfondimenti sulle loro esperienze.
Classifica del Software
Utilizzando un metodo chiamato Analytic Hierarchy Process (AHP), abbiamo classificato il software in base alle prime nove qualità. I primi quattro software erano 3D Slicer, ImageJ, Fiji e OHIF Viewer. I nostri risultati corrispondevano per lo più alle opinioni della comunità, poiché molti dei progetti top mostravano una popolarità simile su piattaforme come GitHub.
Salute Attuale del Software di Imaging Medico
In generale, la situazione del software di imaging medico è abbastanza buona. Abbiamo trovato che l'88% della documentazione necessaria era presente nei progetti che abbiamo studiato e tutti loro usavano strumenti di controllo versione, che aiutano a tenere traccia delle modifiche al software. La maggior parte degli Sviluppatori sembrava seguire un processo agile flessibile nel loro lavoro di sviluppo.
Tuttavia, c'erano alcune aree da migliorare. Abbiamo notato che alcuni documenti raccomandati, come i piani di test e la documentazione dei requisiti, erano raramente trovati. Solo il 17% dei progetti utilizzava Integrazione Continua, e circa la metà dichiarava di non avere test unitari. Sei su nove sviluppatori hanno detto che la loro documentazione potrebbe essere più chiara.
Problemi nella Sviluppo
Attraverso le interviste, abbiamo identificato le principali sfide che gli sviluppatori affrontano. Queste includevano mancanza di tempo e finanziamenti, difficoltà nell'assicurare correttezza e usabilità, e problemi con la manutenzione del software. Gli sviluppatori hanno suggerito diverse strategie per migliorare la loro pratica, tra cui una migliore documentazione, un aumento dei test, l'uso di applicazioni web e l'adozione di pratiche di programmazione in coppia.
Pratiche Raccomandate
Basandoci sui nostri risultati e sul feedback degli sviluppatori, abbiamo creato un elenco di raccomandazioni per aiutare a migliorare il software di imaging medico. Queste includono:
Aumentare la Documentazione: Una migliore documentazione può aiutare i nuovi sviluppatori a capire il software, risparmiando tempo durante lo sviluppo.
Aumentare i Test: Test più approfonditi possono aiutare a catturare gli errori precocemente. Questo potrebbe coinvolgere l'uso di dataset migliori per il Testing.
Migliorare la Modularità: Progettare il software in parti più piccole e indipendenti può migliorare la manutenibilità e rendere più facile l'aggiornamento.
Usare Integrazione Continua: Questa pratica implica testare regolarmente il software con ogni aggiornamento per catturare i bug rapidamente.
Passare alle Applicazioni Web: Sviluppare software basato sul web può migliorare l'accesso e l'usabilità per gli utenti finali.
Utilizzare Linters: I linters sono strumenti che possono controllare automaticamente il codice per errori e far rispettare gli standard di codifica, contribuendo a migliorare la qualità del codice complessiva.
Condurre Revisioni tra Pari: Incoraggiare gli sviluppatori a revisionare il codice degli altri può migliorare la qualità e la condivisione delle conoscenze.
Progettare per il Cambiamento: Il software dovrebbe essere progettato per adattarsi facilmente ai cambiamenti nei requisiti o nella tecnologia.
Usare Casi di Assicurazione: Questi sono argomenti strutturati che mostrano che il software soddisfa determinati standard di qualità, aiutando a garantire la correttezza e la riproducibilità.
Generare Tutto: Questo approccio implica creare automaticamente non solo codice, ma anche documentazione e test, contribuendo a semplificare il processo di sviluppo.
Direzioni Future
Man mano che continuiamo a valutare lo stato del software di imaging medico, speriamo di vedere miglioramenti nelle pratiche utilizzate dagli sviluppatori. Implementando le suggerimenti elencati sopra, crediamo che il software di imaging medico possa diventare ancora più affidabile ed efficiente, portando infine a risultati migliori per pazienti e provider sanitari.
Conclusione
In sintesi, il panorama del software di imaging medico è piuttosto forte ma ha margini di miglioramento. Concentrandoci su pratiche di qualità nello sviluppo del software, nella documentazione e nel testing, possiamo garantire che questi strumenti continuino a supportare i dottori e i ricercatori nel loro lavoro critico.
Titolo: State of the Practice for Medical Imaging Software
Estratto: We selected 29 medical imaging projects from 48 candidates, assessed 10 software qualities by answering 108 questions for each software project, and interviewed 8 of the 29 development teams. Based on the quantitative data, we ranked the MI software with the Analytic Hierarchy Process (AHP). The four top-ranked software products are 3D Slicer, ImageJ, Fiji, and OHIF Viewer. Generally, MI software is in a healthy state as shown by the following: we observed 88% of the documentation artifacts recommended by research software development guidelines, 100% of MI projects use version control tools, and developers appear to use the common quasi-agile research software development process. However, the current state of the practice deviates from the existing guidelines because of the rarity of some recommended artifacts, low usage of continuous integration (17% of the projects), low use of unit testing (about 50% of projects), and room for improvement with documentation (six of nine developers felt their documentation was not clear enough). From interviewing the developers, we identified five pain points and two qualities of potential concern: lack of development time, lack of funding, technology hurdles, ensuring correctness, usability, maintainability, and reproducibility. The interviewees proposed strategies to improve the state of the practice, to address the identified pain points, and to improve software quality. Combining their ideas with ours, we have the following list of recommendations: increase documentation, increase testing by enriching datasets, increase continuous integration usage, move to web applications, employ linters, use peer reviews, design for change, add assurance cases, and incorporate a "Generate All Things" approach.
Autori: W. Spencer Smith, Ao Dong, Jacques Carette, Michael D. Noseworthy
Ultimo aggiornamento: 2024-05-20 00:00:00
Lingua: English
URL di origine: https://arxiv.org/abs/2405.12171
Fonte PDF: https://arxiv.org/pdf/2405.12171
Licenza: https://creativecommons.org/licenses/by/4.0/
Modifiche: Questa sintesi è stata creata con l'assistenza di AI e potrebbe presentare delle imprecisioni. Per informazioni accurate, consultare i documenti originali collegati qui.
Si ringrazia arxiv per l'utilizzo della sua interoperabilità ad accesso aperto.
Link di riferimento
- https://github.com/tomgi/git_stats
- https://github.com/boyter/scc
- https://api.github.com/repos/
- https://github.com/smiths/AIMSS/blob/master/StateOfPractice/MACREM/Application.pdf
- https://www.contributor-covenant.org/version/2/1/code_of_conduct/
- https://ubuntu.com/community/code-of-conduct
- https://www.djangoproject.com/conduct/
- https://google.github.io/styleguide/javaguide.html
- https://cnl.sogang.ac.kr/cnlab/lectures/programming/python/PEP8_Style_Guide.pdf
- https://google.github.io/styleguide/cppguide.html
- https://pypi.org/project/flake8/
- https://www.jenkins.io/
- https://buildbot.net/
- https://www.gocd.org/
- https://integrity.github.io/
- https://travis-ci.org/
- https://github.com/features/actions
- https://circleci.com/
- https://flutter.dev/
- https://vuejs.org/
- https://angular.io/
- https://reactjs.org/
- https://elm-lang.org/
- https://www.django-rest-framework.org/
- https://laravel.com/
- https://nodejs.org/en/
- https://github.com/gin-gonic/gin
- https://nihcc.app.box.com/v/ChestXray-NIHCC
- https://www.cancerimagingarchive.net/
- https://medpix.nlm.nih.gov/home
- https://github.com/pylbm/pylbm
- https://github.com/CFD-GO/TCLB
- https://astah.net/