Transaksjoner og søkeparametere

This section will provide a brief description of the IHE transactions used in national document sharing, aswell as the search parameters for each transaction.

ITI-18 Registry Stored Query

ITI-18 Registry Stored Query transaction is a query done by either Document Consumer or XCA gateway against Document Registry to find documents with defined criteria.
Example:

<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 specifies many different types of stored queries. For national use of ITI-18 only two stored queries are required to support for Document Consumers and XCA gateways:

  • FindDocuments: Find documents in a document registry for a given patientID with a matching availabilityStatus attribute

  • GetDocuments: Retrieve metadata on (a collection of) documents given unique Ids on the documents. Other stored queries defined in 3.18.4.1.2.3.7 in ITI TF-2a is optional and XCA communities not supporting these stored queries shall return a zero successful result.

ITI TF-2a specifies the query parameters for a stored query “FindDocuments” (see ITI TF-2a 3.18.4.1.2.3.7.1). The stored query “FindDocuments” MUST be used using the parameters described in Table 8.
In column 2 the cardinality of each parameter is described:

  • [1..1] indicates that the parameter is required for the document consumer and only one value is allowed.

  • [0..1] or [0..*] indicates that the parameter is optional for a document consumer, but when using the parameter one [0..1] or multiple [0..*] values are allowed.

  • [0..0] indicates "not in use".

 

Name Attribute

Card.

Original descriptions (from ITI TF-2a)

Norwegian National Extension

Mandatory NO

Datatype

Possible data source

$XDSDocumentEntry PatientId XDSDocumentEntry.patientId

[1..1]

The patientId represents the subject of care of the document. It contains the Health ID with its two parts: Authority Domain Id (OID enforced by the Registry) An Id in the above domain issued by the PDQ Supplier Actor. The format of the patientId value is CX. See also ITI TF-3, 4.2.3.2.16

Allowed national patientIds: Birthnr (F-nr). OID = 2.16.578.1.12.4.1.4.1 Temporary nr (D-nr): 2.16.578.1.12.4.1.4.2

Common help nr: (FH-nr): 2.16.578.1.12.4.1.4.3

Example (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..*]

The code specifying the high-level use classification of the document type (e.g., Report, Summary, Images, Treatment Plan, Patient Preferences, Workflow). See also ITI TF-3, 4.2.3.2.3

This attribute MUST represent a value from the Norwegian Metadata Value-Set Dokumenttyper 9602 (OID: 2.16.578.1.12.4.1.1.9602) (from volven.no):, Level 1 Example (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..*]

The code specifying the precise type of document from the user perspective. See also ITI TF-3, 4.2.3.2.25

This attribute MUST represent a value from the Norwegian Metadata Value-Set Dokumenttyper 9602 (OID: 2.16.578.1.12.4.1.1.9602) (from volven.no):, Level 2 Example (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..*]

The code specifying the clinical specialty where the act that resulted in the document was performed (e.g., Family Practice, Laboratory, Radiology). See also ITI TF-3, 4.2.3.2.17 Remark 1: The value sets are not specific for practical usage. Until further notice practical usage of this parameter will not be required for systems that support the role Document Registers. Remark 2: HSØ's EHR product accepts the parameter but do not filter the result based on this parameter

When specified, this attribute MUST represent a value from the Norwegian Metadata Value-Sets defined in the Norwegian IHE XDS metadata profile

O

String

HM/HCP/CDA

$XDSDocumentEntry CreationTimeFrom Lower value of XDSDocumentEntry.creation Time

[0..1]

creationTime represents the time the author created the document. See also ITI TF-3,4.2.3.2.6

Example:

<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]

Represents the start time of the service being documented took place (clinically significant, but not necessarily when the document was produced or approved). See also 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]

Represents the stop time of the service being documented took place (clinically significant, but not necessarily when the document was produced or approved).

 

R

Code

IA

$XDSDocumentEntry ServiceStopTimeTo Upper value of XDSDocumentEntry.serviceStopTime

[0..1]

See also ITI TF-3, 4.2.3.2.20

 

-

 

-

$XDSDocumentEntry HealthcareFacilityTypeCode XDSDocumentEntry. healthcareFacilityTypeCode

[0..*]

This code represents the type of organizational setting of the clinical encounter during which the documented act occurred. See also ITI TF-3, 4.2.3.2.11 Remark: Until further notice usage of this parameter will not be required for systems that support the role Document Registers.

When specified, this attribute MUST represent a value from the Norwegian Metadata Value-Set: 1303 Næringstype (SN 2007) shall be used: Examples: 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]

This list of codes represents the main clinical acts, such as a colonoscopy or an appendectomy being documented. See also and ITI TF-3, 4.2.3.2.8

Not in use. MUST NOT be specified ([0..0]).

R

String

AUT

$XDSDocumentEntry ConfidentialityCode XDSDocumentEntry. confidentialityCode

[0..*]

The code specifying the security and privacy tags of the document. See also ITI TF-3, 4.2.3.2.5 Remark 1: HSØ's EHR product accepts the parameter but does not filter the result based on this parameter

When specified, this attribute MUST represent a value from the Norwegian Metadata Value Set: See last version of Norwegian profile of IHE metadata for details.

R2

Code

HCP/CDA

$XDSDocument EntryAuthorPerson XDSDocumentEntry. author

[0..*]

Represents the humans and/or machines that authored the document. See also ITI TF-3 4.2.3.2.1 Remark 1: HSØ's EHR product accepts the parameter but does not filter the result based on this parameter

This attribute MUST follow XCN HL7 v2.5 Extended Person Name datatype. Following values shall be used:

  • Identifier

  • Last Name

  • First Name

  • Second and Further Given Names


Example where searching after documents with author "Magnar Koman" with 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..*]

The code specifying the detailed technical format of the document. See also ITI TF-3, 4.2.3.2.9 Remark 1: HSØ's EHR product accepts the parameter but does not filter the result based on this parameter

When specified, this attribute MUST be a valid value
Example searching 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..*]

Represents the status of the DocumentEntry. A DocumentEntry shall have one of two availability statuses: Approved: The document is available for patient care. Deprecated: The document is obsolete. See also ITI TF-3, 4.2.3.2.2

A value MUST be used:
urn:oasis:names:tc:ebxml-regrep:StatusType:Approved
or
urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated

R

Code

IA

$XDSDocument EntryType XDSDocumentEntry. objectType

[0..*]

The objectType attribute reflects the type of DocumentEntry. As described in ITI TF-3, Section 4.1.1, there are two DocumentEntry types: Stable Document Entry and On-Demand Document Entry. See also ITI TF-3, 4.2.3.2.30

A value MUST be used:
urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 (Stable documents)

R

OID URN

IA

intendedRecipient

-

-

-

(O)

 

-

launguageCode

X

 

R

R

CS

IA

Response

In FindDocuments stored queries, a Document Consumer can choose between two response types:

  1. ObjectRef: Returns only the documents' unique identificators (UUID and homeCommunityID)

  2. LeafClass: Returns all metadata the system can return.

When the response type "LeafClass" is used in an ITI-18 FindDocument or GetDocuments stored query, the Document Register shall always return at least all required metadata as described in the Norwegian IHE XDS metadata profile. An example response is included in chapter 5.

Søk i Utviklerportalen

Søket er fullført!