Norwegian profile for XDS metadata

This page provides a description of the metadata for the Norwegian XDS profile. This applies both to which attributes to use, how the attributes are to be used and which coding systems are to be used. XDS is content-agnostic, meaning it has no knowledge of the content of the document being shared or made available in an XDS solution.

Whether the document is a PDF, an XML file or an image makes no difference to the XDS solution, it will in any case just treat the file as a document without regard to content or format. Since XDS solutions have no relation to the content of the document, metadata must be registered that describe, among other things, the overall clinical content of the documents. It is this metadata that is used when searching for specific documents. The metadata are divided into the following areas:

  • Patient Identity: Attribute that identifies the patient that a document deals with, including patient ID (national identity number) and name.
  • Source/Provenance: Attribute that describes where the document has been generated.
  • Security & Privacy: Attribute that describes security rules and can be used to control access to the document.
  • Description of Content (Descriptive): Attribute that describes the clinical content of the document. This is an attribute that is important for performing searches and finding documents based on clinical "search parameters".
  • Document Status (Object Lifecycle): Attribute that describes the status of the document and any relationships to other documents Exchange: Attribute that describes how the document can be exchanged ("pull" or "push")

Use of XDS and information security

This profile does not describe how different users and solutions should access documents that are made available for lookup in an XDS solution.
XDS has several metadata attributes, such as the company (authorInstitution) that produced the document and the type of document (classCode/typeCode), which can provide a basis for how security and access management can be ensured.
However, there is no "built-in" security/access control in the metadata attributes directly, this must be taken care of by the solutions that together constitute one or more XDS areas and via the system solutions that provide access to documents in an XDS solution

Profile description

Some of the XML Types described below can be used to represent different concepts. The table below describes the different types.

Document Sharing Object/Association XML Type representation
DocumentEntry <ExtrinsicObject>
SubmissionSet <RegistryPackage>
Folder <RegistryPackage>
HasMember <Association>
MemberOf <Association>
Relationship <Association>

SubmissionSet (<RegistryPackage>)

SubmissionSet means that one submits multiple documents in a "package" and the metadata for the SubmissionSet can be compared to the package label on a package. This metadata summarizes the contents of the SubmissionSet and how documents, relationships, and folders are placed together. An example of when a SubmissionSet can be used is when one wants to collect all documents related to a hospital stay for a patient. When submitting a SubmissionSet it is the case that either all of the documents are put in the document archive. That is, if there is an error related to one of the documents, none of the documents will be placed in the archive.

DocumentEntry (<ExtrinsicObject>)

In this context, a DocumentEntry is the metadata registered on the individual document that is to be made available and shared in an XDS solution. This metadata does not contain the content of the document itself, but only metadata about the document. There are two types of DocumentEntry:

Property Description
Stable urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1
On-Demand urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248
  • Stable DocumentEntry contains data about a document that has already been generated and exists, and is available for download via the XDS solution.
  • On-demand DocumentEntry contains metadata with a unique id that can be used to generate a document when a request has been made for the document with that id.

🚩 Note!
PJD.XcaDocumentSource aswell as all document sources in Norway only support Stable-documents. This is described for informative purposes.
The usage of On-demand Documents in document sharing in Norway is not supported.

Association (<Association>)

An <Association> is used to bind two or more types together in order to create a logical connection between them. This is done using attributes sourceObject and targetObject attributes, referencing the unique identifiers of the associated types. An <Association> can have multiple states based on its associationType

Folder (<RegistryPackage>)

A Folder is a logical collection of those documents that have a relationship to each other. A Folder can be updated by multiple SubmissionSets, also sent from several different companies. This may, for example, be to collect all documents belonging to a laboratory examination, both the laboratory requisition and the associated laboratory results. This document does not specifically describe how to use Folder.

Overview of XDS attributes

XDS metadata in Norwegian profile

The following tags are used to indicate whether a metadata attribute is required or optional:

Kode Required Forklaring
R Required Attribute is Required and should always be provided
R2 Required if known The Attribute should be provided if the information is known to the system and available.
O Optional The attribute is optional, and each actor creating documents should decide whether to use the attribute or not.
- Should not be used The attribute should not be used.

A system integrated with an XDS solution must be able to receive and manage all attributes specified by tags R, R2, or O.

For some attributes, the content to be recorded for the various metadata attributes can be retrieved from different data sources. For example, the data sources can be an discharge summary document that contains information that can be included in one or more metadata attributes. Which data sources may be relevant for different metadata attributes may vary between different solutions/professional systems used.
The table below shows possible data sources for the metadata information.

