Ortocomputer

Imparando dai Grandi

2024-02-28T00:00:00+00:00

Tutti gli illustri artisti e scienziati che hanno lasciato un segno indelebile nella storia si sono ispirati ai giganti che li hanno preceduti. È utile, se non fondamentale, imitare le loro gesta prima di raggiungere l’eccellenza.

Troppo spesso noi programmatori, provenienti da ambiti diversi e pieni di entusiasmo, ci cimentiamo nell’ardua impresa di sviluppare un software gestionale senza ponderarne a fondo la complessità. “Dopotutto, quanto può essere difficile? È solo un altro gestionale.” Sviluppare un’applicazione da zero non è un’impresa titanica, come molti hanno dimostrato in passato. Ma così facendo, il livello di qualità rimarrà probabilmente simile a quello sviluppato da altri. Tuttavia, non sarebbe vantaggioso aspirare a superare i limiti precedenti, a innalzare lo standard di tecnologia e qualità? L’informatica clinica moderna si trova su un piano di eccellenza ben più elevato di quello che potremmo raggiungere da soli, partendo da zero.

Per realizzare gestionali all’avanguardia, è essenziale immergersi negli studi e nelle opere dei pionieri del settore. Di seguito, una lista di risorse fondamentali che ogni esperto di informatica clinica dovrebbe conoscere:

Attraverso la conoscenza e l’applicazione di queste risorse, possiamo aspirare a contribuire in modo significativo all’evoluzione della informatica clinica.

Procedura PIOSEE per risoluzione dei problemi

2022-06-25T00:00:00+00:00

Durante il nostro lavoro, cerchiamo di approcciare i problemi in maniera sistematica e oggettiva, prendendo ispirazione dal mondo dell’aeronautica e ingegneria. Qui sotto riportiamo la procedura PIOSEE, come la applichiamo noi. Si tratta di una procedura che ho sentito da un You-Tuber di nome Mentour Pilot per la prima volta, ma che si incastrava parecchio con il mio modo di approcciare i problemi. È stato molto utile poterla vedere sviscerata.

Fase 1 (P): Definizione del Problema

Un problema può originare da varie fonti. Indipendentemente dalla fonte del problema (che venga fatto presente dal cliente, o che venga messo alla luce da procedure interne), dobbiamo capire molto bene di cosa si tratta. Per questo interroghiamo la fonte, per capire esattamente quale obbiettivo si cerca di ottenere. A volte un problema sembra indicare una mancanza di un sistema, ma in verità si tratta solo di capire quale è la esigenza effettiva della persona o dello studio per poi scoprire che è sufficiente utilizzare una procedura diversa per eliminare l’apparente mancanza.

In questa fase, dopo aver identificato il problema, si crea un ticket, avente nella descrizione una chiara definizione misurabile della deliverable, ossia del nuovo stato. In altre parole, deve essere possibile leggendo la descrizione e conoscendo lo stato delle cose, definire, in maniera inequivocabile, quando il ticket è terminato.

Per esempio, un ticket intitolato “mettere a posto stampante” non ha un obiettivo chiaro, e sarà difficile sapere quando chiuderlo, specialmente se la stampante ha vari problemi. Un ticket con la descrizione “La stampante laser reception stampa caratteri geroglifici su fogli prevalentemente vuoti anziché quello che si vuole stampare quando si stampa da Pages.app sulla workstation amministrativa” diventa facile da chiudere: chiunque in grado di aprire Pages.app sulla workstation amministrativa e stampare, può verificare se la stampante in reception stampa ancora geroglifici. E se non lo fa, può chiudere il ticket, anche se la stampante presenta altri problemi.

Fase 2 (I): Raccolta Informazioni

Qua si raccolgono le informazioni che hanno a che vedere con il problema in questione.

La “deliverable” di questa fase sarà la presenza di informazioni aggiornate e attuali dello stato del backup/documentazione nella relativa pagina wiki del software in questione.

