Publisert - 28.08.2026

Transaksjoner og søkeparametere

Denne delen gir en kort beskrivelse av IHE-transaksjonene som brukes i nasjonal dokumentdeling, samt søkeparameterne for hver transaksjon.

ITI-18 Registry Stored Query

Transaksjonen ITI-18 Registry Stored Query er en spørring som utføres av enten en Document Consumer eller en XCA-gateway mot et Document Registry for å finne dokumenter basert på definerte kriterier.

Eksempel:

<ns4:AdhocQueryRequest xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0">
    <ns4:ResponseOption returnType="LeafClass"/>
    <AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
        <Slot name="$XDSDocumentEntryPatientId">
            <ValueList>
                <Value>'12119000465^^^&2.16.578.1.12.4.1.4.1&ISO'</Value>
            </ValueList>
        </Slot>
        <Slot name="$XDSDocumentEntryStatus">
            <ValueList>
                <Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</Value>
            </ValueList>
        </Slot>
        <Slot name="$XDSDocumentEntryCreationTimeFrom">
            <ValueList>
                <Value>20230513000000</Value>
            </ValueList>
        </Slot>
        <Slot name="$XDSDocumentEntryCreationTimeTo">
            <ValueList>
                <Value>20240513235959</Value>
            </ValueList>
        </Slot>
    </AdhocQuery>
</ns4:AdhocQueryRequest>

ITI-18 spesifiserer mange ulike typer stored queries. For nasjonal bruk av ITI-18 er det kun krav om støtte for to stored queries for Document Consumers og XCA-gatewayer:

  • FindDocuments: Finner dokumenter i et Document Registry for en gitt patientID med et samsvarende availabilityStatus-attributt.
  • GetDocuments: Henter metadata for ett eller flere dokumenter basert på dokumentenes unike ID-er. Andre stored queries definert i 3.18.4.1.2.3.7 i ITI TF-2a er valgfrie, og XCA-communities som ikke støtter disse spørringene, skal returnere et vellykket resultat uten treff.

Søkeparametere for stored query FindDocuments

ITI TF-2a spesifiserer søkeparameterne for stored query «FindDocuments» (se ITI TF-2a 3.18.4.1.2.3.7.1). Stored query «FindDocuments» MÅ brukes med parameterne beskrevet i tabell 8.

I kolonne 2 beskrives kardinaliteten for hver parameter:

  • [1..1] angir at parameteren er påkrevd for Document Consumer, og at bare én verdi er tillatt.
  • [0..1] eller [0..*] angir at parameteren er valgfri for en Document Consumer, men når parameteren brukes, er én verdi [0..1] eller flere verdier [0..*] tillatt.
  • [0..0] angir «ikke i bruk».