Code Description
AUT Metadata which is automatically generated or assigned by either the XDS registry or XDS repository
CDA Data which can be extracted from the header of a HL7 CDA-document (or equivalent)
HM Data which can be extracted from the header; applies to all messages utilizing a header. (i.e. e-prescription) to assign sender, reciever and patient.
HCP Data which can be extracted from standards utilizing the HCP-structure (HCP = Health Care Professional). This applies to standards for referral, clinical summaries, laboratory requisition and responses.
IA IA = Ikke Angitt (Not specified). The attribute shall be used in the Norwegian profile, but it may be a difference in where the information is sourced. Its up to each actor to decide what is a relevant source.
Attribute DocumentEntry SubmissionSet Mandatory IHE Mandatory NO Datatype Possible data source
Author X X R R2 -
author.authorInstitution X X - R2 XON HM/HCP/CDA
author.authorPerson X X - R2 XCN HM/HCP/CDA
author.authorRole X X - O String HM/HCP/CDA
author.authorSpeciality X X - O String HM/HCP/CDA
availabilityStatus X X R R URN IA
classCode X - R R Code IA
comments - - - - - -
confidentialityCode X - R R Code IA
contentTypeCode - - - - - -
creationTime X - R R - HM/HCP/CDA
entryUUID X X R R String AUT
eventCodeList X - O R2 Code HCP/CDA
formatCode X - R R Code IA
hash1 X - R R SHA1 AUT
healthcareFacilityTypeCode X - R R Code IA
homeCommunityId X X R R OID URN IA
intendedRecipient - - - (O)2 - -
languageCode X - R R CS IA
legalAuthenticator X O R2 XCN IA (CDA, HCP)
limitedMetadata - - - - - -
mimeType X R R String IA -
objectType X R R UUID IA -
patientId X R R CX HM/HCP/CDA -
practiceSettingCode X R R2 Code IA -
referenceIdList X O O CXi IA -
repositoryUniqueId X R R OID AUT -
serviceStartTime X R2 R2 DTM IA -
serviceStopTime X R2 R2 DTM IA -
size3 X R R Integer AUT -
sourceId X - O OID - -
sourcePatientId X R R CX HM/HCP/CDA -
sourcePatientInfo X R R PID HM/HCP/CDA -
submissionTime X R R DTM IA -
title X X O O String HM/HCP/CDA
typeCode X R R Code HM/HCP/CDA -
uniqueId X X R R OID HM/HCP/CDA
URI X R2 R2 URI AUT -

1 This attribute shall not be used for "on-demand" type documents.
2 This attribute is not part of the profile, but can be tried out.
3 This attribute shall not be used for "on-demand" type documents.

Datatypes

The datatypes used are according to the XDS specification from IHE.

OIDs

The table below gives an overview of which OIDs (Object-identifiers) are used in the metadata profile. |Kategori|OID| |---|---| |Kodeverk på Volven.no|2.16.578.1.12.4.1.1.XXXX| |Fødselsnummer|2.16.578.1.12.4.1.4.1| |D-nummer|2.16.578.1.12.4.1.4.2| |Felles hjelpenummer|2.16.578.1.12.4.1.4.3| |HPR-nummer|2.16.578.1.12.4.1.4.4| |Duf-nummer|2.16.578.1.12.4.1.4.5| |Organisasjonsnummer|2.16.578.1.12.4.1.4.101|

UUIDs in use in metadata

Submission Set
UUID Usage/Meaning
urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd SubmissionSet ClassificationNode
urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d author External Classification Scheme
urn:uuid:aa543740-bdda-424e-8c96-df4873be8500 contentTypeCode External Classification Scheme
urn:uuid:6b5aea1a-874d-4603-a4bc-96a0a7b38446 patientId External Identifier
urn:uuid:554ac39e-e3fe-47fe-b233-965d2a147832 sourceId External Identifier
urn:uuid:96fdda7c-d067-4183-912e-bf5ee74998a8 uniqueId External Identifier
DocumentEntry object
UUID Usage/Meaning
urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d author External Classification Scheme
urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a classCode External Classification Scheme
urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f confidentialityCode External Classification Scheme
urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4 eventCodeList External Classification Scheme
urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d formatCode External Classification Scheme
urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1 healthCareFacilityTypeCode External Classification Scheme
urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427 patientId ExternalIdentifier
urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead practiceSettingCode External Classification Scheme
urn:uuid:f0306f51-975f-434e-a61c-c59651d33983 typeCode External Classification Scheme
urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab uniqueId ExternalIdentifier

XDS attributes in Norwegian profile

AuthorInstitution

Attribute name AuthorInstitution
Description and usage Shall contain the name and identificator for the organization which has produces the document. Organization number shall be used as the identificator
Required/
optional		 DocumentEntry R2
SubmissionSet R2
Data source HM (messages that use the Head Message), HCP (messages that use the HealtCareProfessional structure) and CDA.
Datatype XON - HL7 V2.5 Organization Name
CodeSystem/
specification		 The following codes may be used:
  • XON.1 - Organization Name (displayName)
  • XON.6.2 - Assigning Authority (codeSystem)
  • XON.10 Organization Identifier (code) OID 2.16.578.1.12.4.1.4.101 shall be used to indicate that the organisation number is used as an identifier
