Quando si progetta un nuovo sistema in un ospedale o in un altro ambiente clinico, penso che sarebbe importante raccogliere informazioni da medici, infermieri, farmacisti, tecnici e altri casi d'uso del sistema.
A parte il fatto che tutti questi sono anche professionisti impegnati, qual è un buon modo per convincerli a condividere informazioni pertinenti al loro flusso di lavoro (probabilmente caotico e sensibile al tempo) che sarebbe utilizzabile in un progetto di ingegneria del software?
L'unico modo per decodificare ciò che i professionisti medici stanno facendo è osservare la prima mano, mentre stanno lavorando. Trova e segui professionisti disposti e chiacchieroni come il bianco sul riso e chiedi loro di narrare il lavoro e il processo di pensiero. Se hanno bisogno di stimolare, fai domande che guidano verso regole come: Che cosa stai pensando? Perché hai scelto questo oltre a quello? Che cosa sta cercando? Che cosa esclude?
Man mano che impari, condividi il tuo modello mentale e poni domande che modellano & perfezionare le regole. Sii il diario del loro lavoro.
Tutto ciò che manca di osservazione e feedback attivi, pratici, di persona, è indovinare .. non ingegneria.
Un'altra risposta relativa a openEHR, da una prospettiva leggermente diversa ...
L'approccio openEHR sta riscuotendo un notevole successo nella standardizzazione dei requisiti dei dati clinici, vale a dire specifiche dei contenuti EHR definiti dal medico; i medici e la collaborazione degli esperti delle parti interessate per garantire che i modelli siano validi, sicuri e corretti; e governandoli / distribuendoli per l'uso in sistemi EHR clinici. Questo approccio standardizzato aiuta sicuramente a semplificare l'acquisizione del processo del flusso di lavoro, inclusa la documentazione degli ordini e le attività corrispondenti, consentendo in tal modo il monitoraggio del flusso di lavoro. Il responsabile della conoscenza clinica openEHR funge da hub per questa attività: www.openEHR.org/Knowledge.
Alcune giurisdizioni stanno iniziando a utilizzare questo approccio anche per la creazione di standard nazionali di sanità elettronica - link e link
Anche alcune università cliniche professionali stanno iniziando a pensare in questo senso, per garantire che il software costruito dai venditori sia sicuro e idoneo all'uso clinico - Sono consapevole delle attività in corso in Australia, Regno Unito e Stati Uniti.
Investire in lingue specifiche del dominio. Dal punto di vista dello sviluppo del software, il software clinico è complicato, perché puoi sviluppare il software nel modo giusto, ma avrai difficoltà a sviluppare il software giusto. Anche il più brillante analista di business o sviluppatore di software ha difficoltà a comunicare con i medici.
Nelle lingue specifiche del dominio IT della salute (principalmente) corrispondono agli standard relativi alla documentazione sanitaria elettronica. Consulta il link se i medici possono esprimere le loro esigenze utilizzando un linguaggio computabile che descrive il dominio, troverai molto più semplice soddisfare le loro esigenze nel software. Per vedere un esempio dell'approccio di cui sto parlando, puoi dare un'occhiata al nostro progetto open source: link
Saltare giù dal post di David: stai cercando di sviluppare un prodotto EHR generale o hai un'installazione specifica del sito del cliente? Stiamo sviluppando un sistema di EHR oncologico interno e non so nemmeno dove si svolgerà questo progetto senza essere in ufficio tutti i giorni. Se vuoi veramente imparare una pratica, hai davvero bisogno di molto tempo e tempo in cui puntano sullo schermo come dovrebbe essere diverso.
Più ti allontani dai tuoi clienti, più la comunicazione è lenta e più stai programmando ciò che pensi di volere, e non quello che vogliono.
E ricorda: la maggior parte delle funzionalità interesserà più persone, infermieri, amministratori, ecc. quindi è fondamentale avere input da tutti e prendere decisioni informate.
Leggi altre domande sui tag design requirements-management healthcare