Mio padre è un medico. Sta insistendo per scrivere un database per archiviare informazioni non critiche per il paziente, senza background di programmazione [chiuso]

Quindi, mio ​​padre è attualmente in procinto di "hackerare" un database usando FileMaker Pro, uno strumento di database basato sulla GUI per la sua piccola pratica (4 dottori). Il database verrà utilizzato per aiutare ad alleviare l'onere per la segnalazione da macchine mediche, semplificando un processo piuttosto maldestro.

Non ha esperienza di programmazione e sembra che stia facendo tutto ciò che è in suo potere per non apprendere correttamente le cose. Ha tipi di dati duplicati, nessuna relazione forzata con il database (vincoli di chiave esterna / primaria) e una dozzina di altri problemi. Lo sta facendo tutto a mano tramite lo strumento GUI usando i video di Youtube.

Il mio problema è che, mentre voglio che abbia successo al 100%, non penso che sia appropriato per lui gestire questo tipo di decisioni. Come posso convincerlo che senza una sorta di educazione in questi argomenti, una soluzione hackerata insieme è una cattiva idea? Può essere piuttosto testardo e penso che veda questi tipi di lavori come "giochi da bambini"

Come dovrei avvicinarmi a questo? È anche una cattiva idea - o ho ragione nel pensare che dovrebbe assumere un DBA / sviluppatore adeguato per gestirlo in modo che non diventi un incubo di manutenzione?

NB: Sono un consulente per sviluppatori di 4 anni e ho visto la mia parte di implementazioni dolorose da parte dei clienti.

Aggiornare:

Quindi sono passati alcuni anni e ho avuto il tempo di riflettere su questa domanda. Mio padre ha finito per implementare una soluzione utilizzando Google Docs, FileMaker Pro e alcuni hook di posta elettronica. Ha messo tutto da solo, e dice che ne sta ricavando un valore immenso.

Se sei uno sviluppatore esperto, stai forse leggendo quella descrizione e facendo il cring. Ma in realtà ho imparato una lezione abbastanza buona dall'intera faccenda - che le persone si preoccupano solo dei risultati e non dell'implementazione. Tutto ciò che interessa a mio padre è il fatto che non ha bisogno di inserire manualmente le informazioni del paziente su carta e può invece compilare rapidamente un modulo di Google Documenti. La cosa fantastica è che sta cercando di assumere una persona junior per concentrarsi esclusivamente sull'automazione all'interno della sua pratica.

Ho progettato soluzioni sanitarie per molti anni. Non entrerò in tutti i diversi motivi per cui tuo padre non dovrebbe farlo; la maggior parte dei motivi è accademica: significa che se sei stato nel settore abbastanza a lungo sai come queste cose nevicano e sviluppano una vita propria.

Invece tuo padre, come medico, deve comprendere le ragioni professionali e le ragioni della vita reale, non accademiche, per cui ciò che sta facendo è pericoloso e forse in pericolo di vita; pericoloso per i suoi colleghi, pericoloso per la privacy e l'identità dei suoi pazienti e pericoloso per la sua pratica dal punto di vista legale.

Il pericolo è sfaccettato:

1. privacy del paziente (HIPAA, ARRA, uso significativo, conformità HITECH)
   • quali sono i campi che sono considerati campi di identificazione del paziente (molti professionisti del settore non lo capiscono, e solo perché si eliminano alcuni dei campi ovvi come cognome, indirizzo, codice postale ci sono ancora molti altri campi che lo renderebbero facile associare i dati clinici a un paziente specifico; questo, di per sé, è difficile; ci sono aziende là fuori che fanno un sacco di soldi per identificare i dati clinici - è un intero dominio in sé).
2. HIPAA, HITECH e la nuova legislazione spiegano chiaramente come
   • il controllo dovrebbe essere fatto
   • la sicurezza dovrebbe essere fatta
   • requisiti di password
   • i dati a riposo devono essere crittografati
   • i dati trasmessi devono essere crittografati e come
   • è necessario considerare i controlli se si utilizza qualsiasi tipo di servizio ospitato (IaaS, PaaS)
   • hai predisposto BAA e DSA adeguati
   • in che modo quelli che ospitano i tuoi server controllano l'accesso
   • come gestiscono il multi-tenancy (rimarrai stupito di come alcune di queste entità di grandi dimensioni NON lo gestiscono in modo appropriato)
   • se risolvi il contratto con coloro che ospitano la tua infrastruttura, come assicureranno la cancellazione permanente dei tuoi dati (regolamenti NIST)