XML-example
(with ebRIM)		 example where St. Olavs Hospital HF with organization-number 883974832 is used. 
<rim:Slot name="authorInstitution">
<rim:ValueList>
<rim:Value>
St Olavs Hospital HF^^^^^&2.16.578.1.12.4.1.4.101&ISO8883974832
</rim:Value>
</rim:ValueList>
</rim:Slot>
Same example but with RESH-ID: 
<rim:Slot name="authorInstitution">
<rim:ValueList>
<rim:Value>Medisinsk klinikk^^^^^&2.16.578.1.12.4.1.4.102&ISO104218</rim:Value>
<rim:Value>St Olavs Hospital HF^^^^^&2.16.578.1.12.4.1.4.101&ISO^^^^883974832</rim:Value>
</rim:ValueList>
</rim:Slot>

AuthorPerson

Attribute name AuthorPerson
Description and usage Must include the name and identifier of the person who is the author of the document. If the document is not authored by a person, the item may be left without content.
National identifiers for people can be used.
Required/
optional		 DocumentEntry R2
SubmissionSet R2
Data source HM (messages that use the Head Message), HCP (messages that use the HealtCareProfessional structure) and CDA.
Datatype XCN - HL7 V2.5 Extended Person Name
CodeSystem/
specification		 The following codes may be used:
  • Identifier
  • Last Name
  • First Name
  • Second and Further Given Names The following OIDs for national identifiers can be used:
  • National identity number: 2.16.578.1.12.4.1.4.1
  • D number: 2.16.578.1.12.4.1.4.2
  • Common helpline: 2.16.578.1.12.4.1.4.3
  • HPR No: 2.16.578.1.12.4.1.4.4
  • DUF number: 2.16.578.1.12.4.1.4.5
XML-example
(with ebRIM)		 Example where Magnar Koman is stated with HPR number 9144889: 
<rim:Slot name="authorPerson">
<rim:ValueList>
<rim:Value>9144889KomanMagnar^^^^^^& 2.16.578.1.12.4.1.4.4&ISO</rim:Value>
</rim:ValueList>
</rim:Slot>

AuthorRole

Attribute name AuthorRole
Description and usage If information about the author's role is known, this can be provided.
Required/
optional		 DocumentEntry O
SubmissionSet O
Data source HM (messages that use the Head Message), HCP (messages that use the HealtCareProfessional structure) and CDA.
Datatype CX
CodeSystem/
specification		 Coding system 9034 Health personnel's functions must be used to specify the role.
The code value must be specified, see example below.
XML-example
(with ebRIM)		 
<rim:Slot name="authorRole">
    <rim:ValueList>
        <rim:Value>10^^^&2.16.578.1.12.4.1.1.9034&ISO </rim:Value>
    </rim:ValueList>
</rim:Slot>

AuthorSpeciality

Attribute name AuthorSpeciality
Description and usage If information about the author's specialty is known, this must be provided.
Required/
optional		 DocumentEntry O
SubmissionSet O
Data source HM (messages that use the Head Message), HCP (messages that use the HealtCareProfessional structure) and CDA.
Datatype CX
CodeSystem/
specification		 Coding system 7426 The Health Personnel Register's (HPR) classification of specialties shall be used to specify the role.
XML-example
(with ebRIM) 
<rim:Slot name="authorSpeciality">
    <rim:ValueList>
        <rim:Value>35^^^&2.16.578.1.12.4.1.1.7426&ISO </rim:Value>
    </rim:ValueList>
</rim:Slot>

availabilityStatus

Attribute name availabilityStatus
Description and usage Indicates the status of the document, two statuses are possible:
  • Approved = the document is available
  • Deprecated = the document is obsolete In the case of a documentEntry, the status of a document can either be set to Approved or Deprecated.
    In the case of a SubmissionSet, the status can only be set to Approved.
Required/
optional		 DocumentEntry R
SubmissionSet R
Data source IA (not specified). Each actor must decide for themselves where this information can be obtained from.
Datatype String
CodeSystem/
specification		 Coding system 7426 The Health Personnel Register's (HPR) classification of specialties shall be used to specify the role.
XML-example
(with ebRIM)		 
<ExtrinsicObject
id="urn:uuid:fbeacdb7-5421-4474-9267-985007cd8855"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved">

classCode

Attribute name classCode
Description and usage The classCode attribute should describe which document group the document belongs to at a general level. This attribute must be seen in conjunction with the typeCode attribute (see chapter 3.5.31), which is intended to describe the type of document at a more detailed level.
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source IA (not specified). Each actor must decide for themselves where this information can be obtained from.
Datatype String
CodeSystem/
specification		 The classCode attribute should have the following urn for classificationScheme: urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a. Coded as an ebRIM classification.
Level 1 codes should be used (codes ending in "-1") in the classCode attribute. OID: 2.16.578.1.12.4.1.1.9602
XML-example
(with ebRIM)		 Code value = "1-A00"
Code text = "Discharge summaries and summaries"
CodeSystem = "2.16.578.1.12.4.1.1.9602" 
<rim:Classification 
    classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" 
    classifiedObject="ExampleDocument" 
    id="IdExample_046" 
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" 
    nodeRepresentation=" A00-1">
    <rim:Name>
        <rim:LocalizedString value="Epikriser og sammenfatninger"/>
    </rim:Name>
    <rim:Slot name="codingScheme">
        <rim:ValueList>
            <rim:Value>2.16.578.1.12.4.1.1.9602</rim:Value>
        </rim:ValueList>
    </rim:Slot>
