ABCDEFGHIJKLMNOPQR
1
Please complete this spreadsheet by Monday, August 30th
To submit your entry, scroll right and add your votes/comments in the next available column...
Ballot contents:
2
link to ballot folder here
3
4
Organization-->InterolpEhealthSSALyniateHarris ComputerANSVisusByLightPhilipsahdisEpicIHE SuisseIntraHealth InternationalGE HealthcarePATH
5
CP-ITI-Descr.Your name-->Charles ParisotJoe LamyBen LevyElliott Lavy (non-voting)Sylvie ColasThorsten Conrad (non-voting)John MoehrkeChris MeloOliver EggerSpencer LaGesseMartin SmockRichard StanleySteve NicholsLuke Duncan
6
1178-03XDS: misalignment between example and description for localizedString
Yes/Abstain/No
NoNoAbstainnon-votingNoabstainNoNoNoYesAbstainYesAbstain
7
Comments:
(Req'd if No)
This CP introduces a non-backward compatible change, as the "XDS" part of the string is specified in all table of query attributes and is likely used by numerous implementations. The inconsitency need to be addressed, but ITI Tech needs to consider that grandfathering the "XDS" prefix may be a more acceptable approach.I concur with Spencer's position; no need to restate it all.Charles,
I was wondering if your issue with 1178 is limited to the parameters in ITI-18. If so, please update the comment accordingly. I definitely agree that those changes would breaking, but the others seem not to be.
This change would produce too many impacts on existing implementationsIt is unclear to me, due to lack of subject matter expertiese, if the change proposed has any interoperability impact. The comment seems to indicate that this is just documentation consistency.We interpret that this will impact our existing implementations.1. Our examples use also XDS" in ITI 18 QueryResponse, https://github.com/ehealthsuisse/EPD-by-example/blob/main/files/RegistryStoredQuery.md
2. Systems available on the market use XDSxxx in LocalizedString responses (see gazelle logs)
3. Also gazelle Assertion manager checks the existance of XDS in Registry Responses, e.g: Allowed Classification on XDSFolder are only XDSFolder.patientId and XDSFolder.uniqueId (IHE_ITI_TF V3, 4.2.3.4) https://ehealthsuisse.ihe-europe.net/AssertionManagerGui/assertions/show.seam?idScheme=IHEXDS&assertionId=IHEXDS-83
Recall that the actual piece of the messages we're talking about here is ExternalIdentifier/Name/value for the set of DocumentEntry, Folder, and SubmissionSet metadata attributes that are expressed as ExternalIdentifiers.

The CP rationale declares that the correct, normative value of that element is the name of the attribute prefixed with the object type to which the metadata attribute applies followed by a period (ie, DocumentEntry.patientId for the patientId attribute of the DocumentEntry object). This assertion is based on the following text from the current version of the technical framework:

"The attribute name is defined with a prefix of the object type of DocumentEntry when referenced by other objects, for example DocumentEntry.patientId."

The first problem I take with this statement is that I'm not sure what the above text is supposed to mean. What does "when referenced by other objects" mean? When discussing ExternalIdentifier/Name/value, we aren't referencing the metadata attribute from other objects, we are referencing it within the same object. This is likely why many implementations simply copied the example text (wich disagrees by further prefixing the names with XDS) which the CP rationale believes to be incorrect.

The need to value ExternalIdentifier/Name/value based on the "attribute name" comes from the following text in table 4.2.3.1.3-1: "The readable name for the identifier. Fixed value according to the particular identifier." - which is actually pretty vague and arguably nonprescriptive. The CP changes this text to be "Should be valued with the readable name for the identifier as defined in Sections 4.2.3.2, 4.2.3.3, and 4.2.3.4. I assert that this text, by itself, resolves any technical problems here by explicately declaring that the prescribed value of ExternalIdentifier/Name/value is a should and not a shall. Therefore, implementations can set that element however they like and remain technically compliant. This is not an interoperability problem because that field is not useful for interoperability and I strongly suspect that the vast majority, if not all, consuming systems ignore it completely. The only breakage this change causes would be if a consuming system took a position on the correct value for that element and enforced it as part of validation. In that case, the consuming system would no longer be compliant since there will exist a set of technically valid messages that it will no longer accept. I believe the risk of this is overall very low and does not become higher becuase of this CP (due to the ambiguity currently present in the technical framework).

I believe what remains, following that change, is a documentation inconsistency in the technical framework that makes it more challenging than necessary for readers to correlate the metadata attribute definitions in section 4.2.3 with references to those metadata attributes found in the rest of the technical framework. Fixing this requires us to decide whether the "XDS" prefix belongs or not and make everything consistent.

I vote no for the following reasons, about which I do not feel strongly due to the fact that I believe that the actual technical problem is resolved as described above.

-It seems the vast majority of the technical framework currently uses the "XDS" prefix, the examples use it, and as a result most implementers use the "XDS" prefix. Choosing to resolve this descrepency by adopting the "XDS" prefix everywhere will be less confusing to existing implementers than the current CP which proposes to strip it from all those places.
-The text that currently defines the attribute names, for example, "The attribute name is defined with a prefix of the object type of DocumentEntry when referenced by other objects, for example DocumentEntry.patientId. " should be revised to be more clear since it is currently rather confusing. I propose explicitly stating how the ExternalIdentifier/Name/value should be constructed and explicitly establishing that a pattern for referring to these metadata attributes throughout the technical framework.
8
1246-00PIXm target domain not recognized applies one or moreYesYesYesnon-votingYesYes - See https://github.com/IHE/ITI.PIXm/issues/87YesYesYesYesYesYes
9
note the change should be made to the current Public-Comment PIXm IG which is slightly different, althouh still has the same text being modified.Yes
10
1253-05XDR PatientIDNo - version -06 of this CP updated the rationale to address Charles' commentYesYesnon-votingYesYesYesYesYesYesAbstainabstainYes
11
The rationale for change is confusing and contradicts the proposed change:
1- "For XDS, Section 3.42.4.1.3.3 indicates that the PatientId of all objects in the SubmissionSet must have the same PatientId. This text, however, is part of of the Register Document Set-b [ITI-42] transaction, so there's no reason why an XDR Document Recipient, which only uses Provide and Register Document Set-b [ITI-41], should be allowed to enforce it. ==> The CP seems to propoe to relax the reuiqrment for an XDR transaction to be "single patient centric"
2 - The proposed change makes the definition of a submission set very explicit in that it applies to a single patient (which is the intent). Submission set is a concept used by XDR transactions and need to be infroced by the Document Receipient.
I am no longer sure what the CP is trying to accomplish, so it shall be rjected until clarified.
Agree rationale is all that is unclear.I took the opposite than Charles did: Looking at the only text this CP proposes to add, it appears to want to make sure that all objects in a submission set refer to the same patient.The rationale was intended to say that an XDR Recipient can't enforce rules from ITI-42 because it's not using ITI-42. The CP is intended to declare the rules in a way that make them enforceable by an XDR Recipient.

What if that part of the rationale was change to:
so an XDR Document Recipient, which only uses Provide and Register Document Set-b [ITI-41], can't enforce it.
The actual change request is clear. The rational is confusing. As I understand this, it is indeed only clarifying the content will all be about the same patient.
12
1257-02Clarify minimum for client authenticationYesYesYesnon-votingYesabstainYesYesYesYesAbstainabstainYes
13
The change in this CP for the token request is ok. But note that the authorization request shown is incorrect, as client_id is always required for that by OAuth 2.1, section 4.1.1.1. I'll address that in a separate CP.don't have enough SME to evaluate the change
14
1259-03Add SVCM constraint for idYesAbstainYesnon-votingYes
FYI - Feedback from CP Submitter (VISUS)
No NoabstainYesAbstainYesYes
15
the CP looks good for me. Although the CodeSystem and ConceptMaps are not mentioned in my concern, it is a good idea to correct this parts also.

(Legacy) Systems, which implements both Profiles will have to think about the storage of the separate URL.
As I learned at the EUCAT, it is not so easy to map the SVS Data into an SVCM Model.
The CP is making more changes than the initial CP request and rational asked for. These other changes should be evaluated on their own.Agree on need to keep this CP only to what was originally submitted.Yes
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100