Fase 3 (O): Studio delle Opzioni

In questa fase, studiamo la differenza tra dove si vuole arrivare, e lo stato attuale, per produrre una lista di tutti i possibili/attualmente visibili piani di attacco.

La deliverable di questa fase potrebbe essere l’inserimento nel ticket di una bozza delle varie opzioni, senza opinioni. Una lista oggettiva.

Fase 4 (S): Seleziona una Opzione

In questa fase:

una delle opzioni della Fase O-pzioni viene selezionata, in base a certi criteri, come potrebbero essere priorità e importanza dei ticket, costi, ore di lavoro, ecc.
l’opzione selezionata viene espansa e sviluppata in un vero e proprio piano, fino al limite delle proprie conoscenze. Per esempio, è se faccio un mega piano di lavoro super-dettagliato per i prossimi 3 mesi, basato su speculazioni, magari ci metto delle ore. Ma poi verrà quasi sicuramente ri-formulato. Meglio dedicare 20-30m per fare un piano realistico, più dettagliato per i passi più prossimi e visibili, e meno per quelli venturi. E poi nel tempo raffinare il piano, aumentarne la risoluzione come si va avanti, come fanno i motori di rendering dei simulatori e videogiochi.

La “deliverable” di questa fase, potrebbe essere la creazione di vari ticket che rappresentano i vari passaggi dell’opzione selezionata, e la loro organizzazione corretta, temporale o prioritaria, per esempio, in una “board” che supporta il ranking. È importante che ogni ticket abbia una chiara meta misurabile (deliverable), in modo da sapere in maniere inequivocabile, quando questo ticket si possa considerare concluso.

Fase 5 (Ex): Esecuzione del piano

Qua è dove finalmente si esegue il lavoro.

La “deliverable” di questa fase sarà il piano definito qui sopra eseguito per intero. Ovvero tutti i ticket creati, conclusi.

Fase 6 (Ev): Valutazione del lavoro

Dipendendo dal lavoro che viene fatto, la fase Ex-ecuzione e la fase Ev-alutazione possono essere separate o distinte. Penso che nella maggior parte dei casi, le fasi I-O-S-Ex-Ev vengano loopate in corso d’opera.

Per esempio, dopo il lavoro preliminare di I-O-S-Ex, salta fuori una nuova informazione I, che prima non avevamo. Questo fa si di aggiungere o modificare la lista di O opzioni. Che ci permette di cambiare la selezione dell’opzione S, e quindi l’esecuzione.

Oppure, dopo l’esecuzione parziale in fase Ex, si nota che gli effetti non producono i risultati desiderati, e si decide di S-elezionare un’altra delle O-pzioni, pertanto iniziando una nuova fase Ex-ecutiva.

Ad ogni modo, questa fase serve per migliorare sia la procedura attuale, che quelle future. È pertanto indicato in questa fase di produrre come deliverable qualche forma di documentazione che possa essere ri-utilizzata in futuro per procedure simili. Come nuove regole, nuove procedure, aggiornamenti al wiki di procedure esistenti, registrazione del tempo che ci si è messo per completare la procedura, ecc. In una procedura andata storta, questa fase potrebbe produrre un IR (incident report).

Le deliverable di questa fase sono:

modifiche del piano esecutivo, correzione del tiro
registrazione di una analisi più o meno dettagliata da poter usare in futuro (ore di lavoro, incident report, …)

Perché non abbiamo un account Whatsapp?

2022-06-13T00:00:00+00:00

In breve: perché non è interoperabile. Ti sei mai chiesto perché devi installarti 5 o più programmi di messaggistica (Telegram, Whatsapp, Signal, Viber, Skype, iMessage, …) per poter comunicare con tutti i tuoi amici?