</rim:Classification>

comments

The comments attribute is not used in this profile.

confidentialityCode

Attribute name confidentialityCode
Description and usage This attribute indicates which Confidentiality group to which the document belongs. In Norway, there is a distinction does not normally rely on different degrees of confidentiality for documents that contains health and personal data. It will therefore often be only be the code value "Normal" ("N") that is relevant to use for this Attribute.

Extended use of the attribute has been adopted. If you need to set "blocking" and "refusing" (sperring og nekting) of documents, this attribute must be used until a common solution for access management/blocking management is in place established.

Required/
optional		 DocumentEntry R
SubmissionSet -
Data source IA (not specified). Each actor must decide for themselves where this information can be obtained from.
Datatype Code
CodeSystem/
specification		 The confidentialityCode should have the following URN for the classificationScheme: urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f.

The following coding system must be used to indicate confidentiality, blocking and refusal of documents:
Coding system: OID: 2.16.578.1.12.4.1.1.9603 Sperring og nekting av dokumenter

XML-example
(with ebRIM)		 
<rim:Classification
classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="ExampleDocument"
id="IdExample_046"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="N">
<rim:Name>
<rim:LocalizedString value="Normal"/>
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>2.16.578.1.12.4.1.1.9603</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>

contentTypeCode

The contentTypeCode attribute is not used in this profile

creationTime

Attribute name creationTime
Description and usage This attribute specifies the time when the author created the document.
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source HM (messages that use Head Message), HCP (messages that use the HealthCareProfessional structure) and CDA. For Header Message, time can be retrieved from the item MsgHead/MsgInfo/GenDate.
Datatype DTM - HL7 V2.5 Date Time
CodeSystem/
specification		 All times must be stated in the format:
YYYYMMDDhhmmss
YYYY = year
MM = month DD = day hh = hours mm = minutes
ss = seconds
All times must be stated in UTC time zone
XML-example
(with ebRIM)		 Example of the time on August 25, 2015 at 15:37:20 UTC: 
<rim:Slot name="creationTime"> 
    <rim:ValueList> 
        <rim:Value>20150825153720</rim:Value> 
    </rim:ValueList> 
</rim:Slot>

entryUUID

Attribute name  
Description and usage This attribute specifies a globally unique identifier for the document. entryUUID is primarily an ID intended for internal document management. This is in contrast to the uniqueId attribute which is used primarily for external references (e.g. links, etc.).
Required/
optional		 DocumentEntry R
SubmissionSet R
Data source AUT. Metadata that is automatically generated or assigned by either the XDS registry or the XDS repository.
Datatype String
CodeSystem/
specification

The UUID must be in the format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, where each X can be a character of type [A-Fa-f0-9].
See RFC 4122 for UUIDs as URNs.

XML-example
(with ebRIM)		 
<rim:ExtrinsicObject mimeType="text/xml"
id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"

</rim:ExtrinsicObject>

eventCodeList

Attribute name eventCodeList
Description and usage eventCodeList describes the clinical measures/procedures that have been performed.
Required/
optional		 DocumentEntry O
SubmissionSet -
Data source HCP (messages using the HealthCareProfessional structure) and CDA.
Datatype Code
CodeSystem/
specification		 The following procedural coding systems may be used:
  • NCRP (7270)
  • NCMP (7220)
  • NCSP (7210)
  • Norwegian Pathology Coding System (7010)

classificationScheme = urn:uuid:2c6b8cb7-8b2a-4051-b291b1ae6a575ef4

XML-example
(with ebRIM)		 
<rim:Classification
classificationScheme="urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="ExampleDocument"
id="IdExample_048"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="AAA27">
<rim:Name>
<rim:LocalizedString value="Innlegging av intracerebral trykkmåler"/>
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>2.16.578.1.12.4.1.1.7210</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>

formatCode

Attribute name formatCode
Description and usage This should be a unique code that describes the format of the document. The shape of the code should be an URN. Together with typeCode, this should be enough information for an "XDS consumer" to determine whether one is able to process the document.
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source IA (not specified). Each actor must decide for themself where this information can be obtained from.
Datatype Code
CodeSystem/
specification

The formatCode attribute should have the following urn for classificationScheme: UUID: A09D5840-386C-46F2-B5AD-9C3699A4309D
The URN format can be as follows: urn:<domene>:<format>:<navnerom>:<dato> Examples:

  • urn:no:kith:xmlstds:epikrise:2012 - Epikrise 1.2
  • urn:no:ehelse:xmlstds:henvisning:2017 - Henvisning ny tilstand
  • urn:no:kith:xmlstds:henvisning:2012 - Henvisning 1.1
XML-example
(with ebRIM)		 
<rim:Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="ExampleDocument"
id="IdExample_049"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="ExampleformatCode">
<rim:Name>
<rim:LocalizedString value="Resept"/>
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>urn:no:kith:xmlstds:eresept:m1:2013-1008</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>

hash

