...

• DROS (anvenderguide) anvendes til skrive aktiviteterne:
  • Oprettelse af nye dokumenter (ITI-41 Provide and Register Document Set) sker fra anvendersystemerne. DROS lagrer det oprettede dokument i det bagvedliggende nationale XDS Repository. I forbindelse med oprettelsen sørger det nationale XDS Repository for at få indexeret dokumentet og dets metadata i det nationale XDS Registry (ITI-42 Register Document Set).
  • Oprettelse af et dokument, som en opdatering til et eksisterende dokument (ITI-41 Provide and Register Document Set). Her ugyldiggøres det eksisterende/gamle dokument.
  • Ugyldiggøre (deprecate)  et dokument eller opdatering af et dokument (ITI-57: Update Document Set)
  • Registrering af On-Demand dokumenter (ITI-61 Register On-Demand Document Entry)
  • Registrering af Stable dokumenter (ITI-42 Register Document Set). Dette anvendes, hvis man selv ejer et repository, men anvender det nationale registry til indeksering. Et eksempel på dette er KIH databasen, som indeholder hjemmemålinger (PHMR) og spørgeskemaer (QRD) .
• DokumentDelingsServicen (DDS registry) (anvenderguide) anvendes til fremsøgning af dokumenter (ITI-18 Registry Stored Query)  hvor der blandt andet kigges i
  • det Nationale XDS Registry
  • Svareksponeringsservice XDS Registry Adapter. Der delegerer søgninger videre til Svareksponeringsservicen efter laboratoriesvar
• DokumentDelingsServicen (DDS repository) (anvenderguide) anvendes til at hente dokumenter (ITI-43 Retrieve Document Set) fra repositories som
  • det Nationale XDS Repository
  • Svareksponeringsservice XDS Repository Adapter. Der delegerer hentning af laboratoriesvar videre til Svareksponeringsservicen
  • KIH databasen
  • Graviditetsmappe On-Demand repository
• Søgning af Fælles StamKort (SFSK) (anvenderguide) er til at fremsøge (ITI-18 Registry Stored Query) og hente (ITI-43 Retrieve Document Set) Fælles Stamkort vha system idkort . Dette er on-demand dokumenter, som skabes ud fra en række bagvedliggende stamdata services.
• Læse servicene i DDS registry/ DDS repository gør repository gør brug at hjælpe komponenterne SamtykkeService, BehandlerRelationsService , SamtykkeService og MinLog2 for at sikre borgerens rettigheder. Se evt. DDS DDS anvenderguide for mere beskrivelse.
• Læse servicene i SFSK gør brug at hjælpe komponenterne BehandlerRelationsService og MinLog2 for at sikre borgerens rettigheder.

...

Ovenstående  infrastruktur findes i flere versioner/miljøer. Eksempelvis findes miljøerne test1, test2, prodtest og produktion. Og f.eks. findes DROS i versionerne "Aftaler" , og "Graviditetsmappe" og "Planer og aftaler".

Hvordan kommer man i gang

Komponenterne i dokumentdelings infrastrukturen kommunikerer med ITI kald, som er standardiserede SOAP services, der skal overholde IHE XDS specifikationen - i det såkaldte XML basererede "RIM format"

Det er op til anvenderen/udvikleren selv at vælge platform og frameworks, der passer til resten af dennes løsning. Fra et udvikler perspektiv kan man enten vælge selv at generere stubkode ud fra de standardiserede WSDL filer eller at anvende et tredjepartsprodukt. Nedenfor gives et forslag til, hvordan det kan gribes an med tredjepartsproduktet IPF Open eHealth Integration Platform, som forudsætter man arbejder på en java platform. Andre platforme kan have tilsvarende værktøjer og muligheder.

...

Man kan med fordel inkludere biblioteket IPF Commons IHE XDS i sin kodebase. Her findes både stubbe og en masse anvendelige utilities. Disse kan blandt andet mappe fra den IHE XDS standard specificerede RIM format, til en en "OpeneHealth core model", som er java klasser. Og gør det at udvikle ITI kald lettere at arbejde med.

Helt overordnet kan det at lave et ITI kald deles op i følgende trin