All’inizio di internet, usavamo dei protocolli di comunicazione che sono stati creati dai primi sviluppatori di internet, che credevano in una interoperabilità aperta e standardizzata, come per esempio IMAP, SMTP (e-mail), NNTP (newsgroup), HTTP (il web), IRC (chat), FTP (trasferimento di file). È proprio grazie alla natura aperta e decentralizzata di questi standard che continuiamo tutt’oggi ad utilizzarne quasi tutti.

Ciò non toglie che, anche se questi protocolli funzionano ancora bene, sono stati sviluppati per altri tempi: le funzionalità che sono state introdotte dalla messaggistica moderna (Whatsapp, Signal, ecc) come la possibilità di effettuare video-chiamate, la crittografia, la possibilità di inviare foto, video e audio-messaggi istantaneamente sono così utili oramai, che le diamo quasi per scontate.

Purtroppo, però, non sono disponibili con i protocolli antiquati e interoperabili, e i protocolli nuovi non ci permettono di comunicare come lo permettevano quelli vecchi. Tanto per fare un esempio: anche se io ho un account di email con GMail e tu ce l’hai con Yahoo, comunque possiamo continuare a mandarci delle email a vicenda. Ma se io ho un account Whatsapp, e tu ne hai uno su Telegram, non possiamo comunicare. E, anche se avessi le capacità tecniche per farlo, non potrei installare un server Telegram o Whatsapp, perché i proprietari di Whatsapp e di Telegram non solo non mi dicono come fare, ma anche non me lo permettono.

Per questo motivo è nata una iniziativa che si chiama matrix.org. Si tratta di un protocollo, di uno standard di messaggistica, aperto, come SMTP e IMAP per email, che però definisce come stabilire una comunicazione moderna, con tutte le funzionalità ormai a noi care (video-chiamate, telefonata, video-messaggi, audio-messaggi, messaggi di gruppo, ecc) che chiunque può usare. Tanto per curiosità, ecco una lista di gestori di server matrix.

Cosa significa? Significa che chiunque abbia le conoscenze tecniche è in grado di installare un server matrix e offrire servizi di messaggistica, nello stesso modo in cui chiunque abbia le capacità tecniche di installare un server di email, è in grado di farlo e offrire servizi di email. Se io ho un account su alternanet.fr e tu ne hai uno su feneas.org, possiamo comunicare!

Il formato di indirizzo matrix è un po’ diverso dagli altri che conosciamo, ma non è poi così difficile: @nome_utente:nomedelserver.com. Quindi, il mio indirizzo è @zgypa:matrix.org. Il che significa che il mio nome utente è zgypa, e il server che sto usando si chiama matrix.org.

Siccome crediamo in una interoperabilità aperta e standardizzata, non facciamo uso di sistemi non interoperabili. Per questo potrai trovarci sempre su sistemi interoperabili come telefono, SMS, email e Matrix, ma non su Telegram o Whatsapp.

AAO Board of Trustees Resolutions on Interoperablity

2022-05-06T00:00:00+00:00

La American Association of Orthodontics ha approvato la sua posizione e suggerimento sull’interoperabilità dei software ortodontici.

12-22 BOT – Interoperability Policy

Resolution #: 12-22 BOT Date:May 6, 2022 Resolution Status:In Process Resolution:

RESOLVED, that it be the position of the American Association of Orthodontists that the developers of orthodontic software should implement open and non-proprietary standards for data interoperability when available, and be it further

RESOLVED, that the American Association of Orthodontists supports the development of new open, non-proprietary data standards by stakeholders, and be it further

RESOLVED, that the American Association of Orthodontists assesses open and non-proprietary data interoperability plans in new programs and budgetary matters.

Background

Many limitations are encountered with existing EHRs and billing systems because information sent from one system cannot be understood by another. If standardized patient data could be imported and exported, analytical techniques could be used to analyze data efficiently. Then improvements in patient referrals and transfers, practice audits and timeliness of billing transactions would occur. Moreover, data repositories could be created with the aim of sparking innovations in treatment modalities, practice functionality, and overall patient health. At the present time, software vendors may create interfaces to transfer data, but such methods are expensive and prone to error.