Attribute name hash
Description and usage This is a hash of the contents of the document.
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source AUT: Metadata that is automatically generated or assigned by either XDS registry or XDS repository.
Datatype SHA1
CodeSystem/
specification		 The format of the hash should be SHA1 according to the IHE specification.
XML-example
(with ebRIM)		 
<rim:Slot name="hash"> 
    <rim:ValueList>     
        <rim:Value>da39a3ee5e6b4b0d3255bfef95601890afd80709</rim:Value> 
    </rim:ValueList> 
</rim:Slot>

healthcareFacilityTypeCode

Attribute name healthcareFacilityTypeCode
Description and usage Describes the type of healthcare facility that generated the document to which the metadata applies.
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source

IA (not specified). Each actor must decide for themself where this information can be obtained from.
Information about this corresponds to what it should be possible to obtain about one's own healthcare facility from the Brønnøysund Registers (brreg).

Datatype Code
CodeSystem/
specification

Coding system 1303 Næringstype (SN 2007) shall be used.
classificationScheme = urn:uuid:f33fb8ac-18af-42cc-ae0eed0b0bdb91e1.

XML-example
(with ebRIM)		 
<rim:Classification

classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="ExampleDocument"
id="IdExample_050"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="86.101">
<rim:Name>
<rim:value "Alminnelige somatiske sykehus"/>
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>2.16.578.1.12.4.1.1.1303</rim:Value>
</rim:ValueList>
</rim:Slot>
</rim:Classification>

homeCommunityID

Attribute name homeCommunityId
Description and usage

This is a unique ID, in the form of an OID, for where the document is located (i.e. in which repository the document is located).
Those responsible for establishing XDS solutions must ensure that the OID exists.
According to ITI XCA: A unique identifier (OID) for a "community" that is used subsequently to the corresponding web service endpoint (URI of the XCA Responding gateway(s)) to obtain.

Required/
optional		 DocumentEntry R
SubmissionSet R
Data source AUT: is assigned by either the repository or registry solution.
Datatype OID URN
CodeSystem/
specification		  
XML-example
(with ebRIM)		 
<rim:ExtrinsicObject home="urn:oid:1.2.3" ...>
...

</rim:ExtrinsicObject>

intendedRecipient

The attribute is Optional for those who want to try it out.

Attribute name intendedRecipient
Description and usage The organization(s) or person(s) for whom the document is intended.
Required/
optional		 DocumentEntry -
SubmissionSet O
Data source

IA (not specified). Each actor must decide for themself where this information can be obtained from.

Datatype ebRIM Slot
CodeSystem/
specification		 XON|XCN|XTN, in which;

  • XON identifies an organization,
  • XCN identifies a person and
  • XTN identifies telecommunications.
XML-example
(with ebRIM)		 
<rim:Slot name="intendedRecipient">
<rim:ValueList>
<rim:Value>
Et Sykehusl^^^^^1.2.3.9.1789.45|
OlaNordmannDrMD|
^^Internet^ola@l@healthcare.example.org
</rim:Value>
</rim:ValueList>
</rim:Slot>

languageCode

Attribute name languageCode
Description and usage Specifies the language used in the document
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source AUT
Datatype CS
CodeSystem/
specification

languageCode should be in the form nn-CC. The content must be in accordance with IETF (Internet Engineering Task Force) RFC 5646. Use:
The "nn" part should be a code from ISO-639-1 in the lower case. The "CC" part, if provided, shall be a code ISO-3166 in the upper case. Norwegian should be able to be used as the "default" value in the vast majority of cases.

XML-example
(with ebRIM)		 
<rim:Slot name="languageCode">
<rim:ValueList>
<rim:Value>”nb-NO”</rim:Value>
</rim:ValueList>
</rim:Slot>

legalAuthenticator

Attribute name legalAuthenticator
Description and usage

Must contain the name and identifier of the person who has approved or signed the document ("legally authenticated or attested the document").
National identifiers may be used.

Required/
optional		 DocumentEntry R2
SubmissionSet -
Data source

IA (not specified). Each actor must decide for themself where this information can be obtained from.

Datatype XCN - HL7 V2.5 Extended Person Name
CodeSystem/
specification		 The following codes may be used:

  • Identifier
  • Last Name
  • First Name
  • Second and Further Given Names The following OIDs for national identifiers can be used:
  • National identity number: 2.16.578.1.12.4.1.4.1
  • D number: 2.16.578.1.12.4.1.4.2
  • Common helpline: 2.16.578.1.12.4.1.4.3
  • HPR No: 2.16.578.1.12.4.1.4.4
  • DUF number: 2.16.578.1.12.4.1.4.5
XML-example
(with ebRIM)		 Example where Magnar Koman is stated with HPR-nr 9144889: 
<rim:Slot name="legalAuthenticator">
<rim:ValueList>
<rim:Value>
9144889KomanMagnar^^^^^^&2.16.578.1.12.4.1.4.4&ISO
</rim:Value>
</rim:ValueList>
</rim:Slot>

limitedMetadata

The limitedMetadata attribute is not used in this profile.

mimeType

Attribute name mimeType
Description and usage Must describe the mime type of the document in the repository (document archive).
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source

IA (not specified). Each actor must decide for themself where this information can be obtained from.