Navn / attributt Kard. Opprinnelig beskrivelse (fra ITI TF-2a) Norsk nasjonal utvidelse Obligatorisk NO Datatype Mulig datakilde
$XDSDocumentEntry PatientId XDSDocumentEntry.patientId [1..1] patientId representerer personen dokumentet gjelder. Den inneholder Health ID med to deler: Authority Domain Id (OID håndhevet av Registry) og en ID i det aktuelle domenet utstedt av PDQ Supplier Actor. Formatet på patientId-verdien er CX. Se også ITI TF-3, 4.2.3.2.16 Tillatte nasjonale patientIds: Fødselsnr. (F-nr). OID = 2.16.578.1.12.4.1.4.1 Midlertidig nr. (D-nr): 2.16.578.1.12.4.1.4.2 Felles hjelpenr. (FH-nr): 2.16.578.1.12.4.1.4.3 Eksempel (F-nr): <rim:Slot name="$XDSDocumentEntryPatientId"> <rim:ValueList> <rim:Value> 12345612345^^^&2.16.578.1.12.4.1.4.1&ISO </rim:Value> </rim:ValueList> </rim:Slot> R2
$XDSDocumentEntry ClassCode XDSDocumentEntry. classCode [0..*] Koden som angir overordnet bruksklassifisering av dokumenttypen (f.eks. rapport, sammendrag, bilder, behandlingsplan, pasientpreferanser, arbeidsflyt). Se også ITI TF-3, 4.2.3.2.3 Dette attributtet MÅ representere en verdi fra det norske metadata-verdisettet Dokumenttyper 9602 (OID: 2.16.578.1.12.4.1.1.9602) (fra volven.no), nivå 1. Eksempel (A00-1 Epikriser og sammenfatninger): <rim:Slot name="$XDSDocumentEntryClassCode"> <rim:ValueList> <rim:Value> 'A00-1^^2.16.578.1.12.4.1.1.9602' </rim:Value> </rim:ValueList> </rim:Slot> R2 XON HM/HCP/CDA
$XDSDocumentEntry TypeCode XDSDocumentEntry. typeCode [0..*] Koden som angir den presise dokumenttypen fra brukerens perspektiv. Se også ITI TF-3, 4.2.3.2.25 Dette attributtet MÅ representere en verdi fra det norske metadata-verdisettet Dokumenttyper 9602 (OID: 2.16.578.1.12.4.1.1.9602) (fra volven.no), nivå 2. Eksempel (A03-2 Epikrise): <rim:Slot name="$XDSDocumentEntryClassCode"> <rim:ValueList> <rim:Value> 'A03-2^^2.16.578.1.12.4.1.1.9602' </rim:Value> </rim:ValueList> </rim:Slot> R2 XCN HM/HCP/CDA
$XDSDocumentEntry PracticeSettingCode XDSDocumentEntry. practiceSettingCode [0..*] Koden som angir den kliniske spesialiteten der handlingen som resulterte i dokumentet, ble utført (f.eks. allmennpraksis, laboratorium, radiologi). Se også ITI TF-3, 4.2.3.2.17. Merknad 1: Verdisettene er ikke spesifikke for praktisk bruk. Inntil videre kreves ikke praktisk bruk av denne parameteren for systemer som støtter rollen Document Register. Merknad 2: HSØs EPJ-produkt aksepterer parameteren, men filtrerer ikke resultatet basert på denne parameteren. Når attributtet er angitt, MÅ det representere en verdi fra de norske metadata-verdisettene definert i den norske IHE XDS-metadata-profilen. O String HM/HCP/CDA
$XDSDocumentEntry CreationTimeFrom Lower value of XDSDocumentEntry.creation Time [0..1] creationTime representerer tidspunktet da forfatteren opprettet dokumentet. Se også ITI TF-3, 4.2.3.2.6 Eksempel: <rim:Slot name="$XDSDocumentEntryCreationTimeFrom"> <rim:ValueList> <rim:Value>200412252300 </rim:Value> </rim:ValueList> </rim:Slot> O String HM/HCP/CDA
$XDSDocumentEntry CreationTimeTo Upper value of XDSDocumentEntry.creationTime [0..1] R URN IA
$XDSDocumentEntry ServiceStartTimeFrom Lower value of XDSDocumentEntry.serviceStartTime [0..1] Representerer starttidspunktet for tjenesten som dokumenteres (klinisk relevant, men ikke nødvendigvis tidspunktet da dokumentet ble produsert eller godkjent). Se også ITI TF-3, 4.2.3.2.19 R Code IA
$XDSDocumentEntry ServiceStartTimeTo Upper value of XDSDocumentEntry.serviceStartTime [0..1] - -
$XDSDocumentEntry ServiceStopTimeFrom Lower value of XDSDocumentEntry.serviceStopTime [0..1] Representerer sluttidspunktet for tjenesten som dokumenteres (klinisk relevant, men ikke nødvendigvis tidspunktet da dokumentet ble produsert eller godkjent). R Code IA
$XDSDocumentEntry ServiceStopTimeTo Upper value of XDSDocumentEntry.serviceStopTime [0..1] Se også ITI TF-3, 4.2.3.2.20 - -
$XDSDocumentEntry HealthcareFacilityTypeCode XDSDocumentEntry. healthcareFacilityTypeCode [0..*] Denne koden representerer typen organisatorisk kontekst for den kliniske kontakten der den dokumenterte handlingen fant sted. Se også ITI TF-3, 4.2.3.2.11. Merknad: Inntil videre kreves ikke bruk av denne parameteren for systemer som støtter rollen Document Register. Når attributtet er angitt, MÅ det representere en verdi fra det norske metadata-verdisettet 1303 Næringstype (SN 2007). Eksempler: 86.211 Allmenn legetjeneste, 86.212 Somatiske poliklinikker, 86.221 Spesialisert legetjeneste, unntatt psykiatrisk legetjeneste. R HM/HCP/CDA
$XDSDocumentEntry EventCodeList XDSDocumentEntry.eventCodeList [0..0] Denne listen med koder representerer de viktigste kliniske handlingene som dokumenteres, for eksempel en koloskopi eller appendektomi. Se også ITI TF-3, 4.2.3.2.8 Ikke i bruk. MÅ IKKE angis ([0..0]). R String AUT
$XDSDocumentEntry ConfidentialityCode XDSDocumentEntry. confidentialityCode [0..*] Koden som angir dokumentets sikkerhets- og personvernmarkeringer. Se også ITI TF-3, 4.2.3.2.5. Merknad 1: HSØs EPJ-produkt aksepterer parameteren, men filtrerer ikke resultatet basert på denne parameteren. Når attributtet er angitt, MÅ det representere en verdi fra det norske metadata-verdisettet. Se siste versjon av den norske profilen for IHE-metadata for detaljer. R2 Code HCP/CDA
$XDSDocument EntryAuthorPerson XDSDocumentEntry. author [0..*] Representerer menneskene og/eller maskinene som har forfattet dokumentet. Se også ITI TF-3 4.2.3.2.1. Merknad 1: HSØs EPJ-produkt aksepterer parameteren, men filtrerer ikke resultatet basert på denne parameteren. Dette attributtet MÅ følge datatypen XCN HL7 v2.5 Extended Person Name. Følgende verdier skal brukes: - Identifier - Last Name - First Name - Second and Further Given Names Eksempel på søk etter dokumenter med forfatter «Magnar Koman» med HPR-nr. 9144889: <rim:Slot name="$XDSDocumentEntryAuthorPerson"> <rim:ValueList> <rim:Value> 9144889^Koman^Magnar^^^^^^& 2.16.578.1.12.4.1.4.4&ISO </rim:Value> </rim:ValueList> </rim:Slot> R Code IA
$XDSDocumentEntry FormatCode XDSDocumentEntry.formatCode [0..*] Koden som angir dokumentets detaljerte tekniske format. Se også ITI TF-3, 4.2.3.2.9. Merknad 1: HSØs EPJ-produkt aksepterer parameteren, men filtrerer ikke resultatet basert på denne parameteren. Når attributtet er angitt, MÅ det være en gyldig verdi. Eksempel på søk etter epikrise v1.1: <rim:Slot name="$XDSDocumentEntry FormatCode "> <rim:ValueList> <rim:Value> urn:no:kith:xmlstds:epikrise:2006-09-23 </rim:Value> </rim:ValueList> </rim:Slot> R SHA1 AUT
$XDSDocument EntryStatus XDSDocumentEntry. status [1..*] Representerer statusen til DocumentEntry. En DocumentEntry skal ha én av to availability statuses: Approved: Dokumentet er tilgjengelig for pasientbehandling. Deprecated: Dokumentet er foreldet. Se også ITI TF-3, 4.2.3.2.2 En verdi MÅ brukes: urn:oasis:names:tc:ebxml-regrep:StatusType:Approved eller urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated R Code IA
$XDSDocument EntryType XDSDocumentEntry. objectType [0..*] Attributtet objectType angir typen DocumentEntry. Som beskrevet i ITI TF-3, avsnitt 4.1.1, finnes det to typer DocumentEntry: Stable Document Entry og On-Demand Document Entry. Se også ITI TF-3, 4.2.3.2.30 En verdi MÅ brukes: urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 (Stable documents) R OID URN IA
intendedRecipient - - - (O) -
launguageCode X R R CS IA

Respons

I FindDocuments stored queries kan en Document Consumer velge mellom to responstyper:

  1. ObjectRef: Returnerer kun dokumentenes unike identifikatorer (UUID og homeCommunityID).
  2. LeafClass: Returnerer alle metadata systemet kan returnere.

Når responstypen «LeafClass» brukes i en ITI-18 FindDocuments- eller GetDocuments-stored query, skal Document Register alltid returnere minst alle påkrevde metadata som beskrevet i den norske IHE XDS-metadata-profilen. Et eksempel på respons er inkludert i kapittel 5.

Søk i Utviklerportalen

Søket er fullført!