Intent

Currently, orthodontic providers and patients do not have full control over the entire lifecycle of their orthodontic data. The intent of this effort is to provide a well-defined framework/infrastructure which the orthodontic software industry can use to build products that protect the privacy and ownership of the data, giving full control over the entire life cycle of orthodontic data. It is not the intent of this effort to allow free access to orthodontic data to anyone.

The intent of AAO’s intervention should be to help, ease, aid, and simplify the transition from the current state of mostly siloed non-interoperable orthodontic software by removing or smoothing the hurdles that currently prevent or slow down industry from doing this on their own.

The reason why the AAO needs to intervene in this effort (which could otherwise have been addressed by the industry) is that the orthodontic community has waited for solutions related to interoperability for two to three decades, and very little progress has occurred.

Our goal is to reach a point where orthodontists are able to pick freely between software products and plug them into their practices without major data conversion hurdles and costs. Additionally, we believe that doctors should be able to exchange protected orthodontic data between each other, among institutions and business partners, and across borders without technical barriers.

A developer should always make use of existing standards. If there are no standards, a developer is expected to invent a new standard. When a new standard is invented, it shall be made public, and eventually adopted by a Standards DevelopmentOrganization (SDO). Orthodontic software projects should only be awarded funds or prizes if their proposals include non-proprietary and standards-based data interoperability solutions (when applicable).

Inizia Gratis

2022-05-01T00:00:00+00:00

Avere il controllo dei dati dei tuoi pazienti non deve essere un segreto. Questa pagina spiega come fare per organizzare il tuo studio per rendere le immagini dei tuoi pazienti interoperabili. Si tratta di linee guida generali, che rappresentano il nostro approccio, ovvero come noi ci muoveremmo nel tuo studio, in caso decidessi di farti aiutare da noi. Ma non abbiamo il monopolio su questa procedura! Tu o qualsiasi altro amministratore di sistema o assistenza tecnica alla quale fai riferimento potrebbe essere in grado di eseguire la stessa procedura. Se hai delle domande, non esitare ad entrare in contatto con noi, e possiamo aiutare te, o il tuo amministratore per eseguire queste procedure.

Installa un PACS DICOM

È importante poter avere un posto dove poter tenere una copia dei dati dei tuoi pazienti in un formato che sia standardizzato e ben documentato. DICOM è senza dubbio il formato per immagini mediche più utilizzato, supportato e implementato che esista oggi giorno. Il PACS (Picture Archiving and Communication System) è un software che solitamente gira su un computer dedicato, oppure dentro una “macchina virtuale” dentro un server.

Trova il PACS che fa per te

Chiedi prima al tuo rivenditore. Esistono vari PACS in commercio. È possibile che l’azienda che ha prodotto il tuo dispositivo per acquisire immagini radiologiche (Cone Beam, panoramico, tele, scanner a fosfori, ecc.) abbia già uno a disposizione. In base ai rivenditori, ci potrebbe essere un prodotto vero e proprio a se stante, oppure certi potrebbero semplicemente avere un modulo DICOM da abilitare. Questa è sempre la soluzione ideale.

È possibile che, però, la spesa richiesta possa essere fuori dal tuo budget. Questo è comprensibile, perché tradizionalmente, i PACS venivamo usati prevalentemente soltanto in aziende mediche molto grandi, come ospedali. In questo caso, potrai valutare la possibilità di installare un PACS gratuito, open-source.

Il vantaggio di utilizzare un PACS open-source, è che non avrai costi di licenza.
Uno svantaggio è che dovrai scaricartelo, installartelo, configurartelo e mantenertelo tu, oppure il tuo amministratore di sistema (questo è un servizio che possiamo offrire anche noi).
Un altro svantaggio è che i programmi medici gratuiti open-source di solito non hanno certificazioni mediche, e pertanto, in certe giurisdizioni, è possibile che non ci si possa affidare per prendere delle decisioni cliniche.