Datatype String
CodeSystem/
specification		 Mime type shall be an "Internet Media Type" according to the "MIME" standard described in RFC 2045 to RFC 2049.
Valid mime types can be found at IANA Media Types
XML-example
(with ebRIM)		 
<rim:ExtrinsicObject
mimeType="text/xml"

id="ExampleDocument"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">
</rim:ExtrinsicObject>

objectType

Attribute name objectType
Description and usage

objectType describes the type of documentEntry that the document belongs to.
DocumentEntry can be one of these types:

  • "Stable DocumentEntry": contains medadata about a document that has already been generated and exists and is available for download via the XDS solution.
  • "On-demand DocumentEntry": contains metadata with a unique ID that can be used to generate a document when a request has been made for the document with that ID. In this way, one can access a document that contains the latest relevant information that the document is intended to contain.
    Unless otherwise specified, only Stable DocumentEntry is currently used in Norway.
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source

IA (not specified). Each actor must decide for themself where this information can be obtained from.

Datatype UUID
CodeSystem/
specification

The format of the value in objectType should be of type UUID.
The URN for Stable DocumentEntry should be: urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1

XML-example
(with ebRIM)		 
<rim:ExtrinsicObject
mimeType="text/xml"
id="urn:uuid:a6e06ca8-0c75-4064-9e5c-88b9045a96f6"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1">

patientId

Attribute name patientId
Description and usage

A unique identifier for the patient, national identifiers such as national identity number and Dnumber can be used.

Required/
optional		 DocumentEntry R
SubmissionSet -
Data source

HM (messages that use Head Message), HCP (messages that use the HealthCareProfessional structure) and CDA.
Datatype CX (ebRIM Slot), HL7 V2.5 Identifier
CodeSystem/
specification

The following OIDs for national identifiers can be used:

  • National identity number: 2.16.578.1.12.4.1.4.1
  • D number: 2.16.578.1.12.4.1.4.2
  • Common helpline: 2.16.578.1.12.4.1.4.3
  • DUF number: 2.16.578.1.12.4.1.4.5 The patientId attribute should have the following urn for classificationScheme:
    uuid: urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427
XML-example
(with ebRIM)		 Example where national identity number is stated: 
<rim:ExternalIdentifier
identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fda8ffeff98427"
value="15076500565^^^&2.16.578.1.12.4.1.4.1&ISO"
id="IdExample_051"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
registryObject="DocumentEntry01">
<rim:Name>
<rim:LocalizedString value="XDSDocumentEntry.patientId "/>
</rim:Name>
</rim:ExternalIdentifier>

practiceSettingCode

Attribute name practiceSettingCode
Description and usage Used to indicate the type of healthcare provided at the institution/unit.
Required/
optional		 DocumentEntry R2
SubmissionSet -
Data source IA (not specified). Each actor must decide for themself where this information can be obtained from.
Datatype  
CodeSystem/
specification

The following coding systems may be relevant:

  • 8651 Akutt-, anestesi- og intensivmedisin
  • 8653 Generelle kliniske tjenester
  • 8654 Klinisk medisinsk service
  • 8655 Helsehjelpsområde classificationScheme: urn:uuid:cccf5598-8b07-4b77-a05e-2015 ae952c785ead.
XML-example
(with ebRIM)		 
<rim:Classification
ClassificationScheme="urn:uuid:cccf5598-8b07-4b77-a05eae952c785ead"
classifiedObject="ExampleDocument"
id="IdExample_052"
objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"
nodeRepresentation="2.16.578.1.12.4.1.1.8655">
<rim:Name>
<rim:LocalizedString value="Kirurgi" />
</rim:Name>
<rim:Slot name="codingScheme">
<rim:ValueList>
<rim:Value>S02 </rim:Value>
</rim:ValueList>
</rim:Slot>

referenceIdList

Attribute name referenceIdList
Description and usage Examples of such identifiers can be order numbers or referral IDs.
Required/
optional		 DocumentEntry O
SubmissionSet -
Data source IA (not specified). Each actor must decide for themself where this information can be obtained from.
Datatype CXi
CodeSystem/
specification		 Coded as an ebRIM slot.
The maximum length for each value is 256 characters.
The "name" in the ebRIM slot should be "urn:ihe:iti:xds:2013:referenceIdList".
XML-example
(with ebRIM)		 
<rim:Slot name="urn:ihe:iti:xds:2013:referenceIdList">
    <rim:ValueList>
        <rim:Value>2013001^^^&1.2.3.4.5.6&ISO^urn:ihe:iti:xds:2013:accession</rim:Value>
        <rim:Value> 1.2.3.12.78.23^^^^urn:ihe:iti:xds:2013:uniqueId^&1.2.3.4&ISO</rim:Value>
    </rim:ValueList>
</rim:Slot>

repositoryUniqueId

Attribute name repositoryUniqueId
Description and usage This attribute should contain a global unique ID that identifies the repository where the referenced document can be found.
Each repository should have its own OID.
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source AUT: Fixed value for the individual XDS repository.
Datatype OID
CodeSystem/
specification		 Coded as an ebRIM slot.
The maximum length is 64 characters.
XML-example
(with ebRIM)		 
<rim:Slot name="repositoryUniqueId"> 
    <rim:ValueList> 
        <rim:Value>1.3.6.1.4.5</rim:Value> 
    </rim:ValueList> 