...

Når man opretter et documentEntry, skal der sættes et entryUuid på. Dette id er vigtigt, da det anvendes i forbindelse med senere ret og ugyldiggørelse af dokumentet. Det skal have prefix "urn:uuid:" for at være et entryUuid, ellers vil det blive opfattet som et symbolsk id, og den kaldte komponent vil selv tildele et gyldigt entryUuid.

Når documentEntry udfyldes med metadata, skal man huske de førnævnte CDA standarder.  Er der tale om et stable dokument, kan man overveje, om ikke man med fordel kan hente meget af metadata informationen fra dokumentet selv (fra headeren), ved at deserialisere det.

I forbindelse med, at oprettelse af associationer, skal der angives en source og target entryuuid, udover associationens egen entryUuid. Her gælder

• For opret af dokumenter: source er submissionSet entryUuid og target er documentEntry entryUuid
• For ret; som for opret. Den ekstra "replace" association:  source er nye dokumentEntry entryUuid og target det gamle dokumentEntry entryUuid
• For ugyldiggørelse:  source er submissionSet entryUuid, og target er documentEntry entryUuid for det dokument, som skal ugyldiggøres

...

// Nyt kald/request 
ProvideAndRegisterDocumentSet provideAndRegisterDocumentSet = new ProvideAndRegisterDocumentSet();

// Opret documentEntry
DocumentEntry documentEntry = new DocumentEntry();
AssigningAuthority patientIdAssigningAuthority = new AssigningAuthority("1.2.208.176.1.2"); // OID for CPR registret
Identifiable patientIdentifiable = patientIdentifiable = new Identifiable("2512489996", patientIdAssigningAuthority);
documentEntry.setPatientId(patientIdentifiable);
... mere metadata, se CDA profilen

// Tilføj dokumentet til request
provideAndRegisterDocumentSet.getDocuments().add(new Document(documentEntry, new DataHandler(new ByteArrayDataSource(documentPayload.getBytes(), documentEntry.getMimeType()))));

// Opret SubmissionSet
provideAndRegisterDocumentSet.setSubmissionSet(createSubmissionSet(documentEntry.getPatientId(), contentTypeCode, submissionTime));

// Opret association mellem SubmissionSet og DocumentEntry
provideAndRegisterDocumentSet.getAssociations().add(createAssociation(submissionSet, documentEntry));

// Transformer request - dette laver core model om til RIM format
ProvideAndRegisterDocumentSetTransformer registerDocumentSetTransformer = new ProvideAndRegisterDocumentSetTransformer(ebXMLFactory);
EbXMLProvideAndRegisterDocumentSetRequest30 ebxmlRequest = (EbXMLProvideAndRegisterDocumentSetRequest30) registerDocumentSetTransformer.toEbXML(provideAndRegisterDocumentSet);
ProvideAndRegisterDocumentSetRequestType provideAndRegisterDocumentSetRequestType = ebxmlRequest.getInternal();

// Udfør kald
RegistryResponseType registryResponse = iti41PortType.documentRepositoryProvideAndRegisterDocumentSetB(provideAndRegisterDocumentSetRequestType);

// Transformer response - dette laver RIM format til core model
ResponseTransformer responseTransformer = new ResponseTransformer(ebXMLFactory);
Response response = responseTransformer.fromEbXML(new EbXMLRegistryResponse30(registryResponse));

// Aflæs kaldets svar
if (response.getStatus().equals(Status.SUCCESS)) {
	// Kaldet gik godt
} else
if (response.getStatus().equals(Status.PARTIAL_SUCCESS) || response.getStatus().equals(Status.FAILURE)) {
	// Der er warning eller fejl i kaldet, håndter dem
	for (ErrorInfo error : response.getErrors()) {
	}
}

(Det er flere detaljer omkring ITI-41 eksempelkode i anvender guiden til DROS.)

Et tilsvarende eksempel for ITI-18 fremsøgning kunne se således ud:

// Nyt kald/request 
FindDocumentsQuery findDocumentsQuery = new FindDocumentsQuery();