Noi lavoriamo principalmente con un prodotto che si chiama Orthanc, ed in particolare, una distribuzione mantenuta da open-ortho che facilita la sua installazione e configurazione proprio per studi più piccoli, come quello odontoiatrico o ortodontico. Questa distribuzione è disponibile su Github e fa uso di Docker. Sebbene la distribuzione sia ancora in uno stato abbastanza giovane, il PACS di per sè, invece è molto stabile. E ortho-tank offre un buon punto di partenza.

Configura i tuoi dispositivi

Una volta che hai il PACS in piedi, devi lavorare con l’assistenza dei tuoi software di gestione e acquisizione di immagini mediche attuali per configurarli in modo tale che inviino al PACS ogni loro immagine acquisita. Questa procedura potrebbe richiedere aggiornamenti e/o costi aggiuntivi, e va coordinata con il tuo rivenditore.

A questo punto, potrai continuare a lavorare con i prodotti che stai utilizzando attualmente, e allo stesso tempo avrai anche un archivio di tutte le tue immagini in formato DICOM su un PACS di cui tu hai il pieno controllo.

Benvenuto nel mondo DICOM

Se sei arrivato qui, congratulazioni! Adesso potrai utilizzare qualsiasi software di visualizzazione o manipolazioni di immagini che supporta il formato DICOM. E ce ne sono sempre di più in commercio.

Una volta che ti trovi nel mondo dei dati interoperabili, potranno venire a galla vari problemi, che fino ad ora non avevi ancora preso in considerazione. Come per esempio, l’accertarsi di non trovarsi con lo stesso paziente inserito più volte con un numero di paziente diverso.

Perché Interoperabilità?

2021-09-10T00:00:00+00:00

Perché senza stiamo frenando il progresso e riducendo la qualità della cura del paziente. Nel post precedente abbiamo spiegato la differenza tra interoperabilità proprietaria, e quella non proprietaria. Ma perché preoccuparsi di interoperabilità non proprietaria?

L’importanza dell’interoperabilità non proprietaria

Per capire l’importanza dell’interoperabilità non proprietaria, dobbiamo dare uno sguardo al passato, e capire in che modo noi esseri umani, abbiamo fatto i più grossi salti di progresso evolutivo: siamo riusciti a farli soltanto dopo esserci concordati ed aver adottato uno linguaggio comune, uno standard.

La lingua scritta

Forse il primo e più importante salto siamo riusciti a farlo quando abbiamo cominciato, come esseri umani, a scrivere. Ma scrivere è facile: chiunque può inventarsi un modo di scrivere, che poi capisce solo lui o lei. La vera forza è stata quando abbiamo cominciato ad insegnare ai nostri alunni un linguaggio di scrittura comune, conosciuto a tutti.

A questo punto, le persone che hanno imparato qualcosa, hanno cominciato a scriverla, per non dimenticarsela, ma principalmente per fare in modo che i posteri potessero conoscere questo nuovo concetto e ridurre le probabilità di ripetere gli stessi errori. Da lì, sappiamo poi cosa è successo: abbiamo scritto libri, raccolto biblioteche, ed arricchito sempre di più quello che gli alunni possono studiare per prepararsi per il lavoro. Conseguentemente un essere umano che entra nella forza lavorativa oggi è a conoscenza di molte più nozioni di uno che entrava nell’ambiente lavorativo 200 anni fa.

Le unità di misura