</rim:Slot>

serviceStartTime

Attribute name serviceStartTime
Description and usage Contains the date and time when the clinical service/contact described in the document started.
This is not necessarily when the document was created or approved, but when the clinical service started.
This can be the same as time for contact in case the service was provided during a contact. The time for contact is not stated in metadata, but can be stated in the document itself.
Required/
optional		 DocumentEntry R2
SubmissionSet -
Data source IA (not specified). Each actor must decide for themself where this information can be obtained from.
Datatype DTM, HL7 V2.5 Date Time
CodeSystem/
specification		 Coded as an ebRIM slot.
XML-example
(with ebRIM)		 Example: 16. october 2015, 21:20:10 UTC 
<rim:Slot name="serviceStartTime"> 
    <rim:ValueList> 
        <rim:Value>20151016212010</rim:Value> 
    </rim:ValueList> 
</rim:Slot>

serviceStopTime

Attribute name serviceStopTime
Description and usage Contains the date and time when the clinical service/contact described in the document stopped. This is not necessarily when the document was created or approved, but when the clinical service was completed. This can be the same as time for contact in case the service was provided during a contact. The time of contact is not stated in the metadata, but can be stated in the document itself.
Required/
optional		 DocumentEntry R2
SubmissionSet -
Data source IA (not specified). Each actor must decide for themself where this information can be obtained from.
Datatype DTM, HL7 V2.5 Date Time
CodeSystem/
specification		 Coded as an ebRIM slot.
XML-example
(with ebRIM)		 Example: 16. october 2015, 22:35:45 UTC 
<rim:Slot name="serviceStartTime"> 
    <rim:ValueList> 
        <rim:Value>20151016223545</rim:Value> 
    </rim:ValueList> 
</rim:Slot>

size

Attribute name size
Description and usage The size of the document in bytes.
Note: The Document Source where the document is produced must not state size, but this must be registered by the document repository if it is not specified by the document source.
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source AUT: Metadata that is automatically generated or assigned by either XDS registry or XDS repository.
Datatype Int
CodeSystem/
specification		 Coded as an ebRIM Slot, max 256 characters.
XML-example
(with ebRIM)		 
<rim:Slot name="size"> 
    <rim:ValueList> 
        <rim:Value>7411</rim:Value> 
    </rim:ValueList> 
</rim:Slot>

sourcePatientId

Attribute name sourcePatientId
Description and usage Identifier of the patient as registered in the source system where the document was produced. Can be both national identifiers such as national identity numbers or local IDs, depending on what is used in the source system.
Required/
optional		 DocumentEntry R
SubmissionSet -
Data source HM (messages that use Head Message), HCP (messages that use the HealthCareProfessional structure) and CDA.
Datatype HL7 v2.5 CX data type
CodeSystem/
specification		 Coded as an ebRIM slot.
The maximum length is 256 characters. The following identifier OIDs can be used:
  • National identity number: 2.16.578.1.12.4.1.4.1
  • D number: 2.16.578.1.12.4.1.4.2
  • Common helpline: 2.16.578.1.12.4.1.4.3
  • DUF number: 2.16.578.1.12.4.1.4.5
XML-example
(with ebRIM)		 
<rim:Slot name="sourcePatientId">
<rim:ValueList>
<rim:Value>
15076500565^^^&2.16.578.1.12.4.1.4.1&ISO
</rim:Value>
</rim:ValueList>
</rim:Slot>

sourcePatientInfo

Attribute name sourcePatientInfo
Description and usage Demographic data of the patient in effect at the time the document was registered in the repository. The information should not be updated after the document has been registered.
Information must be registered about:

  • First name

  • Surname

  • Middle name (if it exists)

  • Birthdate

  • Gender From the IHE specification:
    sourcePatientInfo should not include values for PID-2 (patient id), PID-4 (alternate patient id), PID-12 (country code), or PID-19 (social security number).

Required/
optional		 DocumentEntry R
SubmissionSet -
Data source HM (messages that use Head Message), HCP (messages that use the HealthCareProfessional structure) and CDA.
Datatype PID (Patient Identification)
CodeSystem/
specification		 Coded as an ebRIM slot. The maximum length is 256 characters.
The attribute should have values for:

  • PID-5 (source patient name)

  • PID-7 (source patient date of birth)

  • PID-8 (source patient gender) PID-8 can have the following values:

  • M – Male

  • F – Female

  • O – Other

  • U – Unknown

    • XML-example
    (with ebRIM)    		 Sample data:
    First name = Roland
    Middle name = Arne
    Last name = Gundersen
    DOB: 15.7.1965
    Gender: Male 
    <rim:Slot name="sourcePatientInfo">
