Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

ITI-snitfladeSOAPActionDecoupling-url (test1)ServiceIdentifier
ITI41

urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b

http://test1.ekstern-test.nspop.dk:8080/decoupling/nspservices/aftaler/nspservices/aftaler
ITI42

urn:ihe:iti:2007:RegisterDocumentSet-b

http://test1.ekstern-test.nspop.dk:8080/decoupling/nspservices/aftaler/nspservices/aftaler
ITI57

urn:ihe:iti:2010:UpdateDocumentSet

http://test1.ekstern-test.nspop.dk:8080/decoupling/nspservices/aftaler/nspservices/aftaler
ITI61

urn:ihe:iti:2010:RegisterOnDemandDocumentEntry

http://test1.ekstern-test.nspop.dk:8080/decoupling/nspservices/aftaler/nspservices/aftaler


 Graviditetsmappe repository/registry via DCC

Håndterer dokumenttyperne Vandrejournal, Svangerskabsjournal, Kliniske målinger (PSCR,PRF og CMR)

...

Code Block
titleRegistrer Dokumentsæt Response
linenumberstrue
collapsetrue
----------------------------
ID: 5
Response-Code: 200
Encoding: UTF-8
Content-Type: text/xml;charset=UTF-8
Headers: {connection=[keep-alive], content-type=[text/xml;charset=UTF-8], Date=[Wed, 24 Mar 2021 12:26:49 GMT], Server=[WildFly/8], transfer-encoding=[chunked], X-Powered-By=[Undertow/1]}
Payload:
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns3:RegistryResponse xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
  </soap:Body>
</soap:Envelope>
--------------------------------------


Validering

Der er forskellige typer af validering i DROS. Ens for dem er, at de kan have forskellige "niveaer". Man kan får "fejl" tilbage som advarsler/warnings eller fejl/errors. Får man advarsler tilbage, vil ens request være udført. Får man fejl tilbage vil requestet være afvist og dermed ikke udført.

Man kan læse om de forskelle typer af validering i Design og arkitektur dokumentet.

Udvidet valideringsbibliotek

DROS gør brug af NSP validerings bibliotek til at validere de indkomne request. Reglerne i dette bibliotek kan læses i XDS validation  - guide til anvendere

DROS har en udvidet validering som benytter samme framework, som validerings biblioteket. Reglerne i denne udvidelse beskrives i det følgende. Princippene der anvendes er beskrevet i dokumentationen for NSP validerings biblioteket.

Feltvalideringer

Hver validering beskæftiger sig med et specifikt felt i et eller flere ITI kald

Afkrydningen i tabellens 4 sidste søjler indikerer, hvilke valideringer, den enkelte validator er inkludret i.

Søjlen "felt" kan anvendes til sortering, hvis man ønsker at se valideringen for et specifik felt på tværs af entitet.

KlasseFeltValideringITI 41ITI 42ITI 61ITI 57

DocumentEntryPatientIdExistsValidator

PatientId
  • ! forudsætning for validering: PatientId er udfyldt og af typen CPR
  • patientId.id findes ved kald til PatientInformation
xxxx

DocumentEntryAuthorInstitutionSorEnricher

AuthorInstitution
  • ! forudsætning for validering: Der er mindst en author og AuthorInstitution skal være af type SOR
  • der laves et opslag i Sores efter de sorkoder som findes på dokumentets authors i authorInstitution
xxxx

DocumentEntryAuthorInstitutionSorTypeValidator

AuthorInstitution
  • ! forudsætning for validering: der er lavet opslag efter sorkoder  for authors i authorInstitution
  • sorkoden skal findes ved opslag
  • typen for sorkoden skal være SI (sundhedsinstitution) eller OE (organisatorisk enhed)
xxxx