I disagi dovuti a diverse unità di misura sono presenti ancora oggi: una volta, quasi ogni paese aveva unità di misura differenti, con nomi differenti. E quei paesi che utilizzavano lo stesso nome, utilizzavano però a volte diversi “punti di riferimento”, divergendo quindi dall’unità: pensiamo per esempio al gallone imperiale e quello statunitense. Si chiama comunque un gallone, ma quello imperiale è circa il 20% più voluminoso di quello statunitense. Questa situazione è stata ed è ancora fonte di confusioni. Le confusioni sono state spesso cause di vari incidenti. Per evitare il ripetersi di questi incidenti nuove misure di sicurezza sono state implementate. Per implementare nuove procedure di sicurezza, sono stati richiesti costi aggiuntivi. Questa catena di conseguenze sarebbe potuta essere stata evitata utilizzando soltanto ed esclusivamente la stessa unità per misurare il volume.

L’utilizzo del sistema internazionale di misura ha permesso un abbassamento notevole di costi e di errori sia nell’industria che nella ricerca scientifica, che con alte probabilità avrà inciso positivamente sul progresso umano.

I trasporti

Un altro esempio è quello del trasporto merci e passeggeri. Una volta non esistevano ne container, ne strade ferrate con scartamento ferroviario (distanza fra i binari) comune. Questo significa che ogni azienda ferroviaria (per paesi dove la ferrovia era privatizzata) o ogni paese (per i paesi dove la ferrovia era statale) avevano una distanza differente dei binari.

Questo si traduceva nel dover completamente scaricare a mano il treno ricaricarlo ad ogni frontiera. Se ogni paese aveva dei binari con distanze diverse, le carrozze e locomotive di un paese non potevano viaggiare sui binari di un altro paese. Per esempio quando un’azienda voleva trasportare dei beni dall’Italia al Portogallo su un treno, lo scarico e ri-carico dei treni era necessaria almeno tre volte: una volta sul confine Italia-Francia, uno sul confine Francia-Spagna e uno sul confine Spagna-Portogallo. I costi associate a queste procedure devono essere stati proibitivi.

Per poter realizzare la standardizzazione degli scartamenti, sicuramente ci sono stati dei costi iniziali notevoli da sostenere, perché è stato necessario mettere mano su varie reti ferroviarie esistenti. Inoltre saranno stati eliminati vari modelli di business, come per esempio quello dello scarico e ricarico dei treni ai confini. Però ha generato vari nuovi modelli di business, tra cui il boom dei trasporti internazionali, e lo sviluppo di uno standard per i container, e tutte le attività limitrofe all’industria dei container.

Lo standard cefalometrico

Ma senza andare tanto lontani, stiamo pure nel settore dell’ortodonzia: qua non parliamo di standard di analisi cefalometriche, bensì lo standard di come posizionare il paziente quando si fa una radiografia latero-laterale o postero-anteriore.

Quando le macchine radiologiche sono diventate sufficientemente economiche da poter essere utilizzata negli studi ortodontici, ogni ortodontista faceva i cefalogrammi come riteneva meglio. La distanza fra sorgente e paziente era sempre diversa, e così anche l’angolo. Conseguentemente, l’ingrandimento e la distorsione sulla pellicola erano sempre diversi, e non era possibile paragonare i cefalogrammi fatti da uno studio con quelli fatti da un’altro.

Con l’adozione dello standard di Bolton per acquisire i cefalogrammi, è stato finalmente possibile paragonare radiografie, e fare studi su numeri molto più elevati. È stato anche finalmente possibile condividere le analisi cefalometriche tra colleghi. Infatti gli angoli e le distanze misurati adesso hanno un significato molto simile quando misurate su radiografie acquisite da studi differenti. È per questo che, per esempio tu puoi utilizzare sulle tue radiografie l’analisi cefalometrica che Robert Ricketts ha sviluppato sulle sue radiografie.

Definizione di Interoperabilità

2021-09-03T00:00:00+00:00

Soltanto una interoperabilità utilizzando un protocollo di comunicazione standard, approvato dalla comunità medica, e aperto potrà essere realmente globale e sostenibile lungo termine.

Si intendono interoperabili due o più sistemi informatici che comunicano fra di loro in una maniera automatica, ovvero senza la necessità di un intervento dell’utente. Per esempio:

