Page History

...

• 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). Tidligere har også DRS været anvendt til dette formål, men den udgår.
  • Oprettelse af et dokument, som en opdatering til et eksisterende dokument (ITI-41 Provide and Register Document Set).
  • Sletning (deprecate) af  et dokument  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.
• DokumentDelings Servicen (DDS registry) (anvenderguide) anvendes til fremsøgning af dokumenter (ITI-18 Registry Stored Query)  hvor der kigges i
  • det Nationale XDS Registry
  • aftale adaptorer til region Nord og Region Midt. Disse delegere søgninger videre til de to Bookplan instanser i Region Nord hhv. Region Midt
  • FSK registry (vha bruger idkort)
• DokumentDelingsServicen (DDS repository) (anvenderguide) anvendes til at hente dokumenter (ITI-43 Retrieve Document Set) fra
  • det Nationale XDS Repository
  • aftale adaptorer til Region Nord og Midt, som henter Bookplan dokumenter i Region Nord hhv. Region Midt
  • FSK (vha bruger idkort)
• 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 og SFSK gør brug at hjælpe komponenterne BehandlerRelationsService, MinSpærring og MinLog2 for at sikre borgerens rettigheder.

...

Og her tilsvarende RIM format, som openeHealth oversætter det til, og som anvendes ved ITI kaldet:

...

(Simplificert Simplificeret figur efter figur 4.1-1 i ITI TF-3. Da man på NSP ikke arbejder med folders er disse elementer udeladt)

...

• FindDocuments: Den traditionelle måde, hvor man opsætter en række søgekriterier som dato interval, dokument status, dokument type mm.
• FindDocuemensByReferenceFindDocumentsByReference: her søge efter dokumentreferencer, man måtte have sat på da dokumentet blev oprettet kombineret med andre almindelige søgekriterier
• GetDocuments: her fremsøges dokumenterne efter entryuuid eller uniqueid

...

TODO: Afklaring omkring der skal gøres noget at det bliver som "kunne være". Der gælder 2 ting:

• DDS'en tillader ikke FindDocuemensByReferenceFindDocumentsByReference. Den findes i NXRG.
• DDS'en ser ikke ud til at tillade ObjectRef. Og hvordan skal den kunne håndtere spæringer spærringer på den baggrund? Er det nødvendigt at spære spærre for ID'er? ObjectRef findes i NXRG.

...

// 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åede kodeekspemplerovenstående kodeeksempler, kan man genkende ovenstående transformeringsfigurs kasser i kodelinierne. Eksempelvis for ITI-41 kaldet, hvor  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)

...