3. quali sono i controlli governativi in ​​atto per il tuo sviluppo
   • hai un SDLC in atto
   • hai tracciabilità dai requisiti al codice fino al QA?
   • convalidi l'uso "previsto" della tua applicazione / dispositivo medico
4. il tuo software è QA e hai un ambiente User Acceptance Test (UAT)
   • come proteggete questo ambiente, poiché userete i dati reali dei pazienti
5. gestirà i pazienti con assistenza sanitaria statale, in caso affermativo ha intenzione di utilizzare il suo database per riferire?
   • il governo ha istituito severi controlli per lo scambio di questi dati con il loro scambio di informazioni sanitarie (HIE)
   • il che porta a come implementerà il proprio scambio se vuole trarre vantaggio dal suo archivio di dati clinici (CDR)
6. capisce le particolari norme NIST che deve rispettare per la sicurezza dei dati
   • come la cancellazione permanente dei dati (se si utilizza un'infrastruttura ospitata)
7. hai detto che prenderà i dati dalle macchine mediche
   • capisce i nuovi standard dei dispositivi medici FDA?
   • a partire dal 2013, qualsiasi sistema digitale che visualizza i dati provenienti da dispositivi medici può essere classificato come dispositivo medico ... ciò significa che deve soddisfare i requisiti normativi FDA per i dispositivi medici
8. il suo team e il suo personale prenderanno decisioni mediche sulla base dei dati contenuti nel suo database?
   • ha sviluppato un solido modello di dati clinici, abbastanza flessibile da gestire i requisiti in continua evoluzione (cioè da ICD-9 a ICD-10 a ICD-11 standard di codifica)?
   • come farà la versione del modello di dati e tenerlo sincronizzato con i dati (cioè, se cambia il modello di dati clinici come saranno rappresentati i dati più vecchi?)
   • il suo sistema sarà in grado di produrre un'istantanea esatta dei dati clinici come è stato visto il giorno in cui è stata presa una decisione clinica? ci sono ripercussioni legali se non può
   • conosce la differenza tra una cancellazione reale e una cancellazione logica e le implicazioni per il suo modello di dati; ai suoi requisiti di archiviazione; alle politiche della sua pratica?
   • ha una soluzione di vocabolario in atto per gestire tutti i diversi servizi che dovrà usare? gran parte dei dati devono essere codificati (al contrario del testo libero), perché vorrà sfruttare il suo CDR per produrre report conformi all'ICD-9. E poi deve prendere in considerazione il cambiamento di questi standard; ad es. da ICD-9 a ICD-10.
   • per vocabolario, terminologia o dizionario dei dati sanitari (tutti fondamentalmente sinonimi) come implementerà e garantirà che la vecchia terminologia possa ancora essere resa per vecchie decisioni cliniche?
9. memorizzerà i dati sulle allergie?
   • come verranno archiviate le sue definizioni di "terminologia medica" o "vocabolario"?
   • si integrerà con altri sistemi terminologici come LOINC e First Data Bank?
   • ha una conoscenza dei servizi terminologici (es. Health Data Dictionary)
10. vorrà avere i dati interfacciati nel suo sistema, e magari per uno scambio di informazioni sulla salute (HIE)?
    • in tal caso, comprende HL7 e il suo impatto sul suo database?
    • capisce i motori di interfaccia e tutto ciò che ne consegue?
11. capisce come identificare le informazioni?
    • questo è importante nella fase di sviluppo e nella fase di correzione dei bug

Queste sono solo alcune domande e non dovrebbe assolutamente essere considerato un elenco completo. E per ogni risposta ci saranno innumerevoli altre domande.

In un database sanitario non dovrebbe esserci alcuna cancellazione o sovrascrittura di dati precedenti. Ciò significa che non ci sarà mai "elimina da dove ..." o "aggiorna set ...". Invece avrai solo inserti. Puoi immaginare come questo modifica il tuo modello di dati e le tue query. Ora puoi essere creativo e trovare diverse soluzioni per raggiungere questo obiettivo, ma resta il fatto che questo è un requisito unico per il repository di dati clinici sanitari.

Ancora un altro pensiero riguardo al lato pericoloso di questo problema:

Prendiamo, ad esempio, le informazioni sulle allergie; Sollevo questo perché le istituzioni che lo fanno da anni in digitale hanno appreso che i loro processi devono garantire l'acquisizione dei dati sulle allergie e che non possiamo supporre che, poiché la tecnologia ha acquisito i dati in un database, è in qualche modo intrinsecamente corretta per sempre . Ecco perché ai pazienti vengono chieste le loro allergie ogni volta che si spostano da un reparto all'altro, anche all'interno dello stesso ospedale. Le allergie di un paziente non possono essere eliminate (gli aggiornamenti di una riga eliminano le vecchie informazioni). Una decisione clinica basata su dati digitali deve acquisire ciò che è stato "presentato" al medico al momento della decisione.

So che gran parte di questo potrebbe sembrare orientato a una grande istituzione. Tuttavia, le parti normative non lo sono. E in ogni caso, i sistemi di informazione sanitaria sono intrinsecamente complessi. L'ingegneria dei sistemi sanitari dipende e riconosce la competenza e l'esperienza di buoni medici. Tuttavia, vi è una discrepanza di impedenza superiore alla media (prendere in prestito la terminologia dalla tecnologia ORM) nel dominio IT della sanità ... Mi permetto di dire più grande perché ogni dominio ha i suoi disallineamenti.

In bocca al lupo!

Una soluzione combinata non è sempre male. Se sta risolvendo il suo problema, non ci farei troppo male. Probabilmente ci sono 10 soluzioni hackerate insieme in File Maker e Access per ogni soluzione di database professionale. Dopotutto, ecco a cosa servono Filemaker e Access. Certo, la maggior parte delle soluzioni hackerate insieme sono terribili sotto il cofano. Ma esistono per risolvere i problemi, non per vincere concorsi di bellezza. Spesso l'ambito di queste soluzioni cresce, ed è allora che qualcuno viene assunto per costruire una soluzione professionale.

Quello che potresti fare per aiutare le sue possibilità di successo è esprimere interesse per il suo progetto e offrirti di sederti e aiutarlo a definire il database e ad esaminare tutto. Se non vuole il tuo aiuto ... lascialo cadere e lascialo stare. Che cosa hai intenzione di fare, tasso tuo padre? Se / quando arriva sopra la sua testa, ti farà sapere.

Un'altra cosa da considerare è che se questo è un problema comune tra i medici, potresti avere un'ottima opportunità di business nella creazione di una soluzione generica.

Come progettista di software con oltre 25 anni di esperienza, posso ancora vedere l'attrazione nel creare qualcosa da soli. Spiegare cose a qualcuno che non è esperto in quel settore può essere un enorme ostacolo.

Quindi cosa succede se il database non è normalizzato o potrebbe essere reso più veloce? Molti software non critici (specialmente nell'era dell'agile) seguono il principio wabi-sabi. Fa quello che deve fare e non di più.

Ti preghiamo di notare che non tutti i software devono urlare insieme a un'interfaccia perfetta, un accesso al database estremamente veloce e una GUI immacolata.

Il mio problema è che, mentre voglio che abbia successo al 100%, non penso che sia appropriato per lui gestire questo tipo di decisioni.

Filemaker ha iniziato come un database che chiunque potrebbe usare e funziona ancora molto bene in quel ruolo. Se tuo padre sa cosa vuole e si sente a proprio agio nel metterlo insieme, di cosa ti preoccupi? Se funziona come vuole, vince. Se non funziona come vuole, lo risolverà.

Avresti ragione a preoccuparti se stava costruendo un database per tutti i dottori che lavorano per Kaiser Permanente, ma se sta solo costruendo uno strumento da usare nella sua pratica, sembra che probabilmente sia esattamente la persona giusta per gestire questi decisioni.

Non lasciare che perfetto sia nemico del bene.

Il mio consiglio è di far finta che non esista altrimenti ti farà impazzire. Ho un parente che ha fatto una cosa simile con la sua lista di clienti, e ciò che ha creato da solo è una mostruosità. Inizialmente mi sono offerto di aiutare e ha pensato che la mia citazione (che aveva un forte sconto "famiglia") era scandalosa. Dopo averlo visto, ho suggerito un sacco di cambiamenti, che mi ha chiesto di apportare in cambio di "un paio di birre". Famiglia o no, Homie non ci gioca. Gli ho detto che avrebbe dovuto assumere qualcuno per farlo, ma non l'ha mai fatto. Ho dovuto solo tagliarmi completamente fuori e far finta che non esistesse, solo per evitare che la terribile del progetto mi mangiasse.

Dovresti lasciarlo provare. Tuttavia, dovresti renderlo consapevole del fatto che quando raggiunge un vicolo cieco, è un suo problema e qualsiasi sviluppatore che decide di assumere a quel punto, dovrà iniziare da zero.

Mi piace unire le cose molto insieme, come mobili e persino impianti idraulici. Mi diverto e non vedo nulla di sbagliato in questo. Non avrei mai nemmeno il coraggio di chiedere a un abile artigiano di saltarmi addosso quando rimango bloccato, semplicemente perché penso che vomiteranno alla semplice vista delle mie creazioni.

Quindi lascia che tuo padre faccia quello che gli piace, ma cerca di fargli capire i rischi. Spiegagli semplicemente che quando a un certo punto assume uno sviluppatore qualificato per "aggiungere solo una piccola funzionalità", è come chiedere agli artigiani esperti di "sistemare solo un paio di cose" in una casa dove sono stati fatti quasi tutti i collegamenti elettrici e idraulici con nastro adesivo, foglio di alluminio, plastilina e buona fede.

vede questi tipi di lavori come "un gioco da ragazzi"

Sono un consulente per sviluppatori di 4 anni

Per il tuo benessere e lo sviluppo personale di tuo padre, lascialo fallire. La risposta di John è solida e dovresti menzionarne abbastanza per impedire a tuo padre di andare dalla parte sbagliata della legge, o almeno abbastanza da conoscerlo meglio. Ma tutta questa "umiltà" non è qualcosa che puoi insegnare alle persone e aspettarti che le imparino. È una lezione di vita molto importante per fare del tuo meglio e fallire completamente. Il fallimento è un insegnante molto potente. E potrebbe ottenere un certo rispetto per la professione di suo figlio.

E hey, se riesce a mettere insieme qualcosa che funziona abbastanza bene (e non viola alcuna legge), tanto più potere per lui.

Sono affari suoi. E se è determinato, lo farà funzionare. E molte persone hanno messo insieme soluzioni di varie tecnologie per far funzionare le cose.

Anni fa, ho rivisto il codice di un mio amico che ha messo insieme un'applicazione web con PHP e alcuni software di bacheca. Lo ha personalizzato pesantemente per soddisfare le sue esigenze. Il codice era un abominio. Oltre ad essere a malapena il 1 ° modulo normale, aveva tag HTML con dati nel suo database. Nessuna separazione MVC. Ma Dio lo benedica. La sua domanda ha funzionato ed è stato in grado di pagare le sue bollette con le entrate di quel sito web.

Il mio consiglio per lui era questo: se ti accontenti di mungere la tua domanda di introiti il ​​più a lungo possibile, allora non rifattorizzarla usando buone tecniche di progettazione del software e lascia "abbastanza bene" da solo. Se vuoi far evolvere la tua applicazione per offrire più servizi e ottenere maggiori entrate, dovrai pagare e riformattare il codice. Ha scelto di andare con il primo. È la vita.

Se tuo padre non sente il dolore della duplicazione dei dati e della debole integrità dei dati ora, lo farà più tardi e solo allora imparerà il valore di ciò che stai dicendo.

Penso che la risposta alla tua domanda dipenda principalmente da quanto sia cruciale per la sua pratica medica questa applicazione. Conserverà lì solo alcuni dati dei pazienti che ritiene utili o eventuali malfunzionamenti di questa applicazione potrebbero avere gravi conseguenze? Se può avere gravi conseguenze, allora non dovrebbe farlo, ma perché non stiamo vivendo in un mondo perfetto convincendolo che non è una buona idea potrebbe essere una questione completamente diversa.

Dato che sei un consulente per sviluppatori, suggerirei di offrirgli aiuto nel controllo qualità e nel processo di test. In questo modo manterrai un buon rapporto con tuo padre perché lo stai "aiutando" ma allo stesso tempo puoi assicurarti che la sua app stia facendo quello che dovrebbe fare o anche trovare un problema che non sarà in grado di risolvere così cercherà una soluzione più professionale.

A proposito, ho visto molte app terribili che stavano facendo il loro lavoro e nessuna spiegazione sul perché è terribile convincere chiunque a fare dei veri cambiamenti in esso.

Come ingegnere informatico recentemente in pensione per un grande fornitore di servizi sanitari senza scopo di lucro, consiglio vivamente di cercare un ospedale o una pratica di grandi dimensioni nelle vicinanze che possa, a un costo ragionevole, consentirgli di condividere il loro sistema di cartelle cliniche elettroniche che soddisfi i requisiti dell'iniziativa sull'uso significativo (e altri programmi di incentivazione governativi).

Sono consapevole che "Epic" ( http://Epic.com ) supporta i propri clienti consentendo ai fornitori più piccoli di condividere il loro sistema, e immagino che anche alcuni dei loro concorrenti lo facciano. Cerner è il loro principale concorrente, ma molti altri sono discussi su http://www.beckershospitalreview.com/healthcare-information-technology/50-things-to-know-about-epic-cerner-meditech-mckesson-athenahealth-and- altri-major-ehr-vendors.html

C'è un sussidio del 75% da CMS per quel tipo di condivisione. Abbiamo trasferito il sussidio ai nostri clienti rendendo il prezzo di abbonamento del 25% del nostro costo.