quando l’utente è costretto ad inserire l’anagrafica del paziente nel gestionale e anche nel programma per acquisire radiografie, i due software vengono considerati non-interoperabili;
quando l’utente non inserisce mai i dati del paziente (o altri dati) più di una singola volta, e questi si propagano anche su altri programmi o macchine mediche, odontoiatriche o ortodontiche, allora i software e i sistemi in questione vengono considerati interoperabili.

Interoperabilità basata su standard aperti

L’interoperabilità basata su standard aperti, e quindi non proprietaria, è quando due o più programmi vengono collegati assieme, utilizzando un linguaggio standardizzato e disponibile a chiunque. Quindi quando è sufficiente una semplice configurazione per fare parlare i vari programmi fra di loro.

La “non-proprietarietà” sta nel fatto che nessuno degli sviluppatori ha disegnato e sviluppato per conto proprio il linguaggio di comunicazione. Ha invece implementato un linguaggio standard e aperto. Per esempio quando la tua macchina fotografica salva una immagine nel formato “JPEG”, questo formato è un formato standardizzato internazionalmente da ISO, e chiunque può scrivere un programma per leggere e salvare file in questo formato, senza chiedere il permesso a nessuno.

Nel caso specifico dell’odontoiatria, un esempio di interoperabilità non-proprietaria potrebbe essere l’utilizzo dei programmi odontoiatrici del protocollo DICOM per tutte le immagini (fotografie, scansioni endorali, radiografie, ecc.) e di quello HL7 FHIR per tutto il resto dei dati clinici.

È importante chiarire che seppure il linguaggio di comunicazione è “aperto”, i dati non lo sono! I dati di per se, vengono sempre protetti dai permessi del software che li gestisce. Infatti, anche se la tua macchina fotografica salva le foto in un formato aperto come il JPEG, questo non significa che tutti quanti ora hanno accesso alle foto che la tua macchina fotografica ha prodotto.

Problemi

L’implementazione di uno standard richiede l’apprendimento dello standard che viene implementato. Questo potrebbe significare in certi casi un leggero rallentamento nello sviluppo, che però dovrebbe ridursi con il passare del tempo.
Gli sviluppatori a volte introducono implementazioni parziali o non perfettamente conformi allo standard. Queste imperfezioni possono risultare nel dover fare delle correzioni sul campo, fino a quando lo sviluppatore non risolve il problema.

Interoperabilità Proprietaria

L’interoperabilità proprietaria è quando due o più programmi vengono collegati assieme, utilizzando dei sistemi che sono specifici a quei programmi. In questo scenario, è necessario sviluppare un nuovo collegamento per ogni tipo di programma. Il termine proprietario viene usato per indicare che è proprietario ad ogni specifico programma/software. In altre parole, sono gli sviluppatori di software che gestiscono come avviene questo tipo di interoperabilità. Esempio:

Hai un gestionale, e vorresti farlo comunicare con un gestore di SMS per inviare in automatico gli avvisi SMS ai pazienti, ricordandogli del loro appuntamento.
Ingaggi un tecnico che mette in piedi questo collegamento.
Il tecnico si informa, e trova la documentazione nei manuali del gestionale su come estrarre i dati del pazienti, e sul sito del gestore SMS su come inviare gli SMS.
Poi scrive un programma che prende i dati dal gestionale e li usa per inviare gli SMS.

Problemi

Quando gli sviluppatori di un software fanno qualche cambiamento, è probabile che il collegamento si rompa.
Quando vuoi collegare il gestionale ad un altro programma, come per esempio uno per la firma grafometrica o online, dovrai ingaggiare lo sviluppatore/tecnico per fare di nuovo un programma nuovo per collegare i due sistemi.
La programmazione e il mantenimento diventano costosi.
Per lo sviluppatore di software, è più costoso implementare questo tipo di interoperabilità, perché deve venire disegnata e sviluppata da zero.