Elementi da analizzare

Questa pagina elenca i temi e gli elementi sottoposti (o da sottoporre) all'analisi del Gruppo di Progetto; incluso correzioni e commenti inviati e soluzioni condivise.

Gli Elementi discussi e risolti sono descritti nella Seguente Pagina

Gli elementi sono organanizzati per Temi e per Sezioni : gli elementi potrebbero essere ripetuti o no nelle diverse parti.

Ultimo aggiornamento: — G.Cangioli 2014/09/10 14:17

……

Order Set è stato tradotto come Insiemi di Ordini. (vedi CP.4.1)

Nel file allegato la lista dei criteri in cui viene usato questo termine traduzioniglossario.docx

Riunione 10 settembre: nessuna indicazione, per ora lasciata la traduzione originale. da rivalutare.

Nel file allegato la lista dei criteri in cui viene usato questo termine traduzioniglossario.docx

Nel file allegato la lista dei criteri in cui viene usato questo termine traduzioniglossario.docx

Nel file allegato la lista dei criteri in cui viene usato questo termine traduzioniglossario.docx

Il termine Patient è tradotto in maniera diversa (come paziente o come assistito) in funzioni criteri differenti.

Chiarire se e come uniformare le dizioni e se c'è qualche differenza che si vuole evidenziare nell'uso di questi termini diversi.

La condizione di dipendenza espressa nel modello attraverso la frase standard “according to organizational policy, and/or jurisdictional law.” è tipicamente fatta con la forma canonica “in accordo con il campo di applicazione, le politiche dell’organizzazione e/o le norme della giurisdizione”

Nel profilo si trovano tuttavia altre traduzioni come per esempio “con la normativa nazionale e le politiche dell'organizzazione” alcune volte alle regioni altre volte alle norme della giurisdizione…. oppure (TI.1.1) “in accordo con le politiche condivise definite tra Regioni/Province Autonome.” od altre.

Questa disuniformità si registra anche all'interno della stessa classe di funzioni.

Approfondire se è necesassario uniformare le dizioni, con quali criteri e utilizzando quali traduzioni.

Nel profilo originario tutti i criteri associati a funzioni di tipo OPT, erano stati messi come OPT.

Questo implica la creazione di contraddittori criteri di tipo Optional Shall (Vedi analisi)

Aggiungere Descrizione nelle Clausule di Conformità del profilo su come devono essere intepretate le gerarchie di priorità.

To Do: verificare l'applicazione di tale metodologia nel profilo

Ipotesi di Lavoro: le priorità/milestones di un criterio deve essere interpretato in congiunzione con la priorità/milestone della funzione padre. Esempio di interpretazione delle priorità di una funzione di tipo OPT:

• EN = non ammesso
• EF/“Realizzazione Funzione” = Essenziale nel momento in cui la funzione è realizzata. (equivale ad un EN)
• EF/milestone_x = Essenziale Futuro con la milestone_x indicata, qualora la funzione sia realizzata
• OPT = Opzionale

Alcuni criteri di tipo SHALL erano classficati di priorità OPT nel profilo. Questa sembra essere una condizione contraddittoria.

In questi casi la priorità OPT è stat trasformata in EF, mantenendo la milestone indicata in OPT.

Il profilo originario includeva una serie di criteri di tipo SHALL con priorità “Opzionale”. in questi casi è stato deciso di trasformare gli OPT in EF, lasciando come milestone “in base alle politiche ……”

da redigere

I materiali usati durante le riunioni di Luglio, Agosto e Settembre e le conclusioni concordate sono diposnibili nelle pagine dedicate alle riunioni

• 4383: “erogatore OD operatore della vaccinazione rifiutata” (era “che”, in maiuscolo la parola variata). Più che di rifiuto comunque a me pare si parli di operatore della vaccinazione non erogata (sopra si parla anche di “controindicata”, non solo di “rifiutata”)

4323: propongo “Il sistema DOVREBBE offrire la possibilità di acquisire allergie come testo libero” (tolto un “le” davanti “allergie”)