// Opret søge kriterier
AssigningAuthority patientIdAssigningAuthority = new AssigningAuthority("1.2.208.176.1.2"); // OID for CPR registret
Identifiable patientIdentifiable = patientIdentifiable = new Identifiable("2512489996", patientIdAssigningAuthority);
findDocumentsQuery.setPatientId(patientIdentifiable); // angiv patienten dokumenterne vedrører

List<AvailabilityStatus> searchStatusList = new LinkedList<AvailabilityStatus>();
searchStatusList.add(AvailabilityStatus.APPROVED);
findDocumentsQuery.setStatus(searchStatusList); // søg efter dokumenter, som har status approved

findDocumentsQuery.getServiceStartTime().setFrom(serviceStartTimeFrom); // søg efter specifik dato interval som start tidspunkt
findDocumentsQuery.getServiceStartTime().setTo(serviceStartTimeTo);     // ved at angive fra og til serviceStartTime

QueryRegistry queryRegistry = new QueryRegistry(findDocumentsQuery);
queryRegistry.setReturnType(QueryReturnType.LEAF_CLASS); //returner fuld metadata for de fremsøgte dokumenter

// Transformer request - dette laver core model om til RIM format
QueryRegistryTransformer requestTransformer = new QueryRegistryTransformer();
EbXMLAdhocQueryRequest30 ebxmlRequest = (EbXMLAdhocQueryRequest30) requestTransformer.toEbXML(queryRegistry);
AdhocQueryRequest adhocQueryRequest = ebxmlRequest.getInternal();

// Udfør kald
AdhocQueryResponse adhocQueryResponse = iti18PortType.documentRegistryRegistryStoredQuery(adhocQueryRequest);

// Transformer response - dette laver RIM format til core model
QueryResponseTransformer responseTransformer = new QueryResponseTransformer(ebXMLFactory);
EbXMLQueryResponse ebXML = new EbXMLQueryResponse30(adhocQueryResponse);
QueryResponse queryResponse = responseTransformer.fromEbXML(ebXML);

// Aflæs kaldets svar
if (queryResponse.getStatus().equals(Status.SUCCESS)) {
 	// Kaldet gik godt, håndter de fremsøgte dokumenter metadata
	for (DocumentEntry documentEntry : queryResponse.getDocumentEntries()) {
	} 
} else
if (queryResponse.getStatus().equals(Status.PARTIAL_SUCCESS) || queryResponse.getStatus().equals(Status.FAILURE)) {
	// Der er warning eller fejl i kaldet, håndter dem
	for (ErrorInfo error : queryResponse.getErrors()) {
	}
}

Nærlæser man ovenstående kodeeksempler, kan man genkende ovenstående transformeringsfigurs kasser i kodelinierne. Eksempelvis for ITI-41 kaldet, hvor line 1-18 svarer til boks 2 (core model), linie 20-23 til boks 2 og 3  (core model og RIM format), linie 26 til kaldet mellem boks 3 (RIM format) og NSP komponenten, linie 28-30 til boks 3 og 2 (RIM format og core model) samt linie 32-40 til boks 2 (core model)

Savnes inspiration til kodeeksempler, er også integrationstestene til f.eks. DROS og NXRG et godt sted at kigge.

...

Dette betyder, at der vil være et separat endpoint pr dokumenttype, som anvenderne skal anvende, når dokumenter registreres (og opdateres). Der vil til gengæld fortsat kun være behov for ét endpoint til dokumentdelingsservicen, når man skal fremsøge dokumenter.

Krav til eksterne registries og repositories

Dokumentdelingsservicen anvendes til at fremsøge og hente dokumenter på NSP. Det sker ved, at servicen har en række registries og repositories konfigureret, den kalder med ITI-18 Registry Stored Query henholdsvis ITI-43 Retrieve Document Set. For at sikre godt samarbejde/ fejlhåndtering mellem dokumentdelingsservice og disse registries/ repositories, er der opstillet en række punkter, der skal overholdes, hvis man som registry/ repository ønsker at være en del af NSP's dokumentdeling. Disse findes her: registry og repository.

Hjælpeværktøjer og links

De følgende links kan alle bidrage til at lette arbejdet med at implementere dokumentdeling.

...