1. Introduktion
1.1. Formål
Dette dokument er en vejledning til anvendelse af den Dokument Registrerings- og Opdateringsservice (DROS). På baggrund af dokumentet er det muligt at lave en teknisk implementation af de brugerhistorier der er beskrevet i DROS - Brugerhistorier.
Formålet med dette dokument er at vejlede udviklere, der skal udvikle eller vedligeholde systemer, som anvender DROS snitflader.
1.2. Læsevejledning
Dette dokument er rettet mod udviklere, der skal udvikle eller teste services, der har grænseflader mod DROS.
Læseren forudsættes at være bekendt med de involverede teknologier, som f.eks. SOAP og DGWS. Derudover forudsættes, at læseren er bekendt med IHE XDS (herunder ITI-XX services).
1.3. Referencer
| Term | Beskrivelse | Evt reference |
|---|---|---|
| DGWS | Den Gode Webservice | |
| IHE XDS | Cross Enterprise Document Sharing (IHE) | Cross-Enterprise Document Sharing |
2. Introduktion til DROS
DROS er en service på NSP, der udstiller snitflader til registering og opdatering af dokumenter og metadata i den nationale XDS infrastruktur.
De enkelte brugerhistorier er beskrevet i dokumentet DROS - Brugerhistorier og giver et overblik over DROS set fra anvendersystemerne.
I dette dokument er der en oversigt over snitfladebeskrivelser for DROS.
Efterfølgende gennemgås de brugerhistorier, der er beskrevet i DROS - Brugerhistorier og der gives en oversigt over, hvordan de enkelte brugerhistorier kan realiseres: Dvs. hvilke snitflader i DROS er i spil samt eksempler på requests og responses.
3. Snitfladebeskrivelser og endpoints
DROS udstiller en række services til registrering og opdatering af dokumenter og disses metadata. DROS snitfladerne tager udgangspunkt i de standardsnitflader, der er beskrevet som en del af IHE XDS.
Hver af DROS services udstiller 2 WSDL filer.
- En standard ITI WSDL: Denne WSDL beskriver den standardiserede snitflade som er defineret som en del af IHE XDS stanadarden
- En DGWS WSDL: Denne WSDL er tilpasset således, at kravene i forhold til DGWS fremgår af WSDL filen
| Servicenavn | Service URL | Standard WSDL | DGWS WSDL |
|---|---|---|---|
| ITI-41: Provide And Registre Documentset | http://<NSP miljø>/dros/iti41 | http://<NSP miljø>/dros/iti41?wsdl | http://<NSP miljø>/dros/dgws-wsdl/iti41.wsdl |
| ITI-42: Register Document Set | http://<NSP miljø>/dros/iti42 | http://<NSP miljø>/dros/iti42?wsdl | http://<NSP miljø>/dros/dgws-wsdl/iti42.wsdl |
ITI-42: Register Document Set (ingen DGWS 1 ) | http://<NSP miljø>/dros/iti42noDgws | http://<NSP miljø>/dros/iti42noDgws?wsdl | N/A |
| ITI-57: Update Document Set | http://<NSP miljø>/dros/iti57 | http://<NSP miljø>/dros/iti57?wsdl | http://<NSP miljø>/dros/dgws-wsdl/iti57.wsdl |
| ITI-61: Register On-Demand Document Entry | http://<NSP miljø>/dros/iti61 | http://<NSP miljø>/dros/iti61?wsdl | http://<NSP miljø>/dros/dgws-wsdl/iti61.wsdl |
4. Understøttelse af udvikling for anvendere
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 udfra de standardiserede WSDL filer eller at anvende et tredjepartsprodukt. Her 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. Man kan med fordel inkludere biblioteket IPF Commons IHE XDS i sin kodebase. Her findes både stubbe og en masse anvendelige utilities. Andre platforme kan have tilsvarende værktøjer og muligheder.
Eksempelkoden stammer oprindeligt (er tilrettet for simplificering) fra DROS integrationstest og kan findes her: https://svn.nspop.dk/src/components/dros/trunk/
ITI snitfladerne kaldes som SOAP web services, og er i det såkaldte XML basererede "RIM format", der er specificeret af IHE XDS standarden. Open eHealth frameworket kan blandt andet mappe fra RIM formatet 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
- Opret kald i OpeneHealth core model
- For iti41 kald indebærer det blandt andet opret/indlæs af dokument samt opret af metadata til documententry
- For iti42, 57 og 61 indebærer det oprettelse af metadata
- Udfør kald - det transformeres til RIM format på vej ud, og tilbage til core model ved returnering vha. openeHealth frameworket
- Aflæs kaldets svar og håndter eventuelle fejl returneret
Dette kan illustreres ved følgende tranformeringsdiagram, hvor man ser core modellen blive transformateret til RIM formatet, og efterfølgende et ITI kald udført. Resultatet af ITI kaldet kommer tilbage i RIM format, og transformeres til core modellen:
Et eksempel på, hvordan forskellen mellem core model og RIM format kommer til udtryk, ses her for håndtering af confidentiality code og CPR nummer i forbindelse med oprettelse af et dokument.
Først OpeneHealth core model, den kode man skriver i sit program:
documentEntry.getConfidentialityCodes().add(new Code("N", new LocalizedString("N"), "2.16.840.1.113883.5.25"));
AssigningAuthority patientIdAssigningAuthority = new AssigningAuthority("1.2.208.176.1.2");
Code patientCode = new Code("2512489996", new LocalizedString("CPR"), "1.2.208.176.1.2");
documentEntry.setPatientId(new Identifiable(patientCode, patientIdAssigningAuthority));
Og her tilsvarende RIM format, som openeHealth oversætter det til:
<ns2:Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2" nodeRepresentation="N" id="urn:uuid:9068bc2b-1717-4337-abfb-027f303b20c6">
<ns2:Slot name="codingScheme">
<ns2:ValueList>
<ns2:Value>2.16.840.1.113883.5.25</ns2:Value>
</ns2:ValueList>
</ns2:Slot>
<ns2:Name>
<ns2:LocalizedString xml:lang="en-US" charset="UTF-8" value="N"/>
</ns2:Name>
</ns2:Classification>
<ns2:ExternalIdentifier registryObject="urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="2512489996^^^&1.2.208.176.1.2&ISO" id="urn:uuid:6dc240d8-d871-4df1-b8c6-3414f1415022">
<ns2:Name>
<ns2:LocalizedString value="XDSDocumentEntry.patientId"/>
</ns2:Name>
</ns2:ExternalIdentifier>
I afsnittene nedenfor, som omhandler understøttelse af bruger historierne "opret stable dokument", "ret stable dokument" og "slet dokument" er der vist pseudocode, som illustrerer, hvordan man kan implementere kaldene vha. ovennævnte metode. Afsnittene hænger sådan sammen, at for den givne brugerhistorie kan man se koden (OpeneHealth core model), som skaber kaldet, og hvilke request og response (rim format) det medfører. Som skrevet er der tale om pseudocode, for at illustrere principperne, og ikke fuldt implementeret logik, som kan kopieres, som det er.
5. Understøttelse af Brugerhistorier
Med udgangspunkt i brugerhistorierne i DROS - Brugerhistorier beskrives i det følgende, hvorledes de enkelte snitflader skal anvendes til at understøtte disse.
Alle brugerhistorier indeholder eksempler på succesfulde requests og responses.
Derudover skal den anvendende organisation være whitelistet til kald til DROS. Dette gøres ved at oprette en supportsag via https://www.nspop.dk/category/sup - husk at vedhæfte den offentlige del af det certifikat, der skal anvendes eller angiv CVR eller certifkatets uuid i sagen.
Der kan være flere instanser af DROS kørende. Er dette tilfælde, vil der være et krav til hvilken dokument type, man kalder den enkelte med. Det vil fremgå af den returnerede fejlbesked, hvilke type koder, man kan anvende for den kaldte DROS.
Fejl i autentificeringen (herunder whitelisting) rapporteres tilbage til brugeren som en SOAP Fault.
5.1. Understøttelse af brugerhistorie: Opret Stable Dokument
Til at oprette et stable dokument skal servicen ITI-41: Provide And Registre Documentset anvendes.
Det dokument, der skal registreres sendes med. Bemærk, at det er anvenderens opgave at sætte requestet rigtigt sammen for at få registreret metadata om dokumentet i den bagvedliggende nationale XDS infrastruktur. Korrekt metadata er en forudsætning for at andre anvendere kan fremsøge dokumentet med meningsfyldte søge parametre (se DDS - Guide til anvendere for information om fremsøgning og hentning af dokumenter).
En vigtig detalje er Document Entry UUID, som sættes på DocumentEntry. Denne anvendes i forbindelse med "Ret Stable Dokument" og "Slet Dokument" og skal sættes med prefix "urn:uuid:". I nedenstående eksempel er det "urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2"
Helt overordnet vil et kald ITI-41 kunne laves med:
// Indlæs dokumentet, som skal registreres String documentPayload = getAppointmentXmlDocument(); // Opret documentEntry - boks 2 (core model) i transformeringsfiguren DocumentEntry documentEntry = createDocumentEntry(); // Opret kald/request - boks 2 og 3 (core model og RIM format) i transformeringsfiguren ProvideAndRegisterDocumentSetRequestType provideAndRegisterDocumentSetRequest = buildProvideAndRegisterDocumentSetRequestAftale(documentEntry, documentPayload); // Udfør kald - ITI kaldet mellem boks 3 (RIM format) og DROS i transformeringsfiguren RegistryResponseType registryResponse = iti41PortType.documentRepositoryProvideAndRegisterDocumentSetB(provideAndRegisterDocumentSetRequest); // Aflæs kaldets svar - boks 3 og 2 (RIM format og core model) i transformeringsfiguren handleResponse(registryResponse);
En del af felterne i documentEntry er felter, som kan findes i selve header delen af XML dokumentet. Derfor kan det at lave en documentEntry gøres på 2 måder: Hvis man selv har skabt XML dokumentet, så har man disse felters værdi og kan sætte dem direkte. Er XML dokumentet skabt på forhånd, kan man deserialisere det, og hente relevante informationer ud.
Når man udfylder documentEntry med metadata skal man overholde de danske regler defineret af Medcom (links fundet feb 2022):
- Den danske metadata profil: https://svn.medcom.dk/svn/releases/Standarder/IHE/DK_profil_metadata/Metadata-v096.pdf
- XDS metadata value set: http://svn.medcom.dk/svn/drafts/Standarder/IHE/OID/DK-IHE_Metadata-Common_Code_systems-Value_sets.xlsx
Det følgende eksempel viser, hvordan man kan sætte værdierne i documententry. Se "den danske metadta profil" for specifikke detaljer.
At lave ProvideAndRegisterDocumentSetRequestType kan gøres på følgende måde:
public ProvideAndRegisterDocumentSetRequestType buildProvideAndRegisterDocumentSetRequest(DocumentEntry documentEntry, String documentPayload, Code contentTypeCode) {
ProvideAndRegisterDocumentSet provideAndRegisterDocumentSet = new ProvideAndRegisterDocumentSet();
Document document = new Document(documentEntry, new DataHandler(new ByteArrayDataSource(documentPayload.getBytes(), documentEntry.getMimeType())));
provideAndRegisterDocumentSet.getDocuments().add(document);
// Opret SubmissionSet
SubmissionSet submissionSet = createSubmissionSet(documentEntry.getPatientId(), new Code("39289-4", new LocalizedString("Follow-up (referred to) provider &or specialist, appointment date"), "2.16.840.1.113883.6.1"), "20220221113011");
provideAndRegisterDocumentSet.setSubmissionSet(submissionSet);
// Opret association mellem SubmissionSet og DocumentEntry
Association association = createAssociation(submissionSet, documentEntry);
provideAndRegisterDocumentSet.getAssociations().add(association);
// 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();
return provideAndRegisterDocumentSetRequestType;
}
At oprette SubmissionSet kan gøres som:
public SubmissionSet createSubmissionSet(Identifiable patientIdentifiable, Code contentTypeCode, String submissionTime) {
SubmissionSet submissionSet = new SubmissionSet();
submissionSet.setUniqueId(generateId());
submissionSet.setSourceId(generateId());
submissionSet.setEntryUuid(generateUUID());
submissionSet.setPatientId(patientIdentifiable);
submissionSet.setContentTypeCode(contentTypeCode);
submissionSet.setAvailabilityStatus(AvailabilityStatus.APPROVED);
submissionSet.setSubmissionTime(submissionTime);
return submissionSet;
}
Og at oprette en association kan gøres som:
public Association createAssociation(SubmissionSet submissionSet, DocumentEntry documentEntry) {
Association association = new Association();
association.setAssociationType(AssociationType.HAS_MEMBER);
association.setEntryUuid(generateUUID());
association.setSourceUuid(submissionSet.getEntryUuid());
association.setTargetUuid(documentEntry.getEntryUuid());
association.setAvailabilityStatus(AvailabilityStatus.APPROVED);
association.setLabel(AssociationLabel.ORIGINAL);
return association;
}
Når kaldet er udført, tjekkes om alt gik, som det skulle:
public void handleResponse(RegistryResponseType registryResponse) {
// Transformer response - dette laver RIM format til core model
ResponseTransformer responseTransformer = new ResponseTransformer(ebXMLFactory);
Response response = responseTransformer.fromEbXML(new EbXMLRegistryResponse30(registryResponse));
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()) {
}
}
}
I requestet nedenfor ses selve dokumentet (som MTOM attachment) samt de specificerede metadata (den del af requestet, der er i tag SubmitObjectsRequest).
5.2. Understøttelse af brugerhistorie: Ret Stable Dokument
Til at uploade et nyt dokument, som en rettelse til et eksisterende dokument skal servicen ITI-41: Provide And Registre Documentset anvendes.
Det dokument, der skal registreres sendes med i requestet. Efter udførsel, vil det gamle dokument være deprecated.
Bemærk, at det er anvenderens opgave at sætte requestet rigtigt sammen for at få registreret metadata om dokumentet i den bagvedliggende nationale XDS infrastruktur. Korrekt metadata er en forudsætning for at andre anvendere kan fremsøge dokumentet med meningsfyldte søge parametre (se DDS - Guide til anvendere for information om fremsøgning og hentning af dokumenter).
Derudover er det anvenderens opgave at specificere, hvilket dokument der skal rettes. Til dette formål anvendes Document Entry UUID, hvorunder dokumentet er registreret i det nationale XDS Registry. Dette angives i forbindelse med "Opret Stable Dokument" se ovenfor. (Alternativt kan dette UUID findes ved først at gennemføre en søgning mod Dokumentdelingsservicen). I requestet angives dette med en Association med typen RPLC (replace).
En rettelse laves på samme måde, som ovenfor angivet ovenfor med opret et nyt dokument. Men derudover skal der, når man laver ProvideAndRegisterDocumentSetRequestType, oprettes en association mellem det gamle og det nye dokumententry. entryUuidFoDocuemntToReplace vil være urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2 ifald man vil rette det oprindelige dokument fra "Opret Stable Dokument".
// Hvis det er en opdatering af dokumentet, oprettes association mellem det gamle og det nye dokument vha. entryuuid'erne
if (doReplace && entryUuidForDocumentToReplace != null) {
Association replacementAssociation = new Association(AssociationType.REPLACE, generateUUID(), documentEntry.getEntryUuid(), entryUuidForDocumentToReplace);
provideAndRegisterDocumentSet.getAssociations().add(replacementAssociation);
}
I requestet nedenfor ses selve dokumentet (som MTOM attachment) samt de specificerede metadata (den del af requestet, der er i tag SubmitObjectsRequest).
5.3. Understøttelse af brugerhistorie: Opdater dokument metadata
Til at rette et dokument skal servicen ITI-57 Update Document Set anvendes. Man kan på NSP kun opdatere metadata for et stable dokument, og ikke et on-demand dokument.
Det er anvenderens opgave at specificere, hvilket dokument der skal opdateres ved at matche logcialId, uniqueId og objecttype (stable). Det fulde sæt af metadata skal sendes med i requestet og ikke kun, som ønskes ændret.
Helt overordnet vil et kald ITI-57 kunne laves med:
// Skaf documententry detaljer, som skal opdateres
DocumentEntry documentEntryToUpdate = getDocumentEntryToUpdate();
// Tildel ny entryuuid
documentEntryToUpdate.setEntryUuid(generateUUID());
// Opdater version
documentEntryToUpdate.setVersion(new Version("2"));
// Opdater det metadata som skal justeres. F.eks. practice setting
documentEntryToUpdate.setPracticeSettingCode(practiceSettingCode);
// Opret kald/ request
SubmitObjectsRequest submitObjectsRequest = createUpdateDocumentMetadataRequest(documentEntryToUpdate);
// Udfør kald
RegistryResponseType registryResponse = iti57PortType.documentRegistryUpdateDocumentSet(submitObjectsRequest);
// Aflæs kaldets svar
handleResponse(registryResponse);
At lave SubmitObjectsRequest kan gøres på følgende måde:
public SubmitObjectsRequest createUpdateRequest(DocumentEntry documentEntryToUpdate) {
RegisterDocumentSet request = new RegisterDocumentSet();
String oldVersion = "1";
// Opret SubmissionSet
SubmissionSet submissionSet = createSubmissionSetForDocumentEntry(generateUUID(), documentEntryToUpdate, generateUUID());
request.setSubmissionSet(submissionSet);
// Opret association mellem SubmissionSet og DocumentEntry der skal opdateres
Association association = createHasMemberAssociationWithPropagation(submissionSet, documentEntryToUpdate, oldVersion);
request.getAssociations().add(association);
// Sæt de nye metadata
request.getDocumentEntries().add(documentEntryToUpdate);
// Transformer request - dette laver core model om til RIM format
RegisterDocumentSetTransformer requestTransformer = new RegisterDocumentSetTransformer(ebXMLFactory);
EbXMLSubmitObjectsRequest30 ebxmlRequest = (EbXMLSubmitObjectsRequest30) requestTransformer.toEbXML(registerDocumentSet);
SubmitObjectsRequest submitObjectsRequest = ebxmlRequest.getInternal();
return submitObjectsRequest;
}
At oprette SubmissionSet kan gøres som:
private SubmissionSet createSubmissionSetForDocumentEntry(String id, DocumentEntry documentEntry, String uniqueId) {
SubmissionSet submissionSet = new SubmissionSet();
submissionSet.setEntryUuid(id);
submissionSet.setLogicalUuid(id);
submissionSet.setUniqueId(uniqueId);
submissionSet.setPatientId(documentEntry.getPatientId());
submissionSet.setSourceId(documentEntry.getRepositoryUniqueId());
submissionSet.setContentTypeCode(documentEntry.getTypeCode());
submissionSet.setSubmissionTime(new DateTime());
return submissionSet;
}
Og at oprette en association kan gøres som følgende.
public Association createHasMemberAssociationWithPropagation(SubmissionSet submissionSet, DocumentEntry documentEntry, String oldVersion) {
Association association = createAssociation(submissionSet, documentEntry);
association.setPreviousVersion(oldVersion);
association.setAssociationPropagation(true);
return association;
}
public Association createAssociation(SubmissionSet submissionSet, DocumentEntry documentEntry) {
// Opret association mellem SubmissionSet og DocumentEntry
Association association = new Association();
association.setAssociationType(AssociationType.HAS_MEMBER);
association.setEntryUuid(generateUUID());
association.setSourceUuid(submissionSet.getEntryUuid());
association.setTargetUuid(documentEntry.getEntryUuid());
association.setAvailabilityStatus(AvailabilityStatus.APPROVED);
association.setLabel(AssociationLabel.ORIGINAL);
return association;
}
I requestet nedenfor ses opdatering af metadata for et dokument.
5.4. Understøttelse af brugerhistorie: Slet Dokument
Til at slette et dokument skal servicen ITI-57: Update Document Set anvendes. Denne operation sletter ikke dokumentet fysisk, men vil registrere det med status 'deprecated' i det nationale XDS registry.
Deruodover er det anvenderens opgave at specificere, hvilket dokument der skal slettemarkeres (deprecates). Som det fremgår af nedenstående skal data fra den Document Entry, der ønskes slettemarkeret medsendes i requestet. Disse data angives i forbindelse med "Opret Stable Dokument" og har man dem derfra kan de anvendes. Alternativt kan der gennemføres en søgning mod Dokumentdelingsservicen for at finde disse data.
Helt overordnet vil et kald ITI-57 kunne laves med:
// Skaf documententry detaljer, som skal deprecates DocumentEntry documentEntryToDeprecate = getDocumentEntryToDeprecate(); // Opret kald/ request SubmitObjectsRequest submitObjectsRequest = createDeprecateRequest(documentEntryToDeprecate); // Udfør kald RegistryResponseType registryResponse = iti57PortType.documentRegistryUpdateDocumentSet(submitObjectsRequest); // Aflæs kaldets svar handleResponse(registryResponse);
At lave SubmitObjectsRequest kan gøres på følgende måde:
public SubmitObjectsRequest createDeprecateRequest(DocumentEntry documentEntryToDeprecate) {
RegisterDocumentSet request = new RegisterDocumentSet();
// Opret SubmissionSet
SubmissionSet submissionSet = createSubmissionSetForDocumentEntry(generateUUID(), documentEntryToDeprecate);
request.setSubmissionSet(submissionSet);
// Opret association mellem SubmissionSet og DocumentEntry der skal deprecates
Association association = createAssociateDeprecateStatus(submissionSet, documentEntryToDeprecate);
request.getAssociations().add(association);
// Transformer request - dette laver core model om til RIM format
RegisterDocumentSetTransformer requestTransformer = new RegisterDocumentSetTransformer(ebXMLFactory);
EbXMLSubmitObjectsRequest30 ebxmlRequest = (EbXMLSubmitObjectsRequest30) requestTransformer.toEbXML(registerDocumentSet);
SubmitObjectsRequest submitObjectsRequest = ebxmlRequest.getInternal();
return submitObjectsRequest;
}
At oprette SubmissionSet kan gøres som:
public SubmissionSet createSubmissionSetForDocumentEntry(String id, DocumentEntry documentEntryToDeprecate) {
SubmissionSet submissionSet = new SubmissionSet();
submissionSet.setEntryUuid(id);
submissionSet.setLogicalUuid(id);
submissionSet.setUniqueId(documentEntryToDeprecate.getEntryUuid());
submissionSet.setPatientId(documentEntryToDeprecate.getPatientId());
submissionSet.setSourceId(documentEntryToDeprecate.getRepositoryUniqueId());
submissionSet.setContentTypeCode(documentEntryToDeprecate.getTypeCode());
submissionSet.setSubmissionTime(new DateTime());
return submissionSet;
}
Og at oprette en association kan gøres som følgende. TargetUuid vil være urn:uuid:69d3b9f3-7919-40e0-8731-32fb339216c2 ifald man vil rette det oprindelige dokument fra "Opret Stable Dokument".
public Association createAssociateDeprecateStatus(SubmissionSet submissionSet, DocumentEntry documentEntryToDeprecate) {
Association association = new Association();
association.setAssociationType(AssociationType.UPDATE_AVAILABILITY_STATUS);
association.setSourceUuid(submissionSet.getLogicalUuid());
association.setTargetUuid(documentEntryToDeprecate.getEntryUuid());
association.setOriginalStatus(documentEntryToDeprecate.getAvailabilityStatus());
association.setNewStatus(AvailabilityStatus.DEPRECATED);
return association;
}
I requestet nedenfor ses både ny og gammel status under <Association> ligsom også documententry fremgår her med attributten targetObject.
5.5. Understøttelse af brugerhistorie: Opret On-demand Entry
Til at oprette en on-demand entry i det nationale XDS registry skal servicen ITI-61: Register On-Demand Document Entry anvendes.
Det er dokumentkildens ansvar (anvenderen) at medsende de korrekte metadata i requestet. Korrekt metadata sikrer, at det er muligt for dokumentanvendere senere at fremsøge og anvende dokumentet.
5.6. Understøttelse af brugerhistorie: Register Document Set (med og uden DGWS)
Til at oprette document entries i det nationale XDS registry skal servicen ITI-42: Register Document Set anvendes. Selve requestene er ens uanset, om DGWS benyttes eller ej. Request nedenfor kan derfor anvendes som inspiration i begge tilfælde.
Det er dokumentkildens ansvar (anvenderen) at medsende de korrekte metadata i requestet. Korrekt metadata sikrer, at det er muligt for dokumentanvendere senere at fremsøge og anvende dokumentet.