Rapporto sui risultati

would be: - XCF, - Delayed Document Assembly. Improve the requirement for a more sustainable solution. Avoid to limit the freedom of the implementation and standardize the relevant aspect of the interfaces.

1.4.4: Riguardo all’AuditMessage/ActiveParticipant, Integic consiglia d’introdurre come 1.1 mandatory Element non solo l’UserID, ma anche un nome leggibile della persona attiva in modo da proporre una verbalizzazione comprensibile per il paziente. HIN rileva che il GLN al numero 1.4.4.1.1 deve essere definito come obbligatorio, mentre nell’ordinanza (articolo 24 OCIP) la trasmissione è facoltativa (può). Sembra essere una contraddizione. Vi sono dei casi nei quali il GLN non è ancora definito. Si propone di mettere ovunque un obbligo, un «MUST» per i GLN. Ne consegue che gli ambulatori devono disporre di un GLN prima di poter aderire a una comunità. Posta e IG eHealth scrivono riguardo al numero 1.4.4.1: Why should the implementer be forced to persist an audit event in any particular format? A canonical format is only relevant for audit message exchange across communities. As long as the implementer can generate and populate the exchange format he should be free to store the data in whatever format deemed most practical. Proposta: Remove MUST requirement to store audit event data in a pre-defined format. Sul numero 1.4.4.1.1 osservano: Which time zone is used in a timestamps string representation is completely irrelevant as long as the time zone is included in the string representation so downstream processes interpret it correctly. Proposta: remove the Swiss national extension.

1.5 Requirements on PIXv3 for Patient Identity Feed

Posta e IG eHealth scrivono riguardo a OtherIDs: From the documents of EPDV storing the electronic patient dossier-NIP in the MPI is a MUST requirement. Why is it a MAY requirement here? Correct the requirement.

1.7 Requirements on PDQv3 Profile for Patient Demographics Query

Riguardo al numero 1.7.2.1.1, Posta e IG eHealth richiedono un chiarimento: If there are more than 5 matches zero matches a special handling like in the XCPD transaction (see IHE ITI TF-2b, chapter 3.55.4.2.2.6) is necessary. Clarify this statement.

1.8 Requirements on XCPD Profile for Cross-Community Patient Discovery

Posta e IG eHealth illustrano un caso nel loro parere e domandano come debba essere risolto. Chiedono inoltre quanto segue: An example for patient matching across communities should be provided. Sul numero 1.8.2 commentano: As the header is a suggestion by the initiating gateway to the responding gateway, i.e. the responding gateway may do whatever, why is there a hard limit of the value that can be recommended? To restrict a non-binding value seems pointless. Remove «This values MUST NOT exceed 3 days».

1.9 Requirements on HPD Profile for Replication

HIN ribadisce il parere espresso sul numero 1.4.4.1.1 anche per i numeri 1.9.5.1.1 e 1.9.5.1.2.

Allegato 5c

1 Introduction

KSSG chiede riguardo all’impiego di XDS-I, se il DICOM WADO Service rientri nella certificazione. Questo farebbe parte dei sistemi primari se nel XDS Repository si registra solo il KOF. Chiede inoltre se i portali per i pazienti debbano supportare un apposito DICOM Viewer, che sappia gestire WA-DO (Akteur Imaging Document Consumer), e se ciò è rilevante per la certificazione. Tutto il settore XDS-I per lo scambio di file con immagini non è stata considerato nelle CTO ed è quindi opportuno verificare l’OCIP e le CTO secondo il requisito di IHE XDS-I. Posta e IG eHealth scrivono in riferimento al brano di frase