• 4343: Vedi Analisi su render

• 3372: uniformerei la traduzione del “capture, store…” a quella di 3371
• 4308: viewable per me dovrebbe essere visionabile o visualizzabile, non “visibile” (cfr “ E' visibile l'intera storia delle allergie, incluse le reazioni, per ogni allergene.”). Inoltre “Le informazioni sulle allergie che dovrebbero essere acquisite POSSONO variare in base al campo di applicazione,” (ora dice “può”). Anche “Per esempio i requisiti di documentazione che riguardano una reazione allergica ad una sostanza farmacologica soggetta a reportistica obbligatoria POSSONO richiedere un livello maggiore di dettaglio dei dati acquisiti.” (ora è “può”) (metto in maiuscolo le parole modificate)
• 4313: l'originale dice “food”, non farmaci
• 4335: l'originale dice “manage”, non mostrare. Non ero nel GdL e visto l'uso mi pare una variazione ragionevole.
• 4336: dell'originale manca il “prescriber”, è volontario? (No, Aggiunto)
• 4379: “ Le liste delle vaccinazioni sono gestite nel tempo, sia nel corso di una visita o di una degenza, SIA nel periodo di vita di un paziente.” (era “o”) (in maiuscolo la parola variata)

Rimossa la funzione CPS 1.4 dalla versione post 19 agosto, perché la gestione delle richieste di soculto non è propria di questa versione del FSE. La traduzione di referral (request) con referti, su cui si basava la precendete scelta, non è pertinente.

• 4625: d'accordo con la nota
• 4628: pensando al “sistema di sistemi”, si tratta di una funzione propria dell'interazione fra sistemi anagrafici e sistemi alimentanti, non solo di record duplicati (e.g. paziente in PS che viene riconosciuto e/o accorpato a paziente con FSE aperto all'alimentazione dopo che per lui sono già stati prodotti referti)
• 4635: d'accordo, il criterio è stato significativamente variato nella sostanza
• 4634: credo si sia voluto inserire un requisito relativo ai cambi di identita' per motivi legali, effettivamente e' molto diverso dall'originale
• 4636-4637: in effetti qui c'e' una difficolta' a catturare da una parte il “sistema di sistemi”, dall'altra il “sistema” singolo FSE - in 4637 c'e' quello che serve ai sistemi per far funzionare l'FSE, in 4636 c'e' il sistema singolo FSE come definito dalla normativa. Non mi sembra un problema di facile soluzione. Vale anche per i successivi marcati nella stessa maniera
• tradotto con registrazioni, ma non saprei suggerire di meglio, per cui va bene cosi') 4653, 54, 55: propenderei per togliere. L'unica domanda e' se i criteri sotto (4654, 4655) sono coperti altrove, perche' quelli (scritti cosi') servono…

• 4629, 4631,4632, 4639. 4641 ed altri criteri : Vedi Analisi su render

• 4644: should secondo me
• 4646: deve mi pare ragionevole per la mia esperienza
• 4648: deve, per normativa italiana (almeno credo)
• 4621: “oltre A INCLUDERE” (era ilnculde, evidente errore di digitazione)
• 4630: “con il corretto assistito E marcarle” (era “ed”)
• 4633: a me sembra sia OK; da cambiare “poterli” →poterlo e “rimuoverli”
• 4675: “ Deve essere registrato ogni contatto del paziente con una struttura sanitaria e DEVONO ESSERE gestite le informazioni” (manca).

da redigere

Nota A. Cabroni (27/10/2014):

Per quanto riguarda la traduzione di “The system MAY capture the data, document or other identifier for archived Record Entry content” (e simili) io non cambierei di molto quanto proposto, mettendo semplicemente qualcosa di un po' più leggibile come ad esempio:

Il sistema PUO' acquisire i dati (o il documento o un altro identificativo) associati ad un elemento di un record de-identificato (archiviato/recuperato/distrutto).

Ho dei dubbi sulla traduzione di merge con uniti e unmerged con separati: forse nella traduzione si perde qualcosa della possibile corretta interpretazione.

da redigere