Classification : public 1 / 100
HIS Interoperability Framework
Service Layer
Document Sharing Module
Document IdentificationReference HIS-IF-Service_Layer-Document_Sharing_Module_v1.1.0
Date Created 06/03/2009
Date Modified 17/11/2010
Author ASIP Santé-PRAS
Version V 1.1.0
Page count 100
Reference Documents
[1] IHE International: IT Infrastructure Technical Framework rev. 7.0 volumes 1, 2a, 2b et 3 [2] Obsolete Reference
[3] IHE France: PAM – National Extension France v2.3, October 13 2010
[4] IHE France: Constraints on HL7 v2.5 data types that apply to the IHE IT Infrastructure Technical Framework within the scope of IHE France v1.3
[5] ASIP Santé: HIS Interoperability Framework – Document Metadata Nomenclatures Appendix [6] ASIP Santé: HIS Interoperability Framework – CDA Header and Metadata linkages Appendix [7] ASIP Santé: HIS Interoperability Framework – Cross-functional appendix of data sources for
Document Change History
Version Date Action
0.0.1 25/06/2009 Initial publication for public review
0.0.2 08/09/2009 Integration of comments from the first phase of public review, publication for validation session on September 14 and 15
0.0.3 28/09/2009 Integration of comments post expert session on September 14 and 15 0.1.0 02/10/2009 Publication post approval by industry stakeholders
0.1.1 24/02/2010 Minor spelling corrections.
Publication as part of version 0.1.1 if the HIS-IF
0.1.2 15/06/2010
authorInstitution is empty for documents submitted by the patient. There may be multiple author attributes, as in the XDS.b profile. This is most notable useful for the multi-disciplinary coordination meeting summary
0.2.0 05/07/2010 Integration of comments and lessons learned
0.2.0.1 27/08/2010
Target system defines the level and type of XAdES signature that must be implemented based on its security policy.
submissionTime corresponds to the date and time that the submission set was sent .
Specification of document status, submissions sets and folders confidentialityCode: addition of an explanation that the target system must define the management rules that will be used with the masking and non visibility function
1.0.0 08/11/2010
Clarification: date and time must be in Coordinated Universal Time (UTC) in conformance with the XDS.b profile
Component 7 (INS-C computation date) for patientId and sourcePatientId set to "required if known"
Addition of reference to the cross-functional appendix specifying the source of the professional data for people and organizations
Removal of all patient created documents from the specification of authorInstitution components. In this case, the metadata is left empty Publication post approval by vendor stakeholders
1.0.1 16/11/2010
References: Update to using version 1.3 of the "Constraints on HL7 v2.5 data types that apply to the IHE IT Infrastructure Technical Framework within the scope of IHE France v1.3" document
Clarification that there are no additional checks required when implementing authorRole on target systems
Update references to refer to rev. 7.0 of the IHE Technical Framework XDS profile check for eventCodeListDisplayName removed from this reference framework
Integration of the formatCodeDisplayName metadata (added by the IHE ITI Technical Framework rev. 7.0)
Editorial corrections
1.0.2 21/12/10
patientId component 7: correction of a Optionality typo in § 3.4.23.5.5 Clarification on what is meant by "missing" metadata in § 3.4.1.1 and the table in § 4.2.2
§3.4.2.6 : Correction of example 2 for the authorPerson metadata 11/03/11 Revision of sections that include sourcePatientId and sourcePatientInfo 14/03/11 Correction of the & character stringto the & symbol in examples
when it does not appear as part of an XML message example. 4/05/11 Editorial correction of examples: § 3.4.21.5.1, § 3.4.2.5.1, § 3.4.2.6,
Document Change History
Version Date Action
Correction of sample RPPS independent practice identifiers to be 15 integers in § 3.4.1.5, §3.4.1.6 and §3.4.5.4 (example 1)
01/09/11 Integration of XDS concepts Integration of lessons learned
Table of Contents
1 Positioning within the Interoperability Framework ... 6
2 Pre-requisites ... 7
3 Specifications ... 8
3.1 Concepts and Underlying Standards... 8
3.1.1 References ... 8
3.1.2 Concepts ... 8
3.2 Optional Functionality ... 12
3.3 Transactions ... 13
3.3.1 Provide & Register Document Set-b ITI-41 ... 13
3.3.2 Stored Query ITI-18 ... 20
3.3.3 Retrieve document set ITI-43 ... 21
3.3.4 Distribute document set on media ITI-32 ... 22
3.3.5 Update document set ITI-57 ... 23
3.3.6 Declaration of a patient identity ... 33
3.4 XDS metadata of a document entry ... 35
3.4.1 authorInstitution ... 35 3.4.2 authorPerson ... 37 3.4.3 authorRole ... 42 3.4.4 authorSpecialty ... 42 3.4.5 author ... 35 3.4.6 availabilityStatus ... 46 3.4.7 classCode ... 47 3.4.8 classCodeDisplayName ... 47 3.4.9 comments ... 48 3.4.10 confidentialityCode ... 48 3.4.11 creationTime ... 50 3.4.12 entryUUID ... 50 3.4.13 eventCodeList ... 51 3.4.14 eventCodeListDisplayName ... 52 3.4.15 formatCode ... 53 3.4.16 formatCodeDisplayName ... 53 3.4.17 hash ... 54 3.4.18 healthcareFacilityTypeCode ... 54 3.4.19 healthcareFacilityTypeCodeDisplayName ... 55 3.4.20 languageCode ... 56 3.4.21 legalAuthenticator ... 56 3.4.22 mimeType ... 60 3.4.23 patientId ... 60 3.4.24 practiceSettingCode ... 62 3.4.25 practiceSettingCodeDisplayName ... 62 3.4.26 serviceStartTime ... 63 3.4.27 serviceStopTime ... 64 3.4.28 size ... 65 3.4.29 sourcePatientId ... 65 3.4.30 sourcePatientInfo ... 67 3.4.31 title ... 69 3.4.32 typeCode ... 70 3.4.33 typeCodeDisplayName ... 70 3.4.34 uniqueId ... 71 3.4.35 URI ... 72 3.4.36 repositoryUniqueId... 73 3.4.37 homeCommunityId... 73 3.4.38 documentAvailability ... 74
3.4.39 logicalID ... 74
3.4.40 version ... 75
3.5 XDS Metadata of a Submission Set ... 76
3.5.1 authorInstitution ... 76 3.5.2 authorPerson ... 76 3.5.3 authorRole ... 77 3.5.4 authorSpecialty ... 77 3.5.5 author ... 78 3.5.6 availabilityStatus ... 78 3.5.7 comments ... 79 3.5.8 contentTypeCode ... 79 3.5.9 contentTypeCodeDisplayName ... 80 3.5.10 entryUUID ... 80 3.5.11 intendedRecipient ... 81 3.5.12 patientId ... 81 3.5.13 sourceId ... 81 3.5.14 submissionTime ... 82 3.5.15 title ... 82 3.5.16 uniqueId ... 83 3.5.17 homeCommunityId... 83 3.6 XDS Metadata of a Folder ... 85 3.6.1 availabilityStatus ... 85 3.6.2 codeList ... 85 3.6.3 codeListDisplayName ... 86 3.6.4 comments ... 86 3.6.5 entryUUID ... 86 3.6.6 lastUpdateTime ... 87 3.6.7 patientId ... 87 3.6.8 title ... 88 3.6.9 uniqueId ... 88 3.6.10 homeCommunityId... 89 3.7 Summary Tables ... 90
3.7.1 XDS Metadata Attribute Enforcement ... 90
3.7.2 Optionality and Cardinality ... 92
3.7.3 Population of XDS Metadata from the CDA Document ... 95
4 Security Considerations ... 96
4.1 Access Permissions ... 96
4.2 Non-Repudiation ... 96
4.2.1 Non-Repudiation of Document Content ... 96
4.2.2 Non-repudiation of Document Submission ... 97
4.3 Integrity ... 99
4.3.1 Document Content Integrity ... 99
1 Positioning within the Interoperability Framework
This module specifies the Service layer for: A target system that stores, indexes and makes available personal health information;
An initiating system that provides documents to the target system, either creating or updating the documents;
An initiating system that accesses these documents, querying and retrieving the documents from a target system.
The implementation of this module requires the implementation of the transport layer module:
HIS Interoperability Framework – Transport Layer - Synchronous Transport module.
The implementation of this module also requires the implementation of the service layer module that defines electronic health record (EHR) management:
HIS Interoperability Framework –Service Layer – Patient/Electronic Health Record Sharing module.
This module is in turn used by several content layer modules. Note:
This module is based on the assumption that patient created documents are managed within the same infrastructure as healthcare professional created documents. Alternate methods are not excluded; such as the management of patient created documents within another infrastructure, and/or other modalities.
2 Pre-requisites
All HIS implementers in France are subject to the following legislation:
la loi n° 78-17 du 6 janvier 1978 modifiée relative à l'informatique, aux fichiers et aux libertés,
l’article L. 1111-8 du code de la santé publique inséré par la loi n° 2002-303 du 4 mars 2002 pour les traitements d'hébergement tels que définis dans cet article : dépôt, conservation et restitution des données de santé à caractère personnel.
Additionally, in order to be conformant with this module, initiating systems must be able to rely on a signature certificate from the CPS-PKI, with the possible exception of the initiating system that produces patient created documents.
3 Specifications
3.1 Concepts and Underlying Standards
3.1.1
References
Healthcare document sharing, which includes storage, indexing and making available, uses ebXML Registry Information Model (ebRIM) and ebXML Registry Service (ebRS) standards as specified in the IHE Cross-Enterprise Document Sharing (XDS.b), Cross-Enterprise Document Media Interchange (XDM) and XDS Metadata Update (MU) profiles.
The following is a list of all the documents used: ebRIM :
http://www.oasis-open.org/committees/regrep/documents/3.0/specs/regrep-rim-3.0-os.pdf ebRS :
http://www.oasis-open.org/committees/regrep/documents/3.0/specs/regrep-rs-3.0-os.pdf IHE ITI Technical Framework: http://www.ihe.net/Technical_Framework/index.cfm#IT
XDS.b :
o Volume 1, Chapter 10
o Volume 2a, Chapter 3.18
o Volume 2b, Chapters 3.41 and 3.42
o Volume 3, Chapter 4
XDM :
o Volume 1, Chapter 16
o Volume 2b, Chapter 3.32 IHE ITI Technical Framework Supplements:
MU DSG XAdES : http://uri.etsi.org/01903/v1.1.1/ http://www.w3.org/TR/XAdES
3.1.2
Concepts
XDS.b (Cross-Enterprise Document Sharing) is an IHE infrastructure profile that constrains the OASIS ebXML RegRep 3.0 standard in order to build document sharing management systems and expose them through web services.
This profile applies to shared health information systems in France, especially the DMP. The French implementation uses the carte vitale1 as the patient identity source for patients who have health insurance, and focuses the sharing infrastructure on two of the XDS.b profile actors: the Document Repository and Document Registry.
1
Health Information Systems that use this infrastructure implement the profile's other actors: Document Source, Document Consumer or Document Administrator depending on which transactions they need to implement.
XDS.b is part of the XD* group of IHE profiles that describe document sharing. The other XD* profiles are:
Cross-enterprise Document Reliable Interchange (XDR), using web services to send a document and its metadata;
Cross-enterprise Document Media (XDM), using email or digital media (e.g. CDs or USB keys) to send a document and its metadata;
Cross-Community Access (XCA), query and retrieval of a patient's healthcare data from other communities;
Multi-Patient Query (MPQ), query sent to a registry containing multiple patient identifiers.
3.1.2.1
XDS.b Profile Actors
3.1.2.1.1 Document Repository
A document repository stores documents in no particular order or hierarchy, and in a way that is transparent, secure, reliable and persistent. The document repository responds to requests for document retrieval, where retrieval means a downloading of a copy of the document.
3.1.2.1.2 Document Registry
The document registry contains information that enables indexing of the documents stored in the document repository, and responds to the document consumer's requests.
The information describing the documents is called metadata. Metadata helps to classify documents and make them easier to retrieve. The document registry stores and manipulates objects relating to four concepts: the document entry, folder, submission set, as well as the associations between document entry, folder and submission set.
3.1.2.1.3 Document Source
A document source is a system that is responsible for sending documents to a document repository, and registering those documents. The document source provides the document and its metadata to the repository. The metadata is required for registering the document in the registry as one of the next steps in the sequence.
The document source can also replace documents when their content is updated, or if there has been a submission error.
3.1.2.1.4 Document Consumer
A document consumer is a system that looks up documents on the document registry, and then selects the desired documents out of the ones available to download from the document repository. 3.1.2.1.5 Document Administrator
A document administrator is a system that manages the update of document metadata in the document registry.
3.1.2.1.6 XDS.b Actors and Transactions diagram
Figure 1 identifies the XDS.b profile actors used in France, as well as the transactions implemented between each actor.
Document Registry Document Consumer Document Repository Document Source Document Administrator
Update Document Set [ITI-57]
Provide&Register Document Set – b [ITI-41]
Retrieve Document Set [ITI-43]
Registry Stored Query [ITI-18]
Register Document Set – b [ITI-42]
Figure 1: XDS.b Actors and Transactions
3.1.2.2
Document Sharing Objects
3.1.2.2.1 DocumentA document is the smallest unit of information deposited in a document repository by a document source. Once stored in the document repository with a unique ID, the document can no longer be modified.
3.1.2.2.2 Document Entry
A document entry belongs to a registry and identifies the document stored in the document repository. The document entry contains the metadata describing the principal characteristics of a document stored in the document repository. The metadata includes a uniqueId data element that enables the document to be retrieved.
3.1.2.2.3 Folder
An XDS folder is a registry element that constitutes a virtual assembly of document entries grouped into categories such as: an episode of care, vaccinations, a care team, a clinical specialty, or a patient's health status over a set range of time. The same document entry may be associated with zero to many folders.
This collaborative mechanism offers document sources the ability to associate documents, via their document entry, into categories. It also offers document consumers a method to find document entries associated with the same folder and therefore all documents relevant to the same category. Folders cannot be nested, therefore associations of type "HasMember" between folders are not allowed. A folder is described by a group of attributes, i.e. its metadata.
This document specifies the implementation of the folder concept as described by the XDS.b profile, without expectations about how it will be adopted in France (with or without restrictions). Since the concept has not yet been used in a shared health information system in any country, the decision as to whether or not to rely on the concept of folders for shared health information systems in France is out of scope for this document.
3.1.2.2.4 Submission set
A submission set is a registry element that groups the document entries and folders that are part of the same submission, and attests to the submission status.
A submission set is described by a group of attributes i.e. its metadata. Once created, a submission set and its metadata are immutable.
3.1.2.2.5 Associations
The registry facilitates the creation and management of associations between different objects. These associations are described in the examples in section 3.3 of this document.
3.1.2.3
Metadata
Each of the following objects: Document entry, Folder, Submission Set and Association possess a set of attributes called metadata. These metadata are used to index, manage, find and classify documents.
3.2 Optional Functionality
This module describes the following optional functionality as national extensions of the XDS.b profile:
Masking and unmasking a document so that healthcare professionals have access to them or not depending on the rules defined by the affinity domain;
Making a document no longer visible from patient view, called "non-visibility" for the purposes of this document;
Depublishing, or depublication of a document, in other words, making it inaccessible while it is still stored in the document repository; this is a non-reversible operation,
Functionally archiving a document, i.e. making the document accessible only by queries specific to archived documents. This is a reversible operation.
The implementation of the above functionalities into a target system depends on its legal and professional context.
3.3 Transactions
This section describes the transactions used for the storage and provision of healthcare documents. These transactions use the concept of the XDS submission.
XDS Submission
An XDS submission is a suite of operations that transfer a group of information to the document registry and/or repository. All submissions must be considered as a finite action, where the result is the successful update of either the document registry, or the document registry and the document repository.
All XDS submissions must be atomic. This means that the set of operations that constitute a submission are indivisible. In the event of a failure of one of the operations involved in a submission, the entire submissions must be rolled back regardless of how many of the operations of that submission have already succeeded.
There are two usage scenarios for an XDS submission:
The submission of documents to a document repository, using the Provide and Register Document set-b [ITI-41] transaction, followed by the submission of the metadata for the documents to the document registry using the Register Document Set-b [ITI-42] transaction;
The submission of updated metadata directly to the document registry using the Update document set [ITI-57] transaction.
3.3.1
Provide & Register Document Set-b ITI-41
The Provide & Register Document Set-b ITI-41 transaction makes a set of documents available. The transaction enables an initiating system to send documents and metadata to a target system so that the target system can store and index them. This transaction uses synchronous transport. For more information, please refer to the Synchronous Transport Layer module of the HIS-IF.
HIS Component IHE Actor
Initiating System Document Source
Target System Document Repository
This transaction is followed by the Register Document Set-b [ITI-42] transaction for the submission of the metadata of these documents to the registry, as described in section 3.3.1.2.
3.3.1.1
General Functionality
The submission to the document repository is composed of the following elements:
A message based on an ebXML request SubmitObjectsRequest containing the following objects:
o A submission set containing the metadata relative to the submission;
o Zero to many folders;
o Zero to many document entries; where each document entry contains the metadata for a document to be sent to the document repository. One of the document entries will be the document entry containing the submission set digital signature;
o One to many associations between the submission set and the document entries; the submission set is linked to each document entry to be sent as well as to zero to many document entries previously registered in the document registry;
o Zero to many RPLC associations between document entries; each RPLC association identifies the replacement of an existing document by a new version of the same
document; XFRM, XFRM_RPLC (transformation/replacement) and APND (addendum) associations are not allowed;
o An association between the submission set and any new folder created by this set;
o One to many association pairs; Where one to many document entries are associated with one to many folders; each association pair is formed:
By an association linking the folder and document entry to be associated (folder-document entry association),
By an association linking the submission set and the folder-document entry association;
Zero to many documents to be stored in the document repository, including the submission set's digital signature document.
When the submission is received under normal conditions and without any transaction errors, the document repository performs the following actions:
1. Calculating the size of the document and the hash, and verifying the results with the size and hash metadata of the document entry for the document provided by the document source; 2. Checking the uniqueness of the uniqueId document metadata;
3. Adding the document repository's global ID: repositoryUniqueId metadata to the document entry;
4. Storing the document without modification, along with its uniqueId that is used to index the document;
5. Transferring the amended set of metadata to the document registry.
The submission set objects, as well as their registry and repository representations are described in section 3.3.1.3.
3.3.1.2
Register Document Set-b ITI-42 (Document Registry Submission)
This transaction is internal to the target system, and is based on the ebXML SubmitObjectsRequest transaction. The submission to the registry is composed of the Register Document Set-b Request message, and contains the set of metadata amended by the document repository.
In the normal scenario when the Register Document Set-b ITI-42 transaction is received, the document registry validates the metadata's presence, format and content. It also validates that the patient identifier patientId was declared prior to submission, then saves the metadata and makes whatever changes are required to the submitted object such as the creation of new associations, or the availabilityStatus metadata update.
3.3.1.3
Submission Set Objects and their Representation in the Document Registry
and Document Repository
3.3.1.3.1 Association between a Submission Set and a Document Entry
Once submitted, document entries are associated with a submission set using one of the following two methods:
Inclusion by value: the submission set is linked to the document entry for each new document sent to the document repository by the HasMember association, where the SubmissionSetStatus attribute is set to "Original";
Inclusion by reference: the submission set is linked to the document entry for a document already stored in the document repository that the document source wants to have associated. The HasMember association links the document entry and submission set, where the SubmissionSetStatus attribute is set to "Reference".
The submission set, as well as any document entries included must all be related to the same patientId. This is a restriction imposed on XDS.b specifications in France.
The association concept is illustrated by the following example:
1. Submission 01 submits a new document, document A (uniqueId = 1.1.1.1) to the document repository.
The following elements are generated in the document registry as illustrated in Figure 2 below:
Submission set 01,
Document A entry, and
The "HasMember" association (with value set to Original) between submission set 01 and document A entry.
Figure 2: Submission 01 of a new document A
2. Submission 02 submits a new document, document B (uniqueId = 2.2.2.2) to the document repository; registers document B entry, and also references document A entry,which the document source wants to associate with submission set 02.
The following elements are generated in the document registry as illustrated in Figure 2 below:
Submission set 02,
Document B entry,
The "HasMember" association (with value set to Original) between submission set 02, and document B entry, as well as
The "HasMember" association (with value set to Reference) between submission set 02 and document A entry.
Original HasMember Document A: Document A entry: Submission set 01: uniqueId=1.1.1.1 uniqueId=1.1.1.1
Figure 3: Submission 02 of a new document B and a reference to document A
3.3.1.3.2 Association between a Submission Set and a Folder Use case: Creation of a folder in a shared patient electronic health record
The submission set includes the folders that it has created. In other words, folders are not submitted by reference the way documents are. The submission set is linked to the folder by the "HasMember association" as illustrated in Figure 4 below. The document registry initializes the lastUpdateTime metadata for the folder with the date and time of its creation.
Figure 4: Creation of folder X1 by submission set 10
HasMember Folder X1: Submission set 10: Document Repository Document Registry Original HasMember HasMember Original HasMember Reference Document B: Document B entry: Submission set 02: Document A: Document A entry: Submission set 01: uniqueId=2.2.2.2 uniqueId=2.2.2.2 uniqueId=1.1.1.1 uniqueId=1.1.1.1 Document Repository Document Registry
3.3.1.3.3 Association Pairs [folder-document entry, submission set-folder association-document entry]
Use case: Association of a document with a folder
If a document entry must be associated with a folder, then the following association pairs are submitted:
A "HasMember" association between the folder and the document entry. For the rest of the explanations in this document, this association will be referred to as the folder-document entry association;
A "HasMember" association between the submission set and the folder-document entry association; this association identifies the document source that associated the document entry with the folder.
A folder and the associated document entries are all related to the same patientId.
For each transaction that associates or dissociates a document entry to/from a folder, the registry updates the lastUpdateTime metadata of the folder with the date and time of the transaction.
In the example illustrated in Figure 5 below, folder X1, as well as document A and document B entries exist in the registry, corresponding to documents A and B in the document repository. The example demonstrates two successive submissions of folder-document entry associations between folder X1 and document A and B entries.
Figure 5: Association of two document entries to a folder in two successive submissions
3.3.1.3.4 RPLC Association representing the update of an existing document Use case: Replacing a document with a new version
A submission may comprise the update of an existing document. The new version of the document is sent to the document repository without affecting the previous version which persists.
The submission set is linked to the document submitted to the document repository by the HasMember association, where the SubmissionSetStatus attribute is set to Original.
The RPLC replace association links the document entry of the new version of the document to the document entry for the previous version of the document. This association is part of the submission. This update is only possible for an existing document entry where the value of the availabilityStatus metadata is set to Approved or Archived, because only the most recent version of a document can be updated. HasMember HasMember HasMember HasMember Document B: Document A: Document B entry Entry: Submission set 30: Folder X1: Document A entry: Submission set 20: uniqueId=1.1.1.1 uniqueId=3.3.3.3 uniqueId=1.1.1.1 DocumentRepository Document Registry uniqueId =3.3.3.3
If the submission is successful:
1. The availabilityStatus metadata for the document entry of the new version of the document will be set to "Approved" or "Archived" based on the metadata for the document entry of the previous version of the document.
2. The availabilityStatus metadata of the document entry of the previous version of the document will be set to "Deprecated".
After a series of updates, the document version history will remain accessible to the document consumer via the RPLC association. See Figure 7 and Figure 8 for details.
The RPLC association between document entries is illustrated by the example below:
Document A1 is submitted to the document repository and its submission set and document entry are registered in the document registry. The document entry metadata availabilityStatus is set to "Approved" as illustrated in Figure 6 below.
Figure 6: Submission of document A1
A submission sends a new version A2 of document A1. A2 is therefore submitted and stored in the document repository without affecting document A1.
Submission set 20 is linked to document A2 entry by the HasMember association, where the SubmissionSetStatus attribute is set to the value "Original". A replace RPLC association links the document A2 entry to the document A1 entry.
The availabilityStatus metadata for the document A2 entry is set to "Approved" and the availabilityStatus metadata for the document A1 entry is set to "Deprecated" as illustrated in Figure 7 below.
Figure 7: Submission of document A2, the new version of document A1
Original HasMember Originall HasMember RPLC Document A2: Document A2 Entry: Submission Set 20:
Document A1 Entry: Document A1:
Submission Set 10: uniqueId=2.2.2.2 availabilityStatus =Approved uniqueId=2.2.2.2 availabilityStatus=Deprecated uniqueId=1.1.1.1 uniqueId=1.1.1.1 Document Repository Document Registry Original
HasMember Document A1 entry: Document A1:
Submission Set 10:
availabilityStatus=Approved
uniqueId=1.1.1.1 uniqueId=1.1.1.1
Document Repository Document Registry
A new submission sends the A3 update to document A2. A3 is stored in the document repository without affecting document A2. This additional iteration is illustrated in Figure 8 below.
Figure 8: Submission of document A3, the new version of document A2
3.3.1.3.5 Update of an existing document associated with a folder Use case: Replacing a document associated with a folder
A document to be updated is associated with one to many folders as illustrated in Figure 9 below. In the example, document A1 is sent to the document repository and the document entry is associated to folder X1, which is already present in the document registry.
Figure 9: Submission of document A1 where the document entry is associated to folder X1
When the submission of the new version of an existing document is successful as illustrated later in Figure 10, the following associations are created in the document registry:
Associations present in the submission:
o A HasMember association between the submission set and the document entry for the new version of the document, where the submissionSetStatus attribute is set to the value "Original";
o An RPLC association between the document entry for the new version of the document and the document entry for the previous version of the document;
The HasMember association, automatically generated by the document registry between the folder associated with the document entry for the previous document, and the document entry
HasMember
Original HasMember
HasMember Document A1 Entry: Document A1: Folder X1: Submission Set 10: uniqueId=1.1.1.1 uniqueId=1.1.1.1 availabilityStatus=Approved Document Repository Document Registry RPLC Original HasMember HasMember Original HasMember Original RPLC Document A3: Document A3 Entry: Submission Set 30: Document A2: Document A2 Entry: Submission Set 20: Document A1: Document A1 Entry: Submission Set 10: uniqueId =3.3.3.3 availabilityStatus=ApproveduniqueId=3.3.3.3 uniqueId=2.2.2.2 2 availabilityStatus =Deprecated uniqueId=2.2.2.2 uniqueId=1.1.1.1 availabilityStatus=Deprecated uniqueId=1.1.1.1 Document Repository Document Registry
for the new version of the document. This association is highlighted in red text in Figure 10 below.
The document registry updates the folder's lastUpdateTime metadata with the date and time of the association transaction that associated the document entry and the folder.
`
Figure 10: Document A2 update to document A1 where the document entry is associated to folder X1
3.3.2
Stored Query ITI-18
The Stored Query ITI-18 transaction permits an initiating system to run metadata searches on documents indexed by a target system.
The following table shows the mapping between the component systems of the Health Information Systems Interoperability Framework, and the IHE Actors that participate in the IHE ITI-18 Store Query Transaction.
HIS Component IHE Actor
Initiating system Document Consumer Target system Document Registry
3.3.2.1
General Functionality
The initiating system executes a predefined, or stored, request to the target system by providing the required search criteria values: document metadata, submission set metadata, folder metadata. The target system executes the query and responds with a list of the objects that match the search criteria, i.e. documents, submissions sets, folders and related associations. This list usually consists of:
references, if ObjectRef mode is invoked;
references with their metadata, if LeafClass mode is invoked. The list may potentially be empty.
The initiating system uses the request results to access the documents stored in the document repository. For more information, see the Retrieve Document Set transaction in Section 3.3.3 below.
RPLC HasMember HasMember Original HasMember HasMember Original HasMember Document A2: Document A2 Entry: Submission Set 20: Document A1: Folder X1: Document A1 Entry:
Submission Set 10: uniqueId =2.2.2.2 availabilityStatus=Approved uniqueId=2.2.2.2 uniqueId=1.1.1.1 availabilityStatus=Deprecated uniqueId=1.1.1.1 Document Repository Document Registry
3.3.2.2
Target System Behavior
Depending on the implemented functionality, the target system may exhibit specific behavior when responding to a stored request. These behaviors are described below by functionality. When several functions are implemented, the behavior of the target system is described as the sum of the specific behaviors of each function.
3.3.2.2.1 Implementation of Access permissions
The response to a stored query transaction must contain only elements that reference documents that the initiating system user has the appropriate permissions to access. No other documents may be shown to the user. The user's identity is transmitted by the VIHF token, as described in the transport layer module.
Therefore the response to a stored query may only contain:
Document entries that relate to documents for which the user has the correct permissions to access;
Submission sets that contain at least one document, for which the user has the correct permissions to access;
Folders that containing at least one document, for which the user has the correct permissions to access;
Associations that relate to documents for which the user has the correct permissions to access.
3.3.2.2.2 Implementation of Masking and Non visibility
The response to a stored query must only contain elements that reference documents that are accessible to the initiating system user, as identified in the VIHF token.
Therefore, the response to a stored request must not contain:
Any document entry relating to a document that is not accessible to the user;
Any submission set that only contains documents not accessible to the user;
Any folder that only contains documents that are not accessible to the user;
Any association relating to a document that is not accessible to the user. 3.3.2.2.3 Implementation of Depublication
The response to a stored query must only contain elements that reference documents that have not been depublished2.
Therefore, the response to a stored query must not contain:
Any document entry that relates to an unpublished document;
Any submission set that contains only unpublished documents;
Any folder that contains only unpublished documents;
Any association that relates to an unpublished document. 3.3.2.2.4 Combination of several functions
When several functions, i.e: access permissions, masking, non-visibility, and unpublishing are implemented, the access restrictions on submission sets and folders are combined.
3.3.3
Retrieve document set ITI-43
The Retrieve document set ITI-43 transaction permits an initiating system to retrieve documents that are stored by a target system.
2
Depublication is a term used to describe documents in the document repository that are no longer accessible to users.
HIS Component IHE Actor
Initiating system Document Consumer Target system Document Repository
3.3.3.1
General Functionality
The initiating system transmits the list of document references resulting from the stored query to the target system for retrieval.
The target system returns the referenced documents.
3.3.3.2
Target System behavior
Depending on the implemented functionality, the target system may exhibit specific behavior when responding to a retrieve document set transaction. These behaviors are described below by functionality. When several functions are implemented, the behavior of the target system is described as the sum of the specific behaviors of each function.
3.3.3.2.1 Implementation of Access permissions
The response to a retrieve document set transaction must only allow a document to be retrieved by initiating system users that have the appropriate access permissions, as identified by the VIHF token. Any retrieve document set transaction for a document that the user does not have the permissions to access must generate an error message.
3.3.3.2.2 Implementation of Masking and non visibility
The response to a retrieve document set transaction must not allow the retrieval of a document that is not accessible to the initiating system user, as identified in the VIHF token. Any retrieve document set transaction for a document not accessible to the user must generate an error message.
3.3.3.2.3 Implementation of Depublication
The response to a retrieve document set transaction must not allow the retrieval of an unpublished document. Any retrieve document set transaction for an unpublished document must generate the same error message as if the document UID was unknown.
3.3.4
Distribute document set on media ITI-32
The Distribute document set on media ITI-32 transaction is used by an initiating system to prepare a submission set and send it by email to a target system so that it can make the submission set content available to initiating systems.
Only document submission is possible by email, document retrieval can only be performed by the retrieve document set synchronous transaction.
HIS Component IHE Actor
Initiating system Portable Media Creator Target system Portable Media Importer
3.3.4.1
General Functionality
The Distribute document set on media transaction is a preliminary transaction for the provisioning of a document set using asynchronous email transport.
The transaction enables the initiating system to provide the documents and their associated metadata as attachments to an email, which is then sent to the target system. Upon receipt of the email, the target system uses the attachments to store the transmitted documents and index them as though they had been transmitted by the Provide & Register Document Set transaction.
An email submission must correspond to a unique submission set regarding a single patient. Multi-set submissions are not permitted and must generate a specific error message.
Document entries sent by email must be integrated into a hierarchical zip file attached to the email as specified in the IHE XDM profile. The hierarchical zip file as well as the XML files must use relative links such as "..\temp" rather than absolute links such as "c:\temp".
The zip file must contain:
One XML file containing the set of metadata for the submission that will be used by the target system to index the documents. The set of metadata includes:
o Submission set metadata in the <RegistryPackage> element,
o Document entries in the <ExtrinsicObjects> elements,
o New folders in the <ExtrinsicObjects> elements,
o Associations in the <Association> elements;
One XML file per document submitted as part of the submission set, and referenced in an <ExtrinsicObjects> element. The link between the document and the object is made via the URI metadata that is used exclusively in this case, and then deleted by the target system as soon as the target system updates its metadata before indexing them.
These files must be positioned in an IHE_XDM/SUBSET01 directory of the hierarchical zip file.
All other attachments as well as the body of the email must be ignored by the target system when the documents are being stored and the metadata are being indexed.
3.3.5
Update document set ITI-57
The Update Document Set ITI-57 transaction for updating metadata enables an initiating system to modify associated with a document in order to implement masking, non-visibility, archiving and unpublishing.
HIS Component IHE Actor
Initiating system Document administrator Target system Document Registry
3.3.5.1
General Functionality
This submission is composed of the Update Document Set Request message from the Update Document Set [ITI-57] transaction, which is based on the ebXML UpdateObjectsRequest transaction. In the IHE specification, a metadata update in the document registry is a basic operation that:
Replaces a document entry by a new version after its metadata has been updated,
Replaces a folder by a new version after its metadata has been updated,
Modifies the availabilityStatus metadata of a document entry,
Modifies the availabilityStatus metadata of a folder,
Modifies the availabilityStatus metadata of an association,
The document entry, folder, or document registry association metadata updates, have no impact on the related document or documents being submitted to the document repository.
A submission set is immutable as described in section 3.1.2.2.4. Submission set metadata is not allowed to be updated.
Version control for document entries and folders relies on two complementary metadata:
logicalID (called lid in the ebRIM 3.0 specification), an ID that remains the same regardless of the version of the document entry or folder;
version, version number for the document entry or folder, as assigned by the document registry. The first version of a document entry or folder is numbered version 1, and subsequent versions are incremented by 1. This metadata is returned in response to a query. These updates are only possible on the most recent version of a document entry or folder. If the submission is successful:
1. The availabilityStatus metadata for the new version of the document entry of the document or folder inherits the availabilityStatus of the previous version, either "Approved" or "Archived" for a document entry, and "Approved" for a folder;
2. The availabilityStatus metadata of the previous version of the document entry or folder is set to "Deprecated".
For a folder update, the document registry updates the lastUpdateTime metadata of the new version of the folder with the date and time of the transaction.
In order to maintain coherence between the document content and the XDS metadata, there is a restriction on XDS.b specifications in France that limit basic update transactions to modifying only the following metadata:
Replacing a document entry by a new version as a result of the update of the confidentialityCode metadata,
Modifying the availabilityStatus metadata of a document entry,
Modifying the availabilityStatus metadata of an association.
Reminder: the confidentialityCode metadata is only present on the document entry. It is not present on a folder.
3.3.5.1.1 Replacing a document entry by a new version as a result of the update of the confidentialityCodemetadata
Use case: Managing the masking and visibility of a document
The confidentialityCode metadata contains the information that defines the level of confidentiality of a document submitted to the document repository. The first occurrence of the metadata element is required and indicates the level of confidentiality of the CDA document. This first occurrenceis set to "N" for "normal", "R" for "restricted", or "V" for "very restricted" as defined by the CDA document. The two following occurrences are optional and define whether the document is masked to healthcare professionals and/or non-visible to the patient. Only this two optional occurrences may be updated. The Update Document Set Request message contains the metadata for the following objects:
A submission set containing the metadata for the submission;
Zero to many document entries, each document entry representing the new version of a document entry where the confidentialityCode metadata has been updated. The logicalID metadata must be present in each document entry that is submitted;
A HasMember association between the submission set and each new version of document entry that is submitted where the PreviousVersion attribute inherits the version metadata from the document entry to be updated.
When the document registry receives this message, it must: 1. Validate that:
The new version of the document entry that is submitted has the same logicalID and uniqueId as the version being replaced;
The value of the PreviousVersion attribute for the HasMember association linking the submission set to the new version of the document entry, is equal to the version number of the document entry to be replaced;
The availabilityStatus metadata for the document entry to be replaced is equal to "Approved" or "Archived".
2. Save the new version of the document entry in the document registry, and update the following metadata:
availabilityStatus: set to the value from the document entry being replaced: "Approved" or "Archived";
version: set to the value of the PreviousVersion attribute, incremented by 1.
3. Update the availabilityStatus metadata of the previous version of the document entry and set it to "Deprecated";
4. Propagate the update of the confidentialityCode to the latest version of the document entry for each version of the document. This propagation of the metadata update is a French constraint.
5. Propagate all the folder associations of the former document entry to the new document entry, as well as the document-to-document associations. I.e. the new document entry inherits all the associations of the previous document entry, except the one linking the document to the submission set.
The replacement of a document entry by a new version following the confidentialityCode metadata update is illustrated in the example below.
Figure 11 illustrates the starting scenario: two versions of the same document with document entries that are associated with a folder.
Figure 11: Starting scenario
Figure 12 illustrates the confidentialityCode metadata update by a second instance where the value is set to "MASQUE_PS".
Before making the update, the Stored Query [ITI-18] transaction located the ZZ document entry, which is the most up to date document entry for document A2. The metadata for ZZ document entry have the following values:
AvailabilityStatus = "Approved",
uniqueId = "2.2.2.2",
logicalID = "22-22-22-22".
The update of confidentialityCode is done by the submission of the A2-2 document entry, replacing the document ZZ entry associated with document A2. uniqueId and logicalID metadata of both document entries have the same value.
The document A2-2 entry is linked to submission set 30 by the HasMember association where the PreviousVersion attribute is set to "1", which is inherited from the version metadata of the document ZZ entry.
The availabilityStatus metadata for the document A2-2 entry inherits the original "Approved" value of the document ZZ entry. The availabilityStatus of the document ZZ entry is set to "Deprecated". The version metadata for the document A2-2 entry inherits the value of document ZZ entry version metadata, incremented by 1.
All the associations for the document ZZ entry, except its association with the submission set, are replicated to the document A2-2 entry, marked in red text in Figure 12 below.
The information contained in the confidentialityCode metadata for the document A2-2 entry is replicated to the confidentialityCode metadata for the document A1 entry.
HasMember Original HasMember HasMember Original HasMember HasMember RPLC Submission Set 20:
ZZ Document entry: Document A2:
Document A1:
Folder X1: Document A1 entry:
Submission Set 10: version=1 confidentialityCode=N availabilityStatus=Approved logicalID=22-22-22-22-22 entryUUID=22 -22-22-22-22 uniqueId=2.2.2.2 uniqueId =2.2.2.2 uniqueId=1.1.1.1 version=1 confidentialityCode=N availabilityStatus=Deprecated logicalID=11-11-11-11-11 entryUUID=11-11-11-11-11 uniqueId=1.1.1.1
Figure 12: confidentialityCode metadata update PreviousVersion=1 HasMember RPLC HasMember HasMember HasMember Original HasMember HasMember Original RPLC HasMember
A2-2 Document Entry:
Submission Set 30:
ZZ Document entry: Document A2:
Submission Set 20: Document A1: Document A1 entry: Folder X1: Submission Set 10: version=2 confidentialityCode=N, MASQUE_PS availabilityStatus=Approved logicalID=22-22-22-22-22 entryUUID=45-456-456-456-45 uniqueId=2.2.2.2 version=1 confidentialityCode=N availabilityStatus=Deprecated logicalID=22-22-22-22-22 entryUUID=22-22-22-22-22 uniqueId=2.2.2.2 uniqueId =2.2.2.2 uniqueId=1.1.1.1 version=1 confidentialityCode=N,MASQUE-PS availabilityStatus=Deprecated logicalID=11-11-11-11-11 entryUUID=11-11-11-11-11 uniqueId=1.1.1.1 Document Repository Document Registry
3.3.5.1.2 availabilityStatus metadata update for a document entry Use case: Archive management; document depublication
The availabilityStatus metadata identifies the relevance of the document entry to the user. The availabilityStatus metadata has the following possible values as described in appendix [5]: HIS-IF Document Metadata Nomenclatures Appendix:
"Approved" (Up-to-date version of the document entry for the updated version of the document),
"Deprecated" (Obsolete version),
"Archived" (Up-to-date version of the document entry for the updated version of the archived document),
"Deleted" (Depublished version).
The "Archived" and "Deleted" values of the availabilityStatus metadata were introduced in the HIS-IF. They are used to account for the regulatory framework and patient rights that shared health information systems must comply with in France. These values are not part of the actual XDS.b specification, and are considered by the IHE ITI committee to be French national extensions to XDS.b.
The "Deleted" value identifies the depublication of a shared patient health record document at the request of the patient or the healthcare professional. This is done through a logical suppression of the document that remains in the document repository but is no longer accessible. Depublication is not reversible.
The "Archived" value identifies the archiving of a shared patient health record document, at the request of the patient or the healthcare professional. This is done through a logical archiving of the document, which remains accessible to a query, but only if the query is explicitly extended to archived documents. Archiving is a reversible transaction.
The target system defines which actors are authorized to implement the updates.
The availabilityStatus metadata update of a document entry is obtained by submitting an UpdateAvailabilityStatus association, which is associated with a submission set.
The Update Document Set Request message contains the metadata in the following objects:
A submission set containing the metadata relative to a submission;
An UpdateAvailabilityStatus association between the submission set and the document entry, where the association contains the availabilityStatus metadata update for the document entry.
When the document registry receives the message, it:
Verifies that the association correctly references the most recent version of an existing document entry;
Verifies that the values are coherent;
Updates only the document entry's availabilityStatus metadata with the new value.
In this submission, neither the submission set nor the UpdateAvailabilityStatus association are saved in the document registry. Only the document entry's availabilityStatus metadata is updated. The traceability of update operations must be consolidated elsewhere in the shared health information system; either in the trace logs or other system logs.
The specific case of updating the availabilityStatus metadata of a document entry with "Deleted" requires:
The propagation of the availabilityStatus metadata update of all the previous versions of the document entries that resulted in either:
o updated documents using the Provide and Register Document Set-b [ITI-41] transaction, or
o updated document entries using the Update Document Set [ITI-57] transaction;
The propagation of the availabilityStatus metadata update of the association between the document entry and its submission set that is set to "Deprecated";
If the document entry is linked to multiple folders:
o The propagation of the availabilityStatus metadata update of the associations linking the document entry to the folders that are set to "Deprecated"; where the lastUpdateTime metadata of each folder is updated with the date and time of the operation;
The logical suppression of the corresponding document and its previous versions in the document repository. This means that the document is physically still in the document repository, but is no longer accessible to transactions; this logical suppression is to be implemented at the target system.
Table 1 inventories all the implementation scenarios for the availabilityStatus metadata update of a document entry, whether the transaction is Provide and Register Document Set-b [ITI-41], or Update Document Set [ITI-57].
3.3.5.1.3 availabilityStatus metadata update for an association Use case: Detaching a document entry from a folder
The availabilityStatus metadata identifies the relevance of an association to the users. It has the following possible values:
"Approved" (active association),
"Deprecated" (deactivated association).
The availabilityStatus metadata update is obtained by submitting an UpdateAvailabilityStatus association, which is associated with a submission set.
French constraints to XDS.b limit this submission to the deactivation of a HasMember association, between a folder and a document entry, in order to detach the document entry from a folder.
The target system defines which actors are authorized to implement this update.
The inverse operation to change the availabilityStatus metadata from "Deprecated" to "Approved" is not permitted. In this case, a new association between the folder and the document entry must be submitted. For more details, see section 3.3.1.3.
The Update Document Set Request message contains the metadata in the following objects:
A submission set containing the metadata relative to the submission;
An UpdateAvailabilityStatus association between the submission set and an association for updating the availabilityStatus metadata for the association.
When the document registry receives the message, it:
Verifies that the association correctly references an existing association in the document registry;
Verifies that the existing association is a HasMember type association, and that the source object is a folder;
Updates the availabilityStatus metadata of the association with the new value.
In this submission, neither the submission set nor the UpdateAvailabilityStatus association are saved in the document registry. Only the availabilityStatus metadata for the association is updated. The traceability of update operations must be consolidated elsewhere in the shared health information
system, for example either in the trace logs or other system logs. For the DMP this would be stored in the functional logs.
3.3.5.2
availabilityStatus metadata: Update scenario
The tables in this section list the update scenarios for the availabilityStatus metadata for a document entry and an association.
A submission set is immutable once saved to the document registry. The value of its availabilityStatus metadata remains static and set to "Approved".
Since the update of a folder is out of scope for the French constraints to XDS.b, the value of the availabilityStatus metadata for the folder is static and must be set to "Approved".
3.3.5.2.1 availabilityStatus metadata update for a document entry
Table 1 lists the update scenario for the availabilityStatus metadata update of a document entry via either the Provide and Register Document Set-b [ITI-41] or the Update Document Set [ITI-57] transactions, either directly or indirectly by propagation. The table also lists document registry transactions on other objects.
availabilityStatus metadata update scenario for a document entry Original
value
Target value Transaction Use case - Update type - Impact on other registry objects Approved Archived Update Document
Set [ITI-57],
availabilityStatus
metadata update
Use case : Archiving.
Direct update by the transaction.
No propagation to other objects in the document registry.
availabilityStatus metadata update scenario for a document entry Original
value
Target value Transaction Use case - Update type - Impact on other registry objects Approved Deleted Update Document
Set [ITI-57],
availabilityStatus
metadata update
Use case: Depublication.
Direct metadata update by the transaction. Propagation of the availabilityStatus metadata update to all the previous versions of the
document entry resulting from either the Provide and Register Document Set-b [ITI-41] transaction document updates, or resulting from the Update Document Set [ITI-57] transaction replacement of the document entry by a new version. The
availabilityStatus metadata is then set to "Deleted".
There are repercussions to the
availabilityStatus metadata of the associations linking the document entry to its submissions set. The availabilityStatus metadata is then set to "Deprecated";
If the document entry is linked to several folders:
There are repercussions to the
availabilityStatus metadata of the associations linking the document entry to folders. The availabilityStatus metadata is then set to "Deprecated"; the lastUpdateTime
metadata of each folder is updated with the date and time of the transaction;
Logical suppression of the corresponding document and its previous versions in the document repository.
Approved Deprecated Update Document Set [ITI-57], replacement of a document entry following a ConfidentialityCode metadata update
Use case: Management of masking and visibility of a document.
Direct update by the transaction.
Update of the previous version of the document entry's availabilityStatus metadata, set to "Deprecated" .
Approved Deprecated Provide and Register Document Set-b [ITI-41], update of an existing document
Use case: Replacement of a document with a new version.
Direct update by the transaction.
When a document is updated in the document repository with a new version, the
availabilityStatus metadata update of the corresponding document entry is set to
"Deprecated", as described in section 3.3.1.3.4. Archived Approved Update Document
Set [ITI-57],
availabilityStatus
metadata update
Use case: De-archiving.
Direct update by the transaction.
No propagation to other objects in the document registry.
availabilityStatus metadata update scenario for a document entry Original
value
Target value Transaction Use case - Update type - Impact on other registry objects Archived Deleted Update Document
Set [ITI-57],
availabilityStatus
metadata update
Use case: Depublication.
Direct metadata update by the transaction. Propagation of the availabilityStatus metadata update to all the previous versions of the
document entry resulting from either the Provide and Register Document Set-b [ITI-41] transaction document updates, or resulting from the Update Document Set [ITI-57] transaction replacement of the document entry by a new version. The
availabilityStatus metadata is then set to "Deleted".
There are repercussions to the
availabilityStatus metadata of the associations linking the document entry to its submissions set. The availabilityStatus metadata is then set to "Deprecated";
If the document entry is linked to several folders:
There are repercussions to the
availabilityStatus metadata of the associations linking the document entry to folders. The availabilityStatus metadata is then set to "Deprecated"; the lastUpdateTime
metadata of each folder is updated with the date and time of the transaction;
Logical suppression of the corresponding document and its previous versions in the document repository.
Archived Deprecated Update Document Set [ITI-57], replacement of a document entry following a ConfidentialityCode metadata update
Use case: Management of masking and visibility of a document.
Direct update by the transaction.
Update of the previous version of the document entry's availabilityStatus metadata, set to "Deprecated".
Archived Deprecated Provide and Register Document Set-b [ITI-41], update of an existing document
Use case: Replacement of a document with a new version.
Direct update by the transaction.
When a document is updated in the document repository with a new version, the
availabilityStatus metadata update of the corresponding document entry is set to
"Deprecated", as described in section 3.3.1.3.4. Deprecated Approved - N/A
availabilityStatus metadata update scenario for a document entry Original
value
Target value Transaction Use case - Update type - Impact on other registry objects Deprecated Deleted Update Document
Set [ITI-57],
availabilityStatus
metadata update, set to "Deleted"
Use case: Depublication of a document. Indirect update by propagation.
Deleted Approved - N/A Deleted Archived - N/A Deleted Deprecated - N/A
Table 1: availabilityStatus metadata update scenario for a document entry 3.3.5.2.2 availabilityStatus metadata state change for an association
Table 2
shows the update of the
availabilityStatus
metadata for an association using the
Update
Document Set [ITI-57] transaction, directly or indirectly through propagation. It also lists theactions performed by the registry on other objects.
availabilityStatus metadata update scenario for an association Original
value
Target value Transaction Use case - Update type - Impact on other registry objects Approved Deprecated Update Document
Set [ITI-57],
availabilityStatus
metadata update
Use case: Detaching a document entry from a folder
Direct update by the transaction.
No propagation to other objects in the document registry.
Approved Deprecated Update Document Set [ITI-57],
availabilityStatus
metadata update of a document entry to "Deleted"
Use case: Depublication of a document Update by repercussion.
Deprecated Approved - N/A
Table 2: availabilityStatus metadata update scenario for an association
3.3.6
Declaration of a patient identity
The target system must be aware of the patient identifier prior to accepting any documents concerning a patient.
Functionally, this identity declaration is done upon the creation or opening of a patient record. The transaction for opening the file is described in the "Management of shared patient records" module of the service layer.
The manner in which this flow is implemented by the target system, especially how to inform the document registry of new patient identifiers, is the responsibility of the target system and is not specified in the interoperability framework.
3.4 XDS metadata of a document entry
This section describes the metadata or attributes of a document entry in the document registry representing a document stored in the document repository. The metadata and attributes are described in terms of content, format and optionality.
The "Source" section specifies the origin of the information.
The "Population from a CDA Document" section specifies the correspondence between XDS metadata and the CDA document header.
This specification describes the metadata as they are to appear in the following XDS.b and XDM transactions: ITI-41, ITI-18, ITI-32 and ITI-57. Constraints due to requirements in France will apply.
3.4.1
author
3.4.1.1
Type
This metadata identifies physical persons and/or medical devices that have authored a document. This metadata is composed of the authorInstitution, authorPerson, authorRole, and authorSpecialty sub-attributes. The author metadata does not have its own value.
3.4.1.2
Optionality
The original optionality of the author metadata is R2 (Required if known) in XDS. For operational reasons, the author optionality is set to R (Required) in the French domain.
3.4.1.3
Cardinality
[1..*],A document may have one or more authors. Each author is described by its own set of authorInstitution, authorPerson, authorRole, and authorSpecialty sub-attributes.
3.4.1.4
Examples
Examples are given in section 3.4.5.8.
3.4.2
authorInstitution
3.4.2.1
Usage
This metadata identifies the organization for which the document was created.
For documents created by the patient, this metadata is absent. This means that the <rim:Slot name="authorInstitution"> XML element is not transmitted.
3.4.2.2
Type
HL7 v2.5 XON data type, described in reference document [4]: Constraints on HL7 v2.5 data types that apply to the IHE IT Infrastructure Technical Framework within the scope of IHE France v1.3.
3.4.2.3
Optionality
R2 (Required if known)
3.4.2.4
Cardinality
The authorInstitution cardinality in XDS.b is [0..*], which for operational reasons is constrained to [0..1] in the French domain.