<rim:ValueList>
<rim:Value>PID-5|GundersenRolandArne^^^</rim:Value>
<rim:Value>PID-7|19650715</rim:Value>
<rim:Value>PID-8|M</rim:Value>
</rim:ValueList>
</rim:Slot>

    submissionTime

    Attribute name submissionTime
    Description and usage The time when the submission set was submitted. Must be given by the source system.
    Required/
    optional    		 DocumentEntry -
    SubmissionSet R
    Data source IA (not specified). Each actor must decide for themself where this information can be obtained from.
    Datatype DTM, HL7 V2.5 Date Time
    CodeSystem/
    specification    		 Coded as an ebRIM Slot. The maximum length is 256 characters.
    XML-example
    (with ebRIM)    		 Time: 26 October 2015, at 16:30:00: 
    <rim:Slot name="submissionTime"> 
    <rim:ValueList> 
        <rim:Value>20151026163000</rim:Value> 
    </rim:ValueList> 
</rim:Slot>

    title

    Attribute name title
    Description and usage Describes the title of the document.
    Required/
    optional    		 DocumentEntry O
    SubmissionSet O
    Data source HM (messages that use Head Message), HCP (messages that use the HealthCareProfessional structure) and CDA.<
    Datatype String
    CodeSystem/
    specification    		 The maximum length is 128 characters.
    Title is specified in ebXML using the value attribute in the LocalizesString element.
    XML-example
    (with ebRIM)    		 
    <rim:ExtrinsicObject     
    id="ExampleDocument" 
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
    mimeType="text/xml"> 
    <rim:Name> 
        <rim:LocalizedString value="Operasjonsnotat for 15076500565"/>
    </rim:Name> 
[...] 
</rim:ExtrinsicObject>

    typeCode

    Attribute name typeCode
    Description and usage The typeCode attribute should describe which document group the document belongs to at a granular level.
    This attribute must be seen in conjunction with the classCode attribute, which is intended to describe the type of document at a more general level.
    Required/
    optional    		 DocumentEntry R
    SubmissionSet -
    Data source IA (not specified). Each actor must decide for themself where this information can be obtained from.
    Datatype Code
    CodeSystem/
    specification    		 ClassificationScheme should always have the value: urn:uuid:f0306f51-975f-434e-a61c-c59651d33983

    Coded as an ebRIM classification.

    Coding systems for document types to be used in the classCode and typeCode attributes are described in Volven 9602.
    Level 2 codes should be used (codes ending in "-2") in the typeCode attribute.
    OID: 2.16.578.1.12.4.1.1.9602
    XML-example
    (with ebRIM)    		 code = "A03-2"
    displayValue = "Epikrise"
    Coding system = "2.16.578.1.12.4.1.1.9602"
    <rim:Classification 
    classificationScheme="urn:uuid:f0306f51-975f-434ea61c-c59651d33983"  
    classifiedObject="EksempelEpikrise"
    nodeRepresentation=" A03-2"
    id="IdExample_053"  
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"> 
    <rim:Name> 
        <rim:LocalizedString value="Epikrise"/> 
    </rim:Name> 
    <rim:Slot name="codingScheme"> 
        <rim:ValueList> 
            <rim:Value>2.16.578.1.12.4.1.1.9602</rim:Value> 
        </rim:ValueList> 
    </rim:Slot> 
</rim:Classification>

    uniqueId

    Attribute name uniqueId
    Description and usage Unique ID of the document set by the person or system who generated the document.
    Required/
    optional    		 DocumentEntry R
    SubmissionSet R
    Data source HM (messages that use Head Message), HCP (messages that use the HealthCareProfessional structure) and CDA.
    Datatype Identifier
    CodeSystem/
    specification    		 Taken from IHE ITI TF-3:
    Document creators should use OIDs in dot notation (see OID in Table 4.2.3.1.7-2) as uniqueIds, with the following exceptions:
    For documents using HL7v3 Instance Identifiers (e.g., CDAs) with an extension attribute, the uniqueId should be a serialization of the root and extension attributes in the form root^extension.
    The example below shows the permitted use of CDA. UUID can also be used.
    Encoded as an ebRIM ExternalIdentifier
    XML-example
    (with ebRIM)    		 
    <rim:ExternalIdentifier
    id="urn:uuid:e8281697-86d0-40a6-8edd-201cd360fe3b"
    objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:ExternalIdentifier"
    registryObject="urn:uuid:103d9e5d-0000-0000-0000-000000000000"  
    identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"  
    value="^272473693">
    <rim:Name>
        <rim:LocalizedString value="XDSDocumentEntry.uniqueId"/>  	
    </rim:Name> 
</rim:ExternalIdentifier>

    URI

    Attribute name URI
    Description and usage URI for where the XDS document can be retrieved.
    When used in the Register Document Set transaction, this contains the URI of the XDS Document to be used for retrieval.
    Required/
    optional    		 DocumentEntry R2
    SubmissionSet -
    Data source AUT: Metadata that is automatically generated or assigned by either XDS registry or XDS repository.
    Datatype URI
    CodeSystem/
    specification    		 Coded as an ebRIM slot.
    XML-example
    (with ebRIM)    		 
    <rim:Slot name="URI"> 
    <rim:ValueList> 
        <rim:Value>DOC001.XML</rim:Value> 
    </rim:ValueList> 
</rim:Slot>

    Søk i Utviklerportalen

    Søket er fullført!