Docstoc

Consolidated_ITI_TF_Supplement_Public_Comment_Form-2011_LZ

Document Sample
Consolidated_ITI_TF_Supplement_Public_Comment_Form-2011_LZ Powered By Docstoc
					Submitter   Supplement Name             Other Document   Vol       Section #   Line #
Name        (click cell and select from Name
            list)
Charles                                                        1



            Cross-Enterprise
            Document
            Workflow (XDW)
felhofer    Cross-Enterprise                                   3 5.Y.2.1.1              982
            Document Workflow
            (XDW)




            Support for                                            general
Lynn        Metadata-Limited                                       comment/q
Felhofer    Document Sources                                       uestion
moore       Cross-Enterprise                                   3 5.Y.2.1.1              982
            Document Workflow
            (XDW)
moore      Cross-Enterprise    3 5.Y.2.1.1       982
           Document Workflow
           (XDW)
moore      Cross-Enterprise    3 5.Y.2.1.2       997
           Document Workflow
           (XDW)




felhofer   Cross-Enterprise    3 5.Y.2.2        1070
           Document
           Workflow (XDW)




moore      Cross-Enterprise    3 5.Y.2.2        1070
           Document
           Workflow (XDW)
Mark       Cross Community       Introduction    100
Sinke      Fetch (XCF)




Mark       Cross Community       Closed issue
Sinke      Fetch (XCF)           XCF005

Mark       Cross Community       Closed issue
Sinke      Fetch (XCF)           XCF004

Mark       Cross Community     1 X.3             221
Sinke      Fetch (XCF)
Mark    Cross Community                   1 X.3.2     275
Sinke   Fetch (XCF)




Mark    Cross Community                   1 X.4.1.1   300
Sinke   Fetch (XCF)




Mark    Cross Community                   1 X.4.1.2   320
Sinke   Fetch (XCF)

Mark    Cross Community                   1 X.4.1.*   300
Sinke   Fetch (XCF)


Mark    Cross Community                   1 X.4.2
Sinke   Fetch (XCF)



Mark    Cross Community   Risk Mit. XLS    row 10
Sinke   Fetch (XCF)
Mark    Cross Community   Risk Mit. XLS    row 12
Sinke   Fetch (XCF)
Mark    Cross Community   Risk Mit. XLS    row 16
Sinke   Fetch (XCF)
Mark    Cross Community     Risk Mit. XLS     row 34
Sinke   Fetch (XCF)
Mark    Cross Community                     1 X.5.2          392
Sinke   Fetch (XCF)

Mark    Cross Community                     1 X.5.2          400
Sinke   Fetch (XCF)


Mark    Cross Community                       3.Y.4.1.2      495
Sinke   Fetch (XCF)




Mark    Cross Community                       3.Y.4.1.4      569
Sinke   Fetch (XCF)
Mark    Cross Community                       3.Y.4.1,       584
Sinke   Fetch (XCF)                           3.Y.4.2


Mark    Cross Community                       3.Y.4.2.2      604
Sinke   Fetch (XCF)
Mark    Cross Community                       general
Sinke   Fetch (XCF)



Mark    Cross Community                       3.Y.4.2.2      642
Sinke   Fetch (XCF)

Mark    Cross Community                       3.Y.4.2.4      645
Sinke   Fetch (XCF)



Mark    Cross Community                       3.Y.7          730
Sinke   Fetch (XCF)

Mark    Cross Community                       table 4-1.11   760
Sinke   Fetch (XCF)
Mark    Cross Community                       3.Y.5          657
Sinke   Fetch (XCF)



Mark    Cross Community                       3.Y.5.1        675
Sinke   Fetch (XCF)



Mark    XAD-PID Change                      1 Introduction
Sinke   Management (XPID)
Mark       XAD-PID Change      1 Introduction     114
Sinke      Management (XPID)

Mark       XAD-PID Change      1 X.5              336
Sinke      Management (XPID)

Mark       XAD-PID Change      2 3.Y.4.1.2        395
Sinke      Management (XPID)


Mark       XAD-PID Change      2 3.Y.4.1.3        425
Sinke      Management (XPID)




Mark       XAD-PID Change      2 3.Y.4.1.3        425
Sinke      Management (XPID)




Mark       XAD-PID Change      2 3.Y.5.1.1        495
Sinke      Management (XPID)


moore      Cross-Enterprise    3 5.y.2.2         1070
           Document Workflow
           (XDW)

Malcolm    Cross-Enterprise
Newbury    Document Workflow
           (XDW)


felhofer   Cross-Enterprise    1 fig x.4.1.4-1    443
           Document Workflow
           (XDW)


Rob Horn   Cross-Enterprise
           Document Workflow
           (XDW)
Malcolm   Cross-Enterprise
Newbury   Document Workflow
          (XDW)




Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)                  3 5.Y.2       970-971
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)                  3 5.Y.2.1.1   976-990
Philips   Cross-Enterprise    Intro                 211
          Document Workflow
          (XDW)
Charles                          1 XX.4             810


          Cross-Enterprise
          Document
          Workflow (XDW)
Karen     Cross-Enterprise        1 X.4.1.3         429
Witting   Document Workflow
          (XDW)
Philips   Cross-Enterprise    Vol.                  428
          Document Workflow   1
          (XDW)
Philips   Cross-Enterprise    Vol.                  795
          Document Workflow   1
          (XDW)
sippel    Cross-Enterprise        1 overall              0
          Document Workflow
          (XDW)
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)
                                 3 5.Y.4           1120
Charles                          3 5.Y.2.1.3




          Cross-Enterprise
          Document
          Workflow (XDW)
felhofer   Cross-Enterprise       1 X.3                384
           Document Workflow
           (XDW)




sippel     Cross-Enterprise       1 x.2.2              343
           Document Workflow
           (XDW)
sippel     Cross-Enterprise       1 x.3                351
           Document Workflow
           (XDW)

Karen      Cross-Enterprise    N/A Open Issues   165-210
Witting    Document Workflow        and
           (XDW)                    Questions
Charles                           1              294-295
           Cross-Enterprise
           Document
           Workflow (XDW)
Charles                           3 5.Y.2.2.1         1082




           Cross-Enterprise
           Document
           Workflow (XDW)
Malcolm    Cross-Enterprise
Newbury    Document Workflow
           (XDW)




Charles    Cross-Enterprise       1 X.1                322
           Document
           Workflow (XDW)
                                 1 X.2                   345




          Cross-Enterprise
          Document
          Workflow (XDW)
sippel    Cross-Enterprise       1x                        0
          Document Workflow
          (XDW)


moore     Cross-Enterprise       1X                        0
          Document Workflow
          (XDW)
Karen     XAD-PID Change      N/A Introduction general
Witting   Management (XPID)




Karen     XAD-PID Change         1 X.4.1         303-304
Witting   Management (XPID)

Karen     XAD-PID Change         1 X.4.1                 319
Witting   Management (XPID)


Karen     Document            N/A Introduction 110-155
Witting   Encryption (DEN)



Karen     Document            N/A Introduction           148
Witting   Encryption (DEN)
Karen      Document           N/A Introduction         145
Witting    Encryption (DEN)
Karen      Document           N/A Open Issues          282
Witting    Encryption (DEN)       & Questions

Karen      Document              1 X.4           382-385
Witting    Encryption (DEN)

Karen      Document              1 16.2.6        447-448
Witting    Encryption (DEN)



Karen      Document              1 3.32.4.1.6          560
Witting    Encryption (DEN)

Karen      Document           N/A N/A            N/A
Witting    Encryption (DEN)
felhofer   Cross Community       1 Intro               120
           Fetch (XCF)


sippel     Cross Community
           Fetch (XCF)




                                 1X                    184
felhofer   Cross Community       1 X.3                 219
           Fetch (XCF)


felhofer   Cross Community       1 X.3                 219
           Fetch (XCF)




felhofer   Cross Community       1 X.3                 222
           Fetch (XCF)

sippel     Cross Community
           Fetch (XCF)


                                 1 x.3.1               233
sippel     Cross Community
           Fetch (XCF)           1 x.3.2-1             249
felhofer   Cross Community                             255
           Fetch (XCF)
felhofer   Cross Community                             257
           Fetch (XCF)
sippel     Cross Community
           Fetch (XCF)
                             1 x3.2            260
                                               260
           Cross Community
moore      Fetch (XCF)       1 X.3.2
                                               271
           Cross Community
moore      Fetch (XCF)       1 X.3.2
felhofer   Cross Community   1 X.3.3           286
           Fetch (XCF)

felhofer   Cross Community   1 X.3.3           287
           Fetch (XCF)




felhofer   Cross Community                     295
           Fetch (XCF)
felhofer   Cross Community   1 x.4 and X.4.2   297
           Fetch (XCF)

felhofer   Cross Community   1 X.4.1.2         320
           Fetch (XCF)

felhofer   Cross Community   1 X.4.1.2         328
           Fetch (XCF)
felhofer   Cross Community   1 Figure X.4.2-   354
           Fetch (XCF)         1
felhofer   Cross Community   1 X.4.2           355
           Fetch (XCF)
felhofer   Cross Community   1 X.4.2           368
           Fetch (XCF)


felhofer   Cross Community   1 X.4.2           369
           Fetch (XCF)

sippel     Cross Community
           Fetch (XCF)         x.5.2           385
felhofer   Cross Community   1 X.4.2           392
           Fetch (XCF)



felhofer   Cross Community   1 X.5.2           395
           Fetch (XCF)
felhofer   Cross Community   1 X.5.2            401
           Fetch (XCF)

felhofer   Cross Community   1 X.5.2            401
           Fetch (XCF)
felhofer   Cross Community   1 X.5.2            403
           Fetch (XCF)


moore      Cross Community
           Fetch (XCF)

                                                405
felhofer   Cross Community   1 X.5.2            424
           Fetch (XCF)




moore      Cross Community
           Fetch (XCF)
                                                430
felhofer   Cross Community   1 Appx A           444
           Fetch (XCF)
moore      Cross Community
           Fetch (XCF)                          495
felhofer   Cross Community   2 Table 3.Y.4.1-   498
           Fetch (XCF)         1
felhofer   Cross Community   2 Table 3.Y.4.1-   498
           Fetch (XCF)         1




felhofer   Cross Community   2 3.Y.4.1.2.2      518
           Fetch (XCF)
felhofer   Cross Community   2 3.Y.4.1.2.2      525
           Fetch (XCF)
felhofer   Cross Community   2 3.Y.4.1.2.3   547
           Fetch (XCF)




felhofer   Cross Community   2 3.Y.4.1.4     568
           Fetch (XCF)

felhofer   Cross Community   2 3.Y.4.1.4     572
           Fetch (XCF)
felhofer   Cross Community   2 3.Y.4.1.4     575
           Fetch (XCF)


felhofer   Cross Community   2 3.Y.4.1.4     579
           Fetch (XCF)




felhofer   Cross Community   2 3.Y.4.2       585
           Fetch (XCF)
felhofer   Cross Community   2 3.Y.4.2.2     591
           Fetch (XCF)
felhofer   Cross Community   2 3.Y.4.2.2     613
           Fetch (XCF)
felhofer   Cross Community   2 3.Y.4.2.2     615
           Fetch (XCF)
felhofer   Cross Community   2 3.Y.4.2.3     632
           Fetch (XCF)

felhofer   Cross Community   2 3.Y.4.2.3     636
           Fetch (XCF)




felhofer   Cross Community   2 3.Y.4.2.3     639
           Fetch (XCF)
felhofer   Cross Community          2 3.Y.4.2.3           644
           Fetch (XCF)


felhofer   Cross Community          2 3.Y.4.2.4           646
           Fetch (XCF)

felhofer   Cross Community          2 3.Y.4.2.5           655
           Fetch (XCF)


felhofer   Cross Community          2 3.5.Y               660
           Fetch (XCF)


felhofer   Cross Community          2 3.5.Y               671
           Fetch (XCF)




felhofer   Cross Community          2 3.5.Y               672
           Fetch (XCF)




felhofer   Cross Community          2 3.Y.5.1             677
           Fetch (XCF)


felhofer   Cross Community          3 4.1.13             1161
           Fetch (XCF)


felhofer   Cross Community          3 4.1.13             1171
           Fetch (XCF)
felhofer   Cross Community          1 table X.3.2-1 246 and
           Fetch (XCF)                              252


Teri Sippel Support for Metadata-   1             0            0
            Limited Document
            Sources

felhofer                                Intro                 95

           Support for
           Metadata-Limited
           Document Sources
Teri Sippel Support for Metadata-   1                0   115
            Limited Document
            Sources
felhofer                                Use cases        129

           Support for
           Metadata-Limited
           Document Sources
felhofer                                Use cases        168

           Support for
           Metadata-Limited
           Document Sources
Teri Sippel Support for Metadata-   1               15   248
            Limited Document
            Sources
felhofer                            1 table 3.32.4.1-1   322

           Support for
           Metadata-Limited
           Document Sources
moore                               2 3.32.4.1.2.2       329




           Support for
           Metadata-Limited
           Document Sources
moore                               2 3.32.4.1.2.2         0




           Support for
           Metadata-Limited
           Document Sources
Teri Sippel Support for Metadata-   2 3.32.4             330
            Limited Document
            Sources
moore                               3 3.41.1.2     470




           Support for
           Metadata-Limited
           Document Sources
moore                               2 3.41.1.2     470




           Support for
           Metadata-Limited
           Document Sources
Teri Sippel Support for Metadata-   2 3.41.4.1.3   480
            Limited Document
            Sources
                                    3 4.1.7         605

           Support for
           Metadata-Limited
felhofer   Document Sources
                                    3 table 4.1-5   611

           Support for
           Metadata-Limited
felhofer   Document Sources
                                    3 table 4.1-5   611




           Support for
           Metadata-Limited
felhofer   Document Sources
Teri Sippel Support for Metadata-   3 4.1-4         615
            Limited Document
            Sources




                                    3 table 4.1-6   616




           Support for
           Metadata-Limited
felhofer   Document Sources
                                    3 table 4.1-6   616

           Support for
           Metadata-Limited
felhofer   Document Sources
                                    3 table 4.1-6   616

           Support for
           Metadata-Limited
felhofer   Document Sources
                                    3 table 4.1-7         625

           Support for
           Metadata-Limited
felhofer   Document Sources
felhofer                            1           15.2 231 and 235

           Support for
           Metadata-Limited
           Document Sources
Teri Sippel Support for Metadata-   2 3.32.4 and    320 and
            Limited Document          3.41.4        470
            Sources


felhofer                                Intro




           Support for
           Metadata-Limited
           Document Sources
felhofer


           Support for
           Metadata-Limited
           Document Sources
Teri Sippel Support for Metadata-   2                      330
            Limited Document
            Sources



felhofer   XAD-PID Change               intro                 90
           Management (XPID)

felhofer   XAD-PID Change               intro                 94
           Management (XPID)




felhofer   XAD-PID Change               intro              107
           Management (XPID)
Teri Sippel XAD-PID Change      1    1   210
            Management (XPID)




Teri Sippel XAD-PID Change      1x       215
            Management (XPID)

Teri Sippel XAD-PID Change      1x       218
            Management (XPID)

felhofer   XAD-PID Change       1X       224
           Management (XPID)




Teri Sippel XAD-PID Change      1x       225
            Management (XPID)

Teri Sippel XAD-PID Change      1x       243
            Management (XPID)

felhofer   XAD-PID Change       1X       246
           Management (XPID)




Teri Sippel XAD-PID Change      1x       253
            Management (XPID)
felhofer   XAD-PID Change       1 X.1.1.1   270
           Management (XPID)




Teri Sippel XAD-PID Change      1 x.4       295
            Management (XPID)

felhofer   XAD-PID Change       1 X.4.1     326
           Management (XPID)
felhofer   XAD-PID Change      2                365
           Management (XPID)




felhofer   XAD-PID Change      2 3.Y.4.1.1      387
           Management (XPID)



felhofer   XAD-PID Change      2 3.Y.4.1.2      390
           Management (XPID)

felhofer   XAD-PID Change                       395
           Management (XPID)

felhofer   XAD-PID Change      2 3.10.4.1.2.3   403
           Management (XPID)



felhofer   XAD-PID Change      2 3.10.4.1.2.3   405
           Management (XPID)
felhofer   XAD-PID Change       2 3.10.4.1.2.3   409
           Management (XPID)

felhofer   XAD-PID Change       2 3.10.4.1.2.4   415
           Management (XPID)

felhofer   XAD-PID Change       2 3.10.4.1.2.4   416
           Management (XPID)




felhofer   XAD-PID Change       2 3.Y.4.1.3      424
           Management (XPID)




Teri Sippel XAD-PID Change      2 3.y.4.1.3      427
            Management (XPID)
felhofer   XAD-PID Change      2 3.Y.4.1.3   430
           Management (XPID)




felhofer   XAD-PID Change      2 3.Y.4.1.3   446
           Management (XPID)




felhofer   XAD-PID Change      2 3.Y.4.1.3   464
           Management (XPID)


felhofer   XAD-PID Change      2 3.Y.5.1     490
           Management (XPID)
felhofer   XAD-PID Change      1X                  0
           Management (XPID)




moore      XAD-PID Change
           Management (XPID)

felhofer   XAD-PID Change      2 3.10.4.1.2.2
           Management (XPID)     and .3 and .4

felhofer   XAD-PID Change
           Management (XPID)




moore      XAD-PID Change      1 fig x.4.1-2       0
           Management (XPID)



felhofer   Document              intro           118
           Encryption (DEN)

felhofer   Document              overview        145
           Encryption (DEN)




felhofer   Document              overview        156
           Encryption (DEN)
felhofer     Document             overview &
             Encryption (DEN)     use cases



felhofer     Document             use cases    247
             Encryption (DEN)



felhofer     Document             use cases    258
             Encryption (DEN)
fellhofer,   Document
moore, or    Encryption (DEN)
sippel




felhofer     Document           1 2.2.x        304
             Encryption (DEN)


moore        Document           1X             326
             Encryption (DEN)




moore        Document           1X             329
             Encryption (DEN)
moore        Document           1 x.3.1        349
             Encryption (DEN)


felhofer     Document           1 x.3.2        366
             Encryption (DEN)
felhofer     Document           1 x.4          369
             Encryption (DEN)



moore        Document           1 x.4          374
             Encryption (DEN)
moore        Document           1 x.5          391
             Encryption (DEN)
moore       Document           1 x.5            405
            Encryption (DEN)




moore       Document           1 x.5            427
            Encryption (DEN)

felhofer    Document           1 16.2.6         444
            Encryption (DEN)


felhofer    Document           2 3.32.3         475
            Encryption (DEN)

felhofer    Document           2 3.32.4.1.2.4   495
            Encryption (DEN)

felhofer,   Document           2 3.32.4.1.2.4   496
moore, or   Encryption (DEN)
sippel



moore       Document           2 3.32.4.1.2.4   498
            Encryption (DEN)


felhofer    Document                            514
            Encryption (DEN)   2 3.32.4.1.4.1
moore       Document                            515
            Encryption (DEN)   2 3.32.4.1.4.1
felhofer    Document                            518
            Encryption (DEN)




                               2 3.32.4.1.4.1
moore       Document                            557
            Encryption (DEN)




                               2 3.32.4.1.6
moore      Document                                  567
           Encryption (DEN)




                              2 3.32.4.1.6.2
felhofer   Document                              586 also
           Encryption (DEN)                          724




                              2 3.32.4.1.6.3 and 5.Y 2.2.3
felhofer   Document                                  591
           Encryption (DEN)




                              2 3.32.4.1.6.4
felhofer   Document                                  603
           Encryption (DEN)



                              2 3.32.4.1.6.4.1
felhofer   Document                                  609
           Encryption (DEN)



                              2 3.32.4.1.6.4.1
felhofer   Document                                  614
           Encryption (DEN)


                              2 3.32.4.1.6.4.2
felhofer   Document                                           637
           Encryption (DEN)


                                      2 3.32.4.1.6.4.3
moore      Document                                           659
           Encryption (DEN)




                                      3 5.Y
felhofer   Document                                           673
           Encryption (DEN)


                                      3 5.Y.2
moore      Document                                           826
           Encryption (DEN)           3 5.y.5
agfa       Document                prefa
           Encryption (DEN)        ce
agfa       Document
           Encryption (DEN)


agfa       Document                   1 x.3.1
           Encryption (DEN)
agfa       Document                   1 X.5
           Encryption (DEN)


agfa       Document                   1          16.5
           Encryption (DEN)
agfa       Document
           Encryption (DEN)


agfa       Support for Metadata-
           Limited Document
           Sources
Karen      Cross-Enterprise           1 X&                    255
Witting    Document Workflow            Introduction
           (XDW)
Karen      Cross-Enterprise           1 X.1                   320
Witting    Document Workflow
           (XDW)


Karen      Cross-Enterprise        App All of           General
Witting    Document Workflow       x   Appendix
           (XDW)                   XX XX
Karen      Cross-Enterprise    App XX.2   610-710
Witting    Document Workflow   x
           (XDW)               XX
Karen      Cross-Enterprise    App XX.3
Witting    Document Workflow   x
           (XDW)               XX         710-800
Karen      Cross-Enterprise    App
Witting    Document Workflow   x
           (XDW)               XX XX.4    800-900
felhofer   Cross-Enterprise                     943
           Document Workflow
           (XDW)




Charles                          1              311




           Cross-Enterprise
           Document
           Workflow (XDW)
moore      Cross-Enterprise      1 x.3          357
           Document Workflow
           (XDW)
Charles                       1 XX.1    499




          Cross-Enterprise
          Document
          Workflow (XDW)
Karen     Cross-Enterprise    1X        260
Witting   Document Workflow
          (XDW)
sippel    Cross-Enterprise    1x        312
          Document Workflow
          (XDW)


moore     Cross-Enterprise    1 X.3     385
          Document Workflow
          (XDW)


Sippel    Cross-Enterprise    1 x.4     395
          Document Workflow
          (XDW)

moore     Cross-Enterprise    3 5.Y.2   975
          Document Workflow
          (XDW)
Charles                      1 Introduction 131-144
                                            and 164




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1X          316




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1 X.4.1.3   433




          Cross-Enterprise
          Document
          Workflow (XDW)
         Cross-Enterprise
Jim      Document
Peterson Workflow (XDW)




Dave
Harvey on Cross-Enterprise
behalf of Document
IHE-UK    Workflow (XDW)       general
Karen     Cross-Enterprise    1 X.2.1    336-337
Witting   Document Workflow
          (XDW)
Karen     Cross-Enterprise    1 X.3                 388
Witting   Document Workflow
          (XDW)
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)               3 5.Y          900-947
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)




                              3 5.Y.2.1.2    1010-1012
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)               3 5.Y.2.1.3    1030-1032
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)

                              3 5.Y.4             1130
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)               3 5.Y.5        1138-1141
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)               3 5.Y.5.1      1151-1154
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)               3 5.Y.5.2      1155-1159
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)               3 5.Y.5.2      1163-1166
Charles                       1 Introduction 118-130
                                Section 2.2.X 250_256
                                Section X     260-272




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                       1             143




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                       1             161




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                       1 5.Y.2.1.3   1027



          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                       1 XX.1        605




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles   Cross-Enterprise    1 5.Y.5.2     1165
          Document Workflow
          (XDW)
Charles                      1 5.Y.5.3   1170




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1 5.Y.5.4   1181




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1           221



          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1           230



          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1           235
          Cross-Enterprise
          Document
          Workflow (XDW)
Charles   Cross-Enterprise   1           277
          Document
          Workflow (XDW)
                             1 X.3              352




          Cross-Enterprise
          Document
          Workflow (XDW)
                             1 X.3              368




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles   Cross-Enterprise   1 X.3              377
          Document
          Workflow (XDW)
Charles   Cross Community      Intro   99-125
          Fetch (XCF)



Charles   Cross Community      1.7              172
          Fetch (XCF)
Charles   Cross Community   2.2.X   177
          Fetch (XCF)




Charles   Cross Community   X       183
          Fetch (XCF)




Charles   Cross Community           221
          Fetch (XCF)

Charles   Cross Community           263
          Fetch (XCF)
Charles   Cross Community   268
          Fetch (XCF)




Charles   Cross Community   278
          Fetch (XCF)




Charles   Cross Community   294
          Fetch (XCF)
Charles   Cross Community             X.4.1.1   307
          Fetch (XCF)




Charles   Cross Community             X.4.2     353
          Fetch (XCF)


Charles   Cross Community             X.4.2     371
          Fetch (XCF)



Charles   Cross Community             X.5.2     386
          Fetch (XCF)

Charles   Cross Community                       662
          Fetch (XCF)




Philips   XAD-PID Change      Intro             107
          Management (XPID)

Philips   XAD-PID Change      Intro             114
          Management (XPID)
Philips   XAD-PID Change      Intro   146
          Management (XPID)


Philips   XAD-PID Change      Vol.    249
          Management (XPID)   1

Philips   XAD-PID Change      Vol.    331
          Management (XPID)   1

Philips   XAD-PID Change      Vol.    428
          Management (XPID)   2

Philips   XAD-PID Change      Vol.    449
          Management (XPID)   2

Philips   XAD-PID Change      Vol.    450
          Management (XPID)   2

Philips   XAD-PID Change      Vol.    455
          Management (XPID)   2

Philips   XAD-PID Change      Intro    92
          Management (XPID)

Philips   Cross Community     Intro   113
          Fetch (XCF)
Philips   Cross Community     Intro   116
          Fetch (XCF)
Philips   Cross Community     Intro   119
          Fetch (XCF)
Philips   Cross Community     Intro   124
          Fetch (XCF)
Philips   Cross Community     Intro   132
          Fetch (XCF)
Philips   Cross Community     Intro   134
          Fetch (XCF)
Philips   Cross Community     Intro   146
          Fetch (XCF)
Philips   Cross Community     Vol.    229
          Fetch (XCF)         1
Philips   Cross Community     Vol.    271
          Fetch (XCF)         1
Philips   Cross Community     Vol.    273
          Fetch (XCF)         1
Philips   Cross Community     Vol.    274
          Fetch (XCF)         1
Philips   Cross Community     Vol.    294
          Fetch (XCF)         1
Philips   Cross Community     Vol.    305
          Fetch (XCF)         1
Philips   Cross Community     Vol.    318
          Fetch (XCF)         1
Philips   Cross Community     Vol.    354
          Fetch (XCF)         1
Philips   Cross Community    Vol.    354
          Fetch (XCF)        1

Philips   Cross Community    Vol.    355
          Fetch (XCF)        1
Philips   Cross Community    Vol.    377
          Fetch (XCF)        1
Philips   Cross Community    Vol.    403
          Fetch (XCF)        1
Philips   Cross Community    Vol.    496
          Fetch (XCF)        2
Philips   Document           Intro   113
          Encryption (DEN)
Philips   Document           Intro   118
          Encryption (DEN)

Philips   Document           Intro   125
          Encryption (DEN)

Philips   Document           Intro   132
          Encryption (DEN)
Philips   Document           Intro   136
          Encryption (DEN)
Philips   Document           Intro   142
          Encryption (DEN)
Philips   Document           Intro   145
          Encryption (DEN)
Philips   Document           Intro   148
          Encryption (DEN)
Philips   Document           Intro   148
          Encryption (DEN)

Philips   Document           Intro   164
          Encryption (DEN)
Philips   Document           Intro   164
          Encryption (DEN)
Philips   Document           Intro   166
          Encryption (DEN)
Philips   Document           Intro   181
          Encryption (DEN)


Philips   Document           Intro   183
          Encryption (DEN)
Philips   Document           Intro   219
          Encryption (DEN)
Philips   Document           Intro   235
          Encryption (DEN)
Philips   Document           Intro   240
          Encryption (DEN)
Philips   Document           Intro   243
          Encryption (DEN)
Philips   Document           Intro   247
          Encryption (DEN)
Philips   Document           Intro      254
          Encryption (DEN)
Philips   Document           Vol.       301
          Encryption (DEN)   1
Philips   Document           Vol.       318
          Encryption (DEN)   1
Philips   Document           Vol.       326
          Encryption (DEN)   1
Philips   Document           Vol.       382
          Encryption (DEN)   1
Philips   Document           Vol.       401
          Encryption (DEN)   1
Philips   Document           Vol.       416
          Encryption (DEN)   1
Philips   Document           Vol.       422
          Encryption (DEN)   1
Philips   Document           Vol.       424
          Encryption (DEN)   1
Philips   Document           Vol.       475
          Encryption (DEN)   2
Philips   Document           Vol.       468
          Encryption (DEN)   2
Philips   Document           Vol.       468
          Encryption (DEN)   2
Philips   Document           Vol.       570
          Encryption (DEN)   2
Philips   Document           Vol.       599
          Encryption (DEN)   2
Philips   Document           Vol.       600
          Encryption (DEN)   2
Charles                         1 X.3   377




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                         1 X.3   394
          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1 XX.2   608




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1 XX.2   608




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1 XX.2         608




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      1 XX.2         608




          Cross-Enterprise
          Document
          Workflow (XDW)
WalcoVan Document            3 3.32.4.1.5   539
Loon     Encryption (DEN)


WalcoVan Document            3 5.Y.5        825
Loon     Encryption (DEN)
Charles                      3           942




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      3 5.Y.7.2   976


          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                      3 5.Y.3.1   1100
          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                          3 5.Y.3.2         1100




          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                          3 5.Y.3.3         1110
          Cross-Enterprise
          Document
          Workflow (XDW)
Charles                          3 5.Y.4           1113
          Cross-Enterprise
          Document
          Workflow (XDW)
Philips   Cross-Enterprise    Vol.                 375
          Document Workflow   1
          (XDW)
moore     Cross-Enterprise       1X                293
          Document Workflow
          (XDW)
moore     Cross-Enterprise       1X                296
          Document Workflow
          (XDW)




sippel    Cross-Enterprise       1 x.1             317
          Document Workflow
          (XDW)
sippel    Cross-Enterprise       1 fig x.4.1.4-1   443
          Document Workflow
          (XDW)
sippel     Cross-Enterprise    1 x.2.1     334
           Document Workflow
           (XDW)
moore      Cross-Enterprise    1 x.2.1     335
           Document Workflow
           (XDW)




moore      Cross-Enterprise    1 x.2.1     335
           Document Workflow
           (XDW)
moore      Cross-Enterprise    1 x.2.1     338
           Document Workflow
           (XDW)
moore      Cross-Enterprise    1 x.2.1     339
           Document Workflow
           (XDW)
felhofer   Cross-Enterprise    1 X.2.2.1   346
           Document Workflow
           (XDW)
felhofer   Cross-Enterprise    1 X.2.2.1   347
           Document Workflow
           (XDW)

felhofer   Cross-Enterprise    1 X.2.2.2   349
           Document Workflow
           (XDW)
moore      Cross-Enterprise    1 x.3       352
           Document Workflow
           (XDW)

felhofer   Cross-Enterprise    1 X.3       376
           Document Workflow
           (XDW)




felhofer   Cross-Enterprise    1 X.3       381
           Document Workflow
           (XDW)



felhofer   Cross-Enterprise      X.4       396
           Document Workflow
           (XDW)
moore      Cross-Enterprise      X.4.1.2     415
           Document Workflow
           (XDW)
moore      Cross-Enterprise      X.4.1.2     418
           Document Workflow
           (XDW)
moore      Cross-Enterprise      X.4.1.2     428
           Document Workflow
           (XDW)
sippel     Cross-Enterprise    1 x.4.1.4     434
           Document Workflow
           (XDW)
felhofer   Cross-Enterprise      XX.1.1      515
           Document Workflow
           (XDW)




felhofer   Cross-Enterprise    1 Glossary    936
           Document Workflow
           (XDW)
felhofer   Cross-Enterprise    3 5.Y         942
           Document Workflow
           (XDW)
felhofer   Cross-Enterprise    3 5.Y.2       957
           Document Workflow
           (XDW)




felhofer   Cross-Enterprise    3 5.Y.2.1     978
           Document Workflow
           (XDW)



felhofer   Cross-Enterprise      5.Y.4      1112
           Document Workflow
           (XDW)
felhofer   Cross-Enterprise      5.Y.5      1138
           Document Workflow
           (XDW)
felhofer   Cross-Enterprise     5.Y.5.1             1153
           Document Workflow
           (XDW)




felhofer   Cross-Enterprise     5.Y.5.2             1158
           Document Workflow
           (XDW)




felhofer   Cross-Enterprise     5.Y.5.3             1169
           Document Workflow
           (XDW)
felhofer   Cross-Enterprise     5.Y.5.4             1173
           Document Workflow
           (XDW)


felhofer   Cross-Enterprise     X.4.1.2
           Document Workflow
           (XDW)
felhofer   Cross-Enterprise    1 Intro and Sec 127 and
           Document Workflow     X             269
           (XDW)




felhofer   Cross-Enterprise    1 Intro and Sec 137 and
           Document Workflow     X             278
           (XDW)
felhofer   Cross-Enterprise            throughout
           Document Workflow
           (XDW)


felhofer   Cross-Enterprise            throughout
           Document Workflow
           (XDW)

Charles                           1                 1055




           Cross-Enterprise
           Document
           Workflow (XDW)
Philips    Cross-Enterprise    Intro                 177
           Document Workflow
           (XDW)
Philips    Cross-Enterprise    Vol.                  379
           Document Workflow   1
           (XDW)



Charles                           1 5.Y.3.3         1110




           Cross-Enterprise
           Document
           Workflow (XDW)
felhofer   Cross-Enterprise       3 5.Y.3.3        1109
           Document Workflow
           (XDW)




moore      Cross-Enterprise        X.4.1.2          411
           Document Workflow
           (XDW)
Karen      Cross-Enterprise    App XX.1       500-600
Witting    Document Workflow   x
           (XDW)               XX
Charles                           1 XX.3            710




           Cross-Enterprise
           Document
           Workflow (XDW)
Charles                           1 XX.1            605




           Cross-Enterprise
           Document
           Workflow (XDW)
Karen      Cross-Enterprise       1 X.2.1     General
Witting    Document Workflow
           (XDW)
sippel    Cross-Enterprise       1 appendix aa           460
          Document Workflow
          (XDW)




sippel    Cross-Enterprise       1 x.4                   395
          Document Workflow
          (XDW)
Karen     Cross-Enterprise
Witting   Document Workflow
          (XDW)


                                 3 5.Y.2.2.1     1075…
Karen     Cross-Enterprise    N/a Open Issues    General
Witting   Document Workflow        and
          (XDW)                    Questions
Charles   Cross-Enterprise       1
          Document Workflow
          (XDW)




Malcolm   Cross-Enterprise
Newbury   Document Workflow
          (XDW)
felhofer   Cross-Enterprise    3 5.Y.4   1112
           Document Workflow
           (XDW)




felhofer   Cross-Enterprise    3 5.Y.3   1097
           Document Workflow
           (XDW)




Charles                        1X        316




           Cross-Enterprise
           Document
           Workflow (XDW)
Issue



There should be a common thread of examples across the
entire profile. This would facilitate the readers
comprehension from the use cases, to the WF document
structure and sample XML.



I would like to see the contents of this section reformatted
into a table. Each row of the table would contain an
attribute. The columns would be attribute name, attribute
description, and optionality. Or, if that detail is just
borrowed from CDA R2 or somewhere in the PCC spec, just
point there.



This question came up during a review of a new QRPH
content profile currently in Public Comment…

Many content profiles in PCC & QRPH specify that a
Content Creator actor either “may” or “shall” be
grouped with an XDS/XDR Doc Source or an XDM
Portable Media Creator. When this grouping occurs,
the requirements for “Medical Document Binding”
come into play, as specified in PCC TF-2:4.1, such that
several metadata attributes are mapped from
attributes in the CDA document.

With the publication of the Metadata Limited
supplement, we will have an XDM Portable Media
Creator with ‘lower’ metadata requirements than the
XDS/XDR Doc Source.

How does this affect the ‘bindings’ specified in the
PCC TF? Does it mean that a Content Creator grouped
with an XDM/PMC must only map the ‘limited’
metadata attributes? Ie the mapping bar is higher if a
Content Creator is grouped with a Doc Source than
with a PMC? Is there somewhere where this should
be documented?

Follow-up to Felhofer comments: An example is not a
specification
Is there anything implied by order in the structuredBody?
Does the order in the XML imply the order of the steps? If
not, what does?
Why do we have this stuff? PCC assumes people have
read/understood CDA. If not, we should have a general
introduction that is not owned by ITI, PCC or QRPH




The specification for the contents of the Body needs to
identify the sections (Control Info, Input, Output), and then
within each section, identification of the entries within that
section. . For each, I want to know its name, description,
optionality, ,data type, cardinality, defined values (if any)...
Look at how Sections & Entries are specified in the PCC TF

I want to know code values, template IDs, if sections need a
unique identifier, ..


I object to the reasoning in the introduction for the existence
of this profile. The introduction mentions the implementation
of stateless and simple gateways as the primary reason for
the profile to exist. Stateless: current XCA gateways can also
be stateless, under the (reasonable) assumption that the
transformations on documents and their metadata are
stateless. Simple: simple is a judgement call. I could argue
that the current split query/retrieve approach is simpler, since
it separates concerns. Implementing XCF would also yield a
different operation model, especially for existing XDS
consumers (see XCF002). In general, the introduction uses
many subjective adjectives that, from a first-read
perspective, seem to be there to stress the importance of the
profile in absence of a number of use case descriptions.




Relations (associations) are not sent in a FindDocuments
response, and can hence not be sent in an XCF response.

"The XCF Profile allows for stateless gateway
infrastructures." XCA also allows for stateless gateways.
The reasoning about new document IDs is broken. The XCF
transaction would violate the principle of repeatability if the
intermediate DocIDs as well as the resulting docID are
generated on the fly. A second XCF request with the
resulting docID will not be served well by the gateways, if
they do not hold state in the current situation. The only way I
see this might work is to transparently transform document
metadata and the document itself during transit, but keep the
document uniqueIds intact. If we really wanted an audit trail
or a record of the transformation, the only thing that I can see
working is to add an XFRM related document for every
document that is transformed in the transaction. However,
that implies that for every request for a cross-community
document, the source domain gets a copy of the XFRMed
document, which might bloat the registry on the source side.
Note that this is not related to XCF only, but to any gateway
in XCA or XCF that transparently applies document
transformation (even aside from the fact that any signatures
or hash values are invalidated). However, since the claim in
this profile is simplicity and statelessness, this issue surfaces
more in the XCF than in the XCA context. XCA (in my
The use case can equally well be solved by
understanding) and the profile text does not explain the
superiority of XCF in this case. The dynamic document entry
can be served up to the initiating gateway through a bit of
metadata translation, hash and size are irrelevant (it's a
dynamic document after all), and the subsequent retrieve can
be transformed at will using a similar rule set. The usual
access control rules would guard against getting the
document, for example because the original query will not
even yield the document metadata including the (unchanged)
uniqueId. If the uniqueId is changed, there is no way to make
the cross-community fetch repeatable (see above) and hence
the stateless aspect of the gateway would be violated in both
the XCA and XCF implementation


Similar reasoning as above. The XCA query will yield at
most 1 document which is later (potentially) retrieved.

Use cases cover dynamic documents only. Given the
problems with static documents as described above, we may
want to limit the profile to just dynamic documents.

This section most explicitly mentions the data transformation
that should take place. However, in any XCA context, data
transformation might happen. Do we really want to state the
transformation requirements this strongly?

hash on document is not stored for dynamic documents

any DSGs are invalidated by transformation

an error code "NoExplicitConsent" would be very helpful to
implement "break glass" policies
patient ID and document type limitation also guards server
implementation (more than Consumer, I suspect)
document hash not stored for dynamic documents
(impossible). Dynamic documents are the only listed use
cases.
I concur that no explicit error code should be sent for bad
IDs; however, one that states NoConsent or similar helps
consumer systems provide a UI that users can actually use
(for break glass logic, for example)
Other parameters... shall not be used. Probably a left-over
from the time when this transaction was a limited
FindDocuments query. The current wording inhibits
extension later and adds no value (additional parameters
shall be ignored is already a rule for XCA gateways).

The risk mitigation section says to return no documents
instead of an error code
use of SOAP/MTOM. Per the current XDS specification
either request and response will both use simple SOAP or
SOAP/MTOM. Mixed scenarios are not allowed.

base64 encoded text in sample suggests simple SOAP

given that submission set metadata is nevery returned, there
is no way to get to the sourceId and hence the unique
identification of the source of the information, which means
the information cannot be traced back to a source during
retrieval or later (for audit purposes)
"if no consent is found, the RG shall respond with zero
documents". Wording to suggestive/strict.

I do not understand the reasoning here. We explicitly
disallow sending back the custom metadata for a document.
When a suitable working relationship exists, these properties
may carry value that is of interest to both parties.

Sample for a stable document. Since the supplement
exclusively deals with dynamic data, suggest to change to a
dynamic document.
XDSUnknownPatientId not used in XCF (if changes above
applied, per rationale in the supplement itself)
Note that DSG applies to a specific document. If the
document is transformed the original signature is invalidated.
What this effectively means is that any document is signed
(again) by the RG,losing the original signature

This way of specifying the audit message hides some
problems. For example, I would argue XCF is a combined
query/retrieve and hence the documentUniqueIds should be
added to the audit message as for ITI-43

HLv3 is not mentioned. It is discussed later in the Closed
Issues, but those will not make it into the integrated TF
version.
"(this needs to be validated)"


Link to risk analysis points to work section on FTP site.


The transaction explicitly states enhanced ACK mode, but
does not futher specify its use. Enhanced ACK is not
consistent with the transactions in ITI-30, as far as I can tell.

The supplement only targets moving documents. It is not
possible to move submission sets. However, if the
submission set is not moved, moving a document underneath
it will violate registry constraints. This can be solved by
requiring the submission sets associated with the moved
documents (which should all refer to the same patient as the
submission set) to move as well.

The supplement only targets moving documents. It is not
possible to move folders. Since the folder might be
referencing documents with multiple, different
sourcePatientIds this may not be possible. If that is the case,
a constraint violation of the registry rules occurs. However,
if all documents in the folder are moved, it makes sense to
move the folder as well. The latter is probably the most
common case, since when multiple institutions are
collaborating, the mismatch between the identifiers is likely
found earlier. I would personally opt for specifying behavior
instead of letting it be up to the implementor, at least as good
as we can at this point.

Audit table lists all three patientIDs as having the exact same
structure. A field to distinguish them (at least the"to" from
the "source" patientID would be welcome

our strong recommendation is that, after proper reformatting,
the final home for Section Definitions is in the PCC CDA
Modules Trial Implementation Supplement



This profile highlights but does not resolve one of the
biggest problems with XDS – the definition and affinity
domain compliance to agreed workflows.
consider adding more description to the various steps so that
the actions required are clearer



Replace XDW format. See replacement document
This profile invents a new method for defining
workflows but IHE mission is to use existing standards
wherever possible. And yet there does not seem to be
any reference to BPMN or BPEL – the main standards
for workflow or business process description.
The example (see attached document line 970) is not useful.
Examples should use style "XML Example" .

this section is not helpful. Is there something unique to this
document or are you just restating the rquirements of CDA

Open issue 10


In the Section: XX.4 Healthcare professional Monitoring
Workflow several errors have been identified:
- Line 848; same comment as comment made on Line 654
(use of Folder)
- The overall english flow needs editing

Suggestion for improving figure… figure has no figure title.


This is not a UML diagram. Typos


Diagram is unreadable in printed form.


ALL figures, incl appendix, must have a Figure # and title


"Any Workflow Content Folder shall contain no more than
one approved Workflow Document" - is the opposite also
true, any Workflow Document shall be contained in exactly
one Workflow Content Folder?
In Section: 5.Y.2.1.3 CDA Header Relationships, None of
the relationships are meaningful for an XDW document. Not
even Replace, unless one consider the case for coorecting
workflow "errors". Append and Transform are not relevant.
As Replace is not used, SetId cannot be used to include the
Workflow Instance Id as a copy of the Id contained in the
Folder ID. Is the Workflow Instance Id needed within the
Workflow Document Object ? It seems that it should be to
avoid a specific additional query to access the Folder Id from
the most current workflow document (need to check the
query returned metadata).
"It is up to each specification of the specific workflow to
analyze the need and frequency to search for the list of
workflows…" …this statement made me think about what
the template for an 'content profile' would contain. Can that
be concisely described in this document? There are also
other considerations (eg do referenced documents get put in
the Folder? back-linking considerations, etc)

section numbering issues - put the Options stuff together -
see Supplement Template

section headings



I included my opinion regarding many of the open issues and
questions in the attached document.

This statement should be more specific: "Such workflow
definitions are simply referenced by a unique identifier."


In Section 5.Y.2.2.1 Input Section, the data contained is only
the reference to a Document by use of the DocumentId. This
is insufficent if one want to avoid to have to perform a
requery to the XDS Doc Registry for each document
referenced. It may be useful to get additional metadata such
as document type, document title, document class, service
date/time, healthcare facility type, author...It may also help
when a workflow document is being displayed using the
local CDA style sheet (a more thorough discussion of the
human readeable sections of the CDA should be included).
However, there is a small risk that the referenced document
may have been deprecated. The behavior in case a
referenced workflow document which has been deprecated
may have to be specified in XDW (the repalcing document
should be used ?).


This profile proposes a method for generating and
tracking the status of a particular instance of a
multivendor workflow, but does not propose any
method of controlling application subscribing to a
published definition of the workflow, and instead
relies on a manual process of agreement. This stokes
up security problems for the future.
It is not clear what the need is to reference: "in PCC TF-2:
4.1." A number of statement do not apply, some do, several
are missing.
The section referenced for the profile options (X.2) in the
Table X.2-1 XDW - Actors and Options and the options
defined in the section: X.2.2 XDW Content Profile Options
are inconsitent. The earlier ones reference ITI TF-1: X.2.2.1
and the later reference:
X.2.2.1 View Option
 See PCC TF-1:3.4.1.1
 See PCC TF-2:3.1.1
X.2.2.2 Document Import Option
 See PCC TF-1:3.4.1.2
 See PCC TF-2:3.1.2
roadshow needed




Compare to QRPH RPE


The Introduction should contain a paragraph which explains
what is meant by the terms link, unlink, merge and unmerge
and how each is addressed (or not addressed) in this profile
and XDS.




Publication should be done to the XDS Document
Repository and XDS Document Registry

Figure X.4.1-4 should use a similar approach as Figure X.4.1-
3 to show the change, i.e. use a "cross-out" over Doc-34245
on the left under Patient A and add it into Patient B - rather
than a "?" which is not instructive.
The summary of IHE support for encryption is so useful that
we may want to consider creating a Vol. 1 section for it,
outside of this profile.


Table 1 in the second column (all rows) the phrase "data
concerns …" does not explain anything to me
Second sentence is misleading.

Typo in first open issue


I don't understand this paragraph or its purpose. "It is
recommend that in case of encryption… there is choice for
such a recipient."
Last two sentences are confusing and seem possibly in
conflict "Media may amongst others include… option shall
be supported".


The phrase "and options below." is not clear enough. Be
more specific about where the options are described.

Exceptionally well written supplement.

grammar fix: remove the comma in the middle of this
sentence (ie no comma between scenarios and which-->




"that utilizes pre-negotiated processing to conceal
differences" - I do not understand what pre-negotiated
means. Is this a business agreement that needs to be in
place before ever implementing XCF? So this creates a 1:1
relationship at configuration time then such that no
negotiation (such as sop class negotiation) is required?
The paragraph in X.3 should be moved into X.3.1 since it is
about a specific grouping, and since you talk about more
than one profile interaction (eg X.3.2 has nothing to do with
an XDS doc consumer).
Suggested clarification-->




I think this sentence can be omitted. It has nothing to do (I
think) with a Responding GW in an XDS environment.

the sections in this Supplement need to match the
Template so that when all of the Supplements in any
Domain are lumped together that all of the sections line up
… I think maybe this should be in "Use Case" starting at line
270?
I have not seen this in Table form before, I kind of like it,
very clear
grammar fix:

typo:
is this too much detail for a use case that you are arguing
against? It is good background info and worth keep,
possibly just reduce?
if data discovery and retrieval across data processing
gateways is split

some additional complexity max occur


The section "Usage Restrictions" should not be a subsection
of X.3 "XCF Actor Groupings and Profile Interactions"

Since you state that the XCF profiles assumes, these things, I
think they need to be defined, ie, specifically what are the
"document properties" that must be known in advance? if
the result data set hast to be "characterized", what are the
parameters of that charaterization? what number of
documents is "feasible" to be returned in a single response.
Is 2 OK? 20? It sounds like this is a number that each Resp
GW gets to determine for itself?

"throwing an error"

Essentially, these two sections have the same name "XCF
Process Flow" and "Process Flow" Should X.4 be "XCF
Use Cases and Process Flow"?
Suggested rewording:


spell out the entire profile name; most readers won't know
this acronym
The diagram still contains the old transaction name (Simple
Query)
This paragraph aso contains profile acronymns that should
be expanded (BPPC, XUA).
suggested rewording:




Does 'canonical format' here mean "as defined by the XCF
profile" or "as agreed between the Init and Resp GW" or
something else?
Requirements/Recommendations

M3: When you say "Application shal have the ability to
verify the SHA1 hash…" do you mean implementations of
Init and Resp Gateways. If so, specifically identify that as a
rqmts for those actors. If not, I'm not sure who M3 applies
to.
M4 and M5 and M7 sound like they should be included in
expected actions of the transaction.
M7 is contradictory in that it contains shall language in the
beginning of the paragraph, but the paragraph ends with
"This mitigation is optional."
suggested rewording:

suggested rewording:




After "fish for data." We THINK that maybe there should be
a paragraph break after this sentence and then the description
with begins with "The following migitations…" actually
describes the next paragraph.
T4 I'm not sure who is responsible for giving the ability of a
human requestor to fetch the original document (presumably
untranscoded). It seems like this should be encoded in the
by the Initiating GW in the Request message so that the
Responding GW knows to respond differently than normal
(ie not transcode the document.

Limit the mitigations to those are specific to this Profile
because otherwise the fluff tends lead readers to just pass
over the entire sections.
Remove the header for Appx A from this supplement since
you are making no changes to that section.
Query table: Optionality column - R/O for client or server or
both??
fix TF references; in all cases there should be a dash (-)
between TF and the volume number. Eg ITI TF-3:4.1-5
suggested clarification for $IncludeRelatedDocuments
parameter-->




rewording suggestion:

Regarding this requirement: "If the homeCommunityId is an
identifier for another community that is supported by the
Responding Gateway, the Responding Gateway shall
forward the request to the Responding Gateway that is
responsible for that community." ...I did not see a similar
rqmts in XCA (but may have missed it). Do you really
intend for every Responding GW to maintain a list of other
Resp GW homeCommunityId values and the endpoints
associated with them?
suggested clarification:




In the homeCommunityId section above, you indicate that
unknown or missing homeCommunityID is also an error
condition
Fix TF reference to add a dash

You have text in 3.Y.4.1.2 indicating that the Resp GW
determines what's "related" based on local policy. That
should be here as well. If you don't want it in 2 places, I'd
rather see it in Expected Actions.
Provide a more explicit explanation of what would trigger a
Transcoding Error. Here you refer to 3.Y.4.2.5, which
contains no add'l details for this specific error. In tabel 4.1-
11 in Vol 3, you indicate that the error is triggered when a
Responding GW cannot provide the doc due to a
transcoding/translation error.
"The response message may use SOAP 1.2 MTOM with
XOP…" Did you mean "…shall use SOAP…"?
Fix TF reference

Fix TF reference

Remove this reference; the same reference appears 2 lines
down
"Defined relationships between these DocumentEntry should
be expressed as association objects." Is it "should" or
"shall"?
"Reply with a single message that contains a single document
entry object for each document that matches the given query
parameters up to the maximum number of documents that
could
be transmitted within a single message. "         I am confused
by this statement. The beginning implies that it's one
message per document, but then you say "up to a maximum
number of documents that could be transmitted w/in a single
message. Please clarify.
"If the size of the response message exceeds a configured
value…" Here and elsewhere (in error reporting), you
speak of a 'configured value', but it's not clear (to me) what
this represents. Is it a number of documents? Choose one
location (probably here) to clarify.
"If no valid patient consent could be found, the Resp GW
shall…" You imply here, and elsewhere that patient
consents are always present in an XCF environment. But
you don't mandate that in Vol 1.
suggested clarification:


I think you should omit this example. If, in fact, the Resp
GW is operating in an XUA environment, it would be the X-
Service-Provider actor throwing the error, not the Resp
GW…right?
Since this is a "shall", I think you have to be explicit about
which metadata attributes the Responding GW is not
permitted to return if it is exchanging encrypted documents.

The Responding Gateway shall "Return zero documents if no
valid consent for the patient was found". This requirement
implies that you are always operating in an environment
where XUA (or equivalent) is present. I didn't think that a
Resp GW must always check for a consent before returning a
response to a fetch request.

suggested clarification--> I'm not sure if it changes your
intent. Also, is response size always # of documents? If so,
you should state that.




Rather than saying the audit messages should be "equivalent
to" those for Stored Query, create the table with the audit
message rqmts, as is done for other transacions

The notes that appear beneath this table and some of the
codes in the table do not appear in Vol 3 final text released
in 2010. Did you start with the text in the XCA TI
supplement?
Does Note 2 apply to the XCF transaction? If so, the text
would need to be mofidifed.
typo:



There are no additions at all to the XDM Volume 1, only to
XDR??? This new actor does not even get mentioned?


I think the list of metadata attributes is way too much
detail for the intro
Intro: says that eventually some or all of these use cases will
be inserted into XDR and XDM. Which ones and when?

grammar fix:




missing word:




Vol 1 Process Flow: I realize the process flow is pretty
trivial but new actors should be added to the Process flow
charts also for both XDR and XDM
I think you mean for the name of this table and the
column 2 heading in this table to be "Meaning of code
in Porable Media Creator column"


The table of coded values R, R2, O, N/A gives
incomplete definitions and will lead to the same
problems we have in PCC. These should be defined in
full somewhere and then referenced from here.
Same comment applies at line 466.
Especially problematical is the short "Required if
known" which is interpreted by many as: My
application does not record it, therefore, it is not
known, therefore, I need not send it.

You have just invalidated my implementation of an
XDM Portable Media Importer. All of that data that
you told me "shall be there" will no longer be there.
You just made a major change that is not backwards
compatible.
Please, do not do this. If you are going to make such a
change, you need to radically alter the data so that
my perfectly good application does not try to import
the data from this creator.

Like any kid who has been given a piece of candy
every day, I am now upset that you are no longer
supplying it.
really an XDM comment - why would xxx:author Institution
be Optional everywhere? Especially for this limited meta
data and just for XDM data flying around, wouldn't you want
to know where it originated?
I'm an XDR Document Recipient implemented using
the original specification. I have not declared this new
option. Someone buys a meta-data limited document
source, does not read the fine print, plugs it in, and
my Document Recipient goes belly up. Now, thinking
of implementations, maybe my Document Recipient
does not log enough information to help understand
what happened. Maybe the person who plugged it in
cannot get enough information from the Document
Source to figure it out.

Is there something in these changes that makes this
impossible? I assume not.

Is there something that can be added to make it
easier to avoid or to detect? Remember that I'm not
an XDS/XDR expert. I think of making a more obvious
change to the message so a Document Recipient that
did not understand meta-data limited data but
received it would certainly detect something and not
get into limbo.

Would it help to require that a Document Recipient
use a separate URL for this? Can we modify the web
service or XML somehow that the message is
obviously different.


Your table has separate columns easy as possible on
I know, you want to make this as for XDS Document
Source and XDR Document source. You really only
need one column for this: Document Source. That
allows you to reuse this transaction no matter how
many profiles may use it.
Likewise, remove the XDR prefix on the heading of the
last column. You are giving me the requirements for a
Metadata-Limited Document Source. Next year,
someone will want to put this actor in the Foo profile.
You don't want to update this table everytime
someone does that.


OK, the Document Recipient gets that the Metadata Limited
flag is set and checks the data set accordingly… if all of the
R2 are not there, then what is the Expected Action?
missing word




typo:




If I look at the examples in the existing TF, it looks like
there is an extra "urn:uuid" in the example.




we are defining a new Code just for this one element, really?




same as previous:




Maybe this was the "easter egg". One instance of
"Metadata Challenged Doc Source" survived in this
table.


why do we have the weird mix of fonts in some
portions of this document? …one example here.
same as previous:




fix format of TF reference to remove the dash
between ITI and TF




so every patient id type element is now R2, as are the author
and institution elements. There is no reliable way to identify
this patient which is required??? The unique identifiers are
still Required. (e.g., entry UUID etc).

suggested rewording:




Should we consider inserting a message in large font
at the beginning of Vol 2b for ITI-32 to point
implementors to this supplement rather than the FT
contents for that transaction. Without it, there is no
hint that the rqmts for XDM are essentially different
this year.
Backward compatibility: isn't it possible that we just broke a
whole bunch of XDM and XDR current implementations
because they will have no clue to go look for this new
MetaData Limited attribute and then change the data
requirements; rather they are just going to reject data sets
with an error status.
typo


"In many implementations, the XAD-PID is determined by
linking local patient identifiers (i.e., those used by the
Document Source) with identifiers managed by the XAD
patient identification domain."

"many implementations" of what?
typo
Why is this a separate Profile? Could it not have been an
option to an existing Profile? The scope of this XAD-PID is
very similar in nature to Meta Data Limited sources and, yet,
that one adds an Actor to an existing Profile. Under Closed
Issues XPID.1) there is zero explanation....

define the acronym XAD-PID before you use it


"may (or more likely will)"


"In other situations PIX or PDQ are typically used to
manage the correlation of identifiers across the XDS Affinity
Domain. A Patient Identity Cross-Reference Manager actor
or a PDQ Supplier actor provides each Document Source
and Document Consumer a match between the patient’s local
identifier and the common XAD-PID."

PDQ is not really a solution for finding a match between a
local patient ID and aa patient's XAD-PID. This profile
assumes that Doc Sources put good values in
sourcePatientId. If Doc Sources get their patient ID via
PDQ (or some non-PIX way, and they don't have a "good"
value for sourcePatientID, how does this profile work?


PIX and PDQ acronyms


capitalization question - should all Actor's proper names be
capitalized?

suggested rewording




"In this case, the XDS Doc Reg musst enforce its entegrity
rules and consequently… alerting actions"
Assumptions need to be reworked to be requirements. In
addition, separate requirements that apply to the PIX
Manager actor from the rqmts that apply to the Affinity
Domain in which the PIX Mgr and Doc Registry reside.




in case anyone cares, just as general feedback, I think the
illustrations/figures are incredibly helpful in understanding
this profile
Suggested rewording:
Remembering that the readers of this transaction
specification may not have read Vol 1, we have to clearly
refer to 3 different Patient IDs associated with this
transaction. The terms used to refer to these must be
consistently used throughout the Vol 2 text (ie w/ no
variants). In comments that follow, I am going to make
changes in line with the names below. If other names are
chosen (ie those in the note starting at line 431), fine, as long
as they are consistently applied.

Definitions:
"XDS Affinity Domain Patient ID Assigning Authority"
refers to the single Patient ID Assigning Authority (OID)
recognized by the XDS Doc Registry.
For a given patient (eg Patient P),

"XAD-PID" is the value of P's Patient ID as known by the
"XDS Affinity Domain Patient ID Assigning Authority". In
this transaction, that XAD-PID exists in the PIX Manager
and is the XAD-PID for which the Document Registry will
accept document submissions for Patient P.

1. "local patient ID" - this is the patient ID that Patient P is
known by in his local domain. This value is placed in the
"sourcePatientID " metadata attribute for Patient P's
document(s) from that local domain when submitted to the
Doc Registry.
2. "pre-relink (or original) XAD-PID" - this is a patient ID
Reword to be a trigger (not expected action) :




suggested rewording:


suggested rewording:


This section only contains specifications for the contents of
PID-3 and PID-5. Are are you deferring to HL7 v2.5 for the
rqmt for the remaining attributes, or do you want to point to
an IHE definition of a PID segment for HL7v2.5 eg. in ITI-
30: ITI TF-2b:3.30.5.3?
suggested update:
suggested update


As above, do you want to point to ITI TF-2b:3.30.5.5 for the
IHE definition of the MRG segment for HL7v2.5, along with
your specific rqmts for the use of MRG-1?
suggested update:




suggested update:




The paragraph beginning at line 427 addresses how
transactions are linked together for this Profile. This
information belongs at the Profile level, not at the
Transaction level. The behaviour of the system on
subsequent transactions does not belong in Volume 2 of this
transaction. (It makes this Transaction un-reusable by future
Profiles.)
Suggested updates:




Suggested updates:




editorial:
You indicate here that a link change operation may update
many patient records. Is one audit msg sent per change? If
so, state that.
suggested rewording




Is there any issue with the feed (ITI-8) being an HL7v2.3.1
msg and this being HL7 v2.5?

Section number errors


You say, "The Document Registry shall version updates to
Document Entires according to the mechanism described in
Volume 3, Section 4.1.15 – Metadata Versioning Semantics
(IHE Technical Framework Supplement - XDS Metadata
Update)."

This is the only reference into the MU supplement in Vol 2.
However, in the intro in Vol 1, you say (line 244) "...these
updates must follow the same technical requirements and
behaviors defined in the Update Doc Set transaction as each
change must results in a new version of the affected object."

I think more extensive references into the ITI-57 details need
to be made here to specify the behavior of the XPID Doc
Registry when it updates a doc.
Because XPID introduces a second method to trigger an
update of meta data in the Registry, this supplement needs to
be clear when XPID is used versus Document Administrator
who updates the MetaData in the Registry.

suggested rewording:


It would be nice if this IHE encryption overview, as well as
the Use cases in the following section, found a permanent
home in Vol 1, probably as an appendix. In its current
location, it would get lost when this profile goes to Final
Text. I see the Use Cases will be copied to X.3.1. What
about the overview?
suggested clarification:
Several times in these 2 sections, you identify the Document
Encryption profle and XDS Media Encryption option as
"NEW". You may want to remove the "NEW" label, as it
will soon be outdated, and then you don't need to update the
text later.
according to dictionary.com, anonimization is not a word
(nor is anonymization). However, if it were, I think it would
be spelled with a "y". (as you do with "pseudonymization"
that immediately follows in this paragraph)

suggested rewording:

In volume 1, they need to succintly state what
interoperability problem they are solving. The Introduction
does not count because it will go away; it will not appear in
final text.

The introductory material above this point does not count as
you state it will be removed and not published in Final Text.
I am not advocating for keeping all of it, but keeping some of
it

I purposely chose not to read the Introduction because the
supplement told me it would not be part of Final Text.
Therefore, as a reader two years from now, that material
would not be available to me.
You use the word "certain" rather than "partially" in Section
X. I think that was your intent. See suggestion:


This profile does not specify any specific policy aspects to
allow for policy ranging from regulatory, organizational as
well as privacy or consent policies (e.g., BPPC).

Wording

typo: missing comma

Wording in the sentence + note 2 is not clear. Does the note
refer to a case where encryption is appropriate using existing
means or where it is not appropriate using existing means?

typo:

Several times in this section you refer to "This profile, but
the profile is never named. I recommend making the
following change to the beginning of the section, and then
subsequent references to "this profile" will be ok.

missing comma

You reference FIPS. Is this known to everyone with an
explicit reference? Is this US specific? If so, should there be
reference to something not from the US?
awkward wording




What does it mean to "improve availablity"? If you are
improving something, what are you basing this improvement
on? Improve with respect to what?
In the current ITI Vol 1 Final Text, there is no section
"16.2.5"; here you add section 16.2.6 as the next section.
Should "Media Encryption option" section be 16.2.5?

Section 3.32.41.1.2.4 below refers to DICOM standard Part
15. You should add that to the list of references here.

I believe you are adding section 3.32.4.1.2.4 and .5 as new
sections. Add an editor's box above these sections indication
"Add these new sections"
suggested rewording:




reference to DICOM Part 15 Appendex. Please be
explicit. Which appendix? If you mean Appendix B,
then publish that.
In Vol 2b Final Text, section 3.32.4.1.4.1 already belongs to the BPPC Enforcement option. You reuse that section number he

S/MIME S/MIME ?? Listed twice??

"...comply with the secutiy process as defined in the
DICOM Part 15 Appendix..."

I'm not sure which "Appendix" you are referring to
here. In Part 15 (2009), there are no appendices.
Annex B.8 does contain a section on "Secure Use of
Email transport", but that Annex states "This profile is
separatae from the underlying user of ZIP File or other
File Set packaging over email."


The first bullet item talks about the "following CMS
options below". I understand you discuss CMS things,
but exactly what options are you referencing? These
are not named options as in our profiles, are they?
I'm just a little dense and need a 2x4.
This is the first time (I believe) that you list the
mandatory encryption algorithms. In this location, and
every other place you mention these, it would be
helpful to replace the text reference with a table that
includes the OIDs Given that the OIDs are required for
the encoding, you will be doing this lazy reader a
favor.
"If the Portable Media
Importer actor verifies signatures then it shall support the
RSA algorithm."

It sounds like the PMI can choose to support verifying
signatures, or not. Is that correct? What if the PMC signs
using RSA?
suggested clarification:




suggested rewording (a transaction like ITI-32) does not
belong to one profile):




"is expected" or "shall" in the following?

"The Portable Media Importer actor is expected to support
the algorithms and related parameters belonging to the
certificates for recipients it intends to support."

suggested rewording:
"should" or "shall" in the following?

"The Portable Media Importer actor should also support
HMAC-SHA256 for the key derivation process. "

The introduction to section 5 states: This section follows the
documentation pattern found in the IHE PCC Technical
Framework. The reader should be familiar with the IHE
PCC Technical Framework.

Because the material presented here does not follow that
format, does it belong in Section 5, or does it warrant a new
section in Volume 3? The material is important; it appears to
be misplaced.
extra word:




What does it mean to handle the decrypted content with
care? Should I not drop it?




This section is a good place to put the table about
encryption. A new reader thinking about encryption is likely
to start with a profile named encryption. This would then re-
direct them appropriately.
Remove the "(not preferred)". It gets into too many policy
debates unnecessarily.
The tradeoffs explaining our choices are a valuable part of
the closed issues. It will be part of the supplement, but it
would be nice to have it survive longer.

Looks good, other than font issue noted above for DEN


Section X seems to significantly duplicate the content of the
Introduction. While it is sometimes helpful to duplicate a
few sentences, I feel this has gone to far.
Text states a Content Creator must consume a Workflow
Document. This suggests a Creator must also always be a
consumer. I think this is likely to be the case, but is it a
requirement? Need more clarity here.

If feel like Appendix X is so intent on beating me over the
head with the minute details, spelled out over and over and
over again in various\, abstract and confusing ways, that I get
nothing useful out of it.
Some suggestions in attached document for improving the
content of this section.

Some suggestions in attached document for improving the
content of this section.


Incomprehensible, I didn't have the stomach to read
any more
REPLACE: The main structure of the document and some
elements related to its metadata and the management of its
lifecycle need to be fixed and independent by the domain or
the scenario in which it is used. The different IHE domains
and the different scenarios, in which the Cross-Enterprise
Document Workflow Content profile is applied, have to
define the specific rules of the workflows. The structure of
the Workflow Document and the general rules defined by the
ITI domain remain fixed; the different domains and Affinity
Domains can contestualize only the different steps of the
workflow and their content (e.g.: name and codes).

The use of a defined structure for the workflow document, of
a common set of metadata and of their values and a common
management for the workflow document is necessary to
guarantee the interoperability cross-enterprise.



The concept of workflow definition driving teh future states
of an XDW managed workflow need to be better highlighted.
It is also proposed to add to XDW a sample template for a
workflow definition that would be used as a foundation for
workflow profile specifications.




Is there any limit to the scope of a workflow instance? How
do we know when an instance is complete? Can an instance
be open for hours, days, months, years?
In the use cse described by section: XX.1 Use Case e-
Prescription Workflow,there a a number of minor incorrect
statments:
Line 512- The use case analyzed is not focused on the
workflow of a single document, the e-Prescription document.
It contains other documents.
Line 541- The type of references listed are not all inputs "a
section of “inputs” where the author puts a set of information
useful to understand the reason for the e-Precription (the
references of the report of the visit, the references of reports
of exams, etc.)," The report of the visit seems to be rather an
output document, rather than not an input document.
Line 557: In the step: "He checks in which step the e-
Prescription is (using the Workflow Document) and he may
checks the potential interactions of the active substances
prescribed." one need to discuss avoiding the double
dispensation, as the issue is mentionned in the introduction.
Line 566: Why would the pharmacist requery for the
workflow and the advice document he just produced: "When
the pharmacist dispenses the items, he queries and retrieves
the Workflow Document, the e-Prescription Document and
the Pharmaceutical Advice Document of interest and if all
the information are correct he can dispense the medications
prescribed."
typo


what about outside of affinity domain?




Is there a requirement that Creators be able to deprecate
documents?



in a very generic manner, consider copying a portion or
reduced (or currently similar) section 5.y.5 from Volume 2
here; as it is currently it is not really normative for Vol 2 and
is basically a generic use case
Do your sections have unique identifiers?
Following the list of bullets relative to the properties of the "a
common, workflow-independent interoperability infrastructure", a
graphics would help the reader better visualize the points made.
This graphic is part of an XDW overview slide deck that was tested
with some audiences during public comment and was proved
effective.
The use of XDW requires the specification of a workflow
definition by the different workflow environments where
XDW will be used. The current XDW profile should better
present the overall architecture within which XDW is
intended to be used.




The example figure in the referral use case should be
extended (or a new figure added) to explain in the example
the parts which are related to the the workflow definition and
those that are supported by XDW;
A comment I have regarding the basic technology
selection for document encryption is that perhaps
using the common ZIP format rather than the chosen
combination of MIME/CMS wrapper will provide for
greater efficiency in implementation with reduced
processing and storage requirements for documents.
There are a number of benefits ZIP can provide that
should be considered for this encryption need.




Having participated in the t'con last week, and since
discussed the porposal in the IHE-UK meeting today,
there was universal agreement that the lack of any
"forward/future" aspects to this profile severly limit
its functionality. Whilst it has limited use as a
RECORD of workflow, the name "Cross Enterprise
Document Workflow" had led us all to believe that it
would be doing much more than record past steps,
which is what we had hoped and expected it to do. In
particular, it is most confusing that a "content" profile
is (a) given the name "workflow" and (b) given a 3
letter acronym, which by convention in XDS should
relate to a transaction-based/workflow profiles rather
than merely a content profile.
Doesn’t the Content Creator need to be a Content
Consumer to? In order to replace it must first
retrieve. (same as prior comment)
Says "If all participants are part of the same XDS Affinity
Domain" but isn't that required? The only binding is with
XDS, so seems like a weird "if" clause.
Suggested improved wording in the attached document.



Parenthetical remark is the main point, pull out of
parenthesis and probably make the first point, deleting the
rest.




How does discussion of APND and XFM relate to a
Workflow document? It seems odd to even do these things.

"A good name/label for the folder would be Workflow
Context Folder. " - the next sentence seems redundant with
this sentence. And it seems weird to label all the same,
shouldn’t the name be more descriptive than that?

Typos, see attached doc


Typos, see attached doc


Improved wording, see attached doc


Duplicative of previously stated, see attached doc


Small improvements in the Supplement Intro:
"The Cross-Enterprise Document Workflow (XDW) profile enables
participants in a multi-organizational environment to track the steps related
to patient-centric workflows as they coordinate their activities. It builds
upon the sharing of health documents provided by other IHE profiles such
as XDS, adding the means to associate documents to a patient-specific
workflow. XDW provides a common interoperability infrastructure upon
which a wide range a specific workflow “content” may be defined. It is
designed to support the complexity of health services delivery with much
flexibility to adapt as workflows evolve.
This profile defines a shared workflow tracking data structure, called a
“workflow document” that records past steps of a workflow and maintains
the references to health information input and output associated with each
step. Such shared workflow state information allows the various
participating systems to be aware of the history (past steps) of any of the
workflows known for a patient, access the workflow current state and
remain coordinated by updating this shared document with the new steps
they have performed."
The bullet: "Facilitates the integration of multi-organizational
workflows with the variety of existing organization workflow
management systems."
is correct but needs to be extended to explain that XDW
enables peer-to-peer ( or federated) workflow
synchronization beetwen the participating workflow
managment systems in the point of care systems.
The bullet: "Leave the driving of the workflow to the health
professional. Future steps are not managed in XDW, but left to the
business layer above XDW where requests or expectations are
considered integral to the outcome of previous steps (care plans,
requests, etc.)."
is incorrect in stating that XDW does not manage future
steps. In fact XDW reference the defintion of the workflow
step to which all particpants are bound by, thus providing the
framework for participants to behave accordingly.

In the section 5.Y.2.1.3 CDA Header Relationships, replace,
append, and transform are described. It seems clear that
append and transfrom are not applicable to XDW. They
should be removed. Replace:RPLC may be relevant, but is
not discussed in any details. Is XDW requiring that RPLC
be tracked witjin the XDW document or only through the
XDS metadata.
In the process flow for the Use Case e-Prescription
Workflow, as shown by Figure XX.1.4-1. Basic Process
Flow in XDW Profile, there seems to be an inconsitency.
After the "Content Creator provides the Pharmaceutical
Advice Document and replaces the old Workflow Document
with the updated one (9,10)", it is not clear why the Content
Creator would then need to re-query for the same documents
in the following step (11,12). This query appears
unnecessary if the patient stays at the pharmacy for both
validation and dispensation.

It should be only possible to add, but not to update specific
past steps.
The tilte of this section:
"5.Y.5.3 Add clinical document to workflow"
Is not correct. It should speak of performing a new step in a
workflow which results in creating a new document.
The title and section text should reflect this better semantic.



The following section is quite confusing:
"5.Y.5.4 Get a clinical document referenced by workflow
The Workflow Document contains details of each step as
well as the DocumentEntry.uniqueId of all the referenced
clinical documents, so a single stored query is adequate to
get all the clinical document metadata. The query is needed
because the workflow document contains only references to
the clinical documents."

The explanation about the need for a single query appears
incorrect, as not all XDS document entry metadata for the
referenced documents is included within the workflow
document.



In the closed issue introduction, the terms:
step status codes, status step description, are used.
In Volume 3 the term step code and step description are
used. This is better as the code speaks to the overall step.
No status fro the step should be defined. A step when
recorded in an XDW document exists. No other status are
relevant to XDW.
In the closed issue section, an editorial improvement could
reference the workflow decription:
"This reflect the reality that in a multi-organizational
environment future steps are an “expectation” shared by one
professional with others that will rely upon their medical
judgment and the latest information to perform or not such
expected activities”.
In the closed issue section point 4 is not correctly stated,: 4.
This profile specifies no rules for controlling changes of
status.


The official term for IHE specified workflow definitions is
propsoed to be: "These will be called XDW-Based Content
Profiles.".
The explanation of the role of the XDW document should be
broaden in the following section:
"This document is used to track the steps of the workflow
which is followed, to manage the documents related to a
clinical workflow and its changes as it evolves step after
step. The Content Creator shall be able to create XDW
Workflow Document as 355 specified in ITI TF-3:5.3."
Note there does not seem to be a section 5.3 in Volume 3 of
ITI TF.
The definition of input and output documents should be
clarified and extended to include parent and chilmd
workflow documents.
"• The Inputs contains information needed to access
documents used in performing this step. For example, this
could contain a reference to a referral request.
• The Outputs contains information needed to access
documents output as a result of 370 performing this step. For
example, this could contain a reference to a report written by
a specialist."




Note there does not seem to be a section 5.3 in Volume 3 of
ITI TF.


The introduction text is misleading, giving the impression
that XCF is a perfect solution. The downside versus XCA
should explained and the upside toned down. In particular
the overadvertizing of stateless is unnecessary.

The word exchange is not appropriate. It should be access.
XCA as well as XCF facilitate multiple dimensions of
communication (trust, semantics, encoding, legislation,
authority, etc.). No need to highlight. However the fact that
only limited data can be accessed.
The word exchange is not appropriate. It should be access.
XCA as well as XCF facilitate multiple dimensions of
communication (trust, semantics, encoding, legislation,
authority, etc.). No need to highlight. However the fact that
only limited data can be accessed. The gateways are not
significantly simpler to implement as concluded bu ITI
implementers at the Toronto meeting.




Based on above comments the text should be aligned and
avoid making exagerated claims, while failling to highlight
consequences. It is important to explain that XCA remains
the generic approach when XCF is intended for nitche
applications.




Stememnt; "The XCF Profile allows for stateless gateway
infrastructures." contradicts what is expalined just before.

A statement about XCA Doc Retrieve seems incomplete and
may be misinterpreted: "(e.g., this is not trivial for XCA
Cross Gateway Retrieve transaction that only provides
document identifiers as arguments)" The connection with
the next sentence is unclear and seems confusing.
The problems listed, are not significantly different with XCF
in this section: "• Gateways have to manage the intermediate
documents and document identifiers as shown in figure X.3.2-
1. (e.g., a document query for a patient summary may result
in a matching document with ID 17). If the consumer then
requests document with ID 17 he will retrieve a document
with ID 51 (some additional complexity max occur if
document 17 is dynamic as may be the case for several
aggregated documents). This is inconsistent to the
consuming actor and therefore the gateways must hide away
all implications of the existence of intermediary documents.
This even includes the management of consistent audit trails
(e.g., for traceability it may be required to write at least the
ID and hash value of the canonical document into an audit
log. This leads to a request for document 17 that results in
document 51 and is linked with an audit log for document
24)."
The duplicative action described depend on the way things
are ilmplemented. A simple caching of a few
attributes/outcome avoids much of this duplication. There is
no need to exagerate a point, stating basic facts is all that is
needed.




The last sentence of the paragraph needs to flow from the
previous one.
The cross regional/national environment decribed is equally
well supported by XCA and XCF. This needs to be stated,
before the specifics of a use case that justifies XCF are
introduced.




In Figure X.4.2-1 Basic Process Flow in XCF Profile the
transactions that are beyond the scoep of the profile are
generally shown in dotted lines, to avoid scope confusion.

In Figure X.4.2-2 Process Flow with Consent/Policy
Enforcement and Document Transcoding in XCF Profile the
transactions that are beyond the scope of the profile are
generally shown in dotted lines, to avoid scope confusion.

Some of the security requirmeents are definitively beyond
XCF imlplementation. Is it usual to do that in a security
section ?
The bullet:
"3. With XCF the responding community’s internal
infrastructure and service deployment is fully hidden by the
Responding Gateway which facilitates all communication
aspects. A responding community may decide not to disclose
any details on its infrastructure and therefore not to provide
attributes which identify or locate its internal services (e.g.,
registries and repositories)."
is quite cryptic in what is implied. What metadata attribute
may result in this behavior ?

typo


"(this needs to be validated)"
Open issue XPID.14



typo


Footnote reference to FTP document.


reword


typo


typo


typo


suggestion


reword

reword

typo

typo

Open issue XCF002

Open issue XCF008

suggestion

unclear

typo

reword

reword

reword

reword

typo

reword
reword


reword

Refrence to FTP document

reword

reword

reword

reword


reword


reword

reword

reword

reword

Table 1 typos

Table 1 typos


Tabe 2 typos

Table 2 format

typo

unclear



suggestion

reword

usage

reword

reword

typo
reword

typo

typo

reword

typo

suggestion

dependency

reword

suggestion

typo

typo

suggestion

suggestion

suggestion

suggestion

Need to better explain the deprecation process of prior
Workflow documents.




Need to put document as plural.
In the section XX.2 Use Case e-Referral Workflow several
error have ben identified:
Line 610-- The definition is not clear as it is not the
workflow for the way a specialist works but of the way a
physician refers a patient to a specialist. "The use case is
focused on the workflow of a specialist exam (e-Referral)."
Line 611: I suggest removing the following text with little
value: "This use case, in the 610 same modality of the
previous, approaches the problem of tracking the different
steps which characterize the availability and usability of the
electronic prescription. The problems are the same described
in the previous use-case (how manage the tracking of the
steps of the workflow). The different from the previous is
that the e-Referral follow all workflow of the exam
prescribed in object and in the workflow are involved more
actors and more systems."
Line 628-- The specialist practices in a hospital, but this not
the case in many environment. the text should be
generalized: "After a few days the patient is admitted at the
hospital, the HCP consults the e-Referral and the process for
the visit starts."
Line 649-- Avoid using the term prescription in : "GP’s
prescription placer software produce twoWorkflow several
In the section XX.2 Use Case e-Referral objects:"
error have ben identified:
Line 650: It is not coorect to use the folder mechanism to
reference documents from an XDW object: "this two objects
are referenced using the XDS Folder mechanism". Replace
by:
this two objects are referenced by their document Id and it
has been decided by this affinity domain to place both in the
same XDS folder."
Line 654: Again wording misleading. Replace: "The
Content Creator provides a document folder to group all
document produced and related at the same workflow
document" by: "The Content Creator creates a document
folder to place the workflow document and choose the option
to place in the same folder all document produced and
related to the same workflow document
Line 660: The use of the healthcared need to be mentionned
as an example of patient identification. Replcae: "The HCP
asks for patient health card in order to retrieve both the
documents containing the ordered exams and the associated
workflow document." by: "The HCP asks for the patient
identity (e.g. using his health card) in order to access the
workflow document. and the referenced documents
dexcribing the specific ordered exams."
Line 665: The concept of the workflow passing from a state
In the section XX.2 Use Case e-Referral Workflow several
error have ben identified:
Line 669: Write in term of steps for the workflow, not in
term of statuses. replace: "When the patient is admitted at
the hospital, the HCP consults the e-Referral document and
the Workflow Document associated and checks if the e-
Referral is still in the step 670 placed and it has been booked
by the same health care provider." by "When the patient is
admitted at the hospital (assuming the specialist practices
within a hospital), the HCP consults the e-Referral
document and the Workflow Document associated and
checks if the prior steps in the e-Referral contains the
"placing order" step and the "booking visit" steps. placed
and it has been booked by the same health care provider.
Line 674: Write in term of steps for the workflow, not in
term of statuses. replace: "If the e-Referral’s step is correct
and the exam can take place, the HCP replaces the Workflow
Document with the updated one which contains all the
information of the previous one and a new task to describe
the current step. At this step the e-Referral passes from the
step scheduled to the step in-progress and the exam can take
place." by: "If the necessary prior e-Referral’s step have
taken place, the exam can takee-Referral Workflow several
In the section XX.2 Use Case place. The HCP replaces the
error have ben identified:
Line 691: replace throw by trhough in: "It is also possible to
manage a system of subscription and notification to
communicate the progress between the different steps
through the use of the Document Metadata Subscription
(DSUB) profile or the Notification of Document Availability
(NAV) profile."
ParticipantObject does not exist inas an element in the
RFC3881, and ParticipantObjectIdentification.Encrypted
would be a violation of the RFC 3881 schema

Same issue as #9
The use of the word content…is confusing. Replace: "This
section describes the the content of the XDW Workflow
Document and the requirements of the Cross-Enterprise
Document Workflow (XDW) Content profile. The main
structure of the document and some elements related to its
metadata and the management of its lifecycle need to be
fixed and independent by the domain or the scenario in
which it is used. The different IHE domains and the different
scenarios, in which the Cross-Enterprise Document
Workflow Content profile is applied, have to define the
specific rules of the workflows. The structure of the
Workflow Document and the general rules defined by the ITI
domain remain fixed; the different domains and Affinity
Domains can contestualize only the different steps of the
workflow and their content (e.g.: name and codes).
The use of a defined structure for the workflow document, of
a common set of metadata and of their values and a common
management for the workflow document is necessary to
guarantee the interoperability cross-enterprise."
by:
"This section describes the content of the XDW Workflow
Document as defined by the requirements of the Cross-
Enterprise Document Workflow (XDW) Profile. The Profile
defines thestructure presented is confusing on a few points:
The XML structure of a workflow tracking document and
- The word TASK should be replaced by the word STEPS
- Replace "at" by "to" in: <!-- including the references to at
the published document -->


A statement needs to be added about the metadata table: "In
the metadata table, only specific constraints are specified
about the use of some metadata element for XDW Document
Entries, if none, No special requirements for Workflow
Document".
The specification of the active/inactive flag in eventcode list
needs to be better specified. There should not be a rule
requiring the initial step of a workflow to be as "inactive".
XDW should supports workflows intances with a single step.
The current definition of "inactive" referrs to a workflow
being "completed", without any further definition.




In the folder metadata table, one attribute needs further
refinement:
"uniqueId - No special requirements for Workflow
Document"
Sentence:
"The tasks within a Workflow Document can reference many
clinical documents related to the workflow tracked"


typo


Such workflow definitions are simply referenced by a unique
identifier.


Need to be tracked in distributed environments, so
that the workflow participants need to know the most
recent step performed, and what was the history of
past steps. Only “information about the workflow
history so far” is shared, no centralized workflow
manage systems is needed for XDW.
small title issues


true for ALL figures - Process Flow - the ACTOR types must
be incuded in a sequence/process diagrams
section numbering issues


In some places in this document, you hint that the creator
must be grouped with a consumer in order to get previous
input. In other places, you mandate it.




…shall be grouped with appropriate actors from the Xds
profile

..of the clinical document - a XDW


A XDW Content Consumer


Remove the reference to PCC TF-1:3.4.1.1. This is specific
to the XDS-MS profile.

PCC TF-2:3.1.1 to which you point for the definition of the
View option contains the requirement that the Content
Consumer must be able to print the document. Is it your
intent to require this?
Remove the reference to PCC TF-1:3.4.1.2. This is specific
to the XDS-MS profile.

The first sentence needs a re-write. Hard to understand.
"This document is used to track…"


Because you speak of deprecated documents going in a
folder, I suggest this clarification-->




suggested clarification:




Here (and elsewhere) you refer to the "XDW Content
Profile", ie the profile specified in **this** TI supplement.
In line 136, you refer to "XDS-Based Content Profiles"
which are the future specifications that will define different
clinical workflows based on XDW. I think this is a subtlety
that some readers will not understand.
At the end of the exam, he generates the clinical report of the
exam, references the clinical report inside the workflow
document and updates it.
At any time, during this proces,…


The following diagram represents the UML diagram
representing the …

section titles


Omit these sentences; you state the same thing at the end of
Sec XX




you can remove this "Glossary" section since you are not
making any changes to that section.

typo:


suggested clarification:




typos:




Section needs to be reworked. The behavior of the XDS Doc
Source needs to be detailed, with "shall" statements.

Section and its subsections need to be reworked. The
behavior of the XDS Doc Source needs to be detailed, with
"shall" statements.
sample rework:




sample rework:




Move the contents of this section into the "Contents" section.
These are rules for creating the content of the workflow
document.
The text in this section doesn't match the section heading.
You do need to talk abou "Getting clinical documents
referenced by a workflow" (the heading topic), and how
various versions of a workflow document are handled (the
text topic)
grammar fix:


suggested rewording:




suggested rewording:
I suggest that whenever your refer to the "workflow
document" defined by this profile, you use upper case,
perhaps even with the double quotes, ie, "Workflow
Document". This visually identifies the entity you are
specifying in this supplement.
At various points, you refer to XDW as a "Content Profile".
I think this is misleading and should be removed. This
profile mandates a workflow (little w) involving XDS
operations.
An XDW workflow needs to be uniquely identified. In the
PC version there is some confusion about what mechanism to
use. This is required for a variety of use cases. The creator
of new workflow instance wants to periodically check the
status of the workflow it initiated (need to be queryable
metadata). A referenced document needs, in its clinical
content, to refer to one or more workflows that may be
completed or on-going, but not to any specific point in the
workflow (so pointing to a specific XDW document would
not be appropriate). In the Public Comments proposal the
sepcification of the proposed mechanisms needs to be very
explicit to specify clerly a single identifier and associated
mechanism to create it, query by it, etc.




Open issue 5


Folders should not be required. Yes, having stable folder
references is useful, but why is it any more useful for a
workflow document than any other document? If there is no
difference we should make folder use optional or require
every document to be in a folder so that it may have a stable
reference.
Folder codeList Value is not fully specified in the metadata
specification table 5.Y.3.3 for CodeList:
"Contains the set of codes specifying the type of clinical
activity that resulted in placing XDS Document in this
XDSFolder.
The value shall be “XDW Workflow Context Folder”."
The CodeList and DisplayName are two ditinct entries that
booth need to be defined. In the proposed text the display
name is specified as a code. This is incorrect.
You say "At the level of the XDS Affinity Domain is
necessary to define some specific codes to identify the type
of the Folder used. "
but then you specify the codeList attribute to be "XDW
Workflow Context Folder". It sounds like that code is
mandated by IHE, not the affinity domain.


eReferral document….


Some suggestions in attached document for improving the
content of this section.

In the section XX.3 Use Case Tele-counseling Service for
Neurosurgery Workflow several error have ben identified:
- Need editing to avoid using the concept of status and
instead speak of steps.
- The follow-up seems to be identical to the frist tele-
consulting session. It make the example too complex and
does not add any value. It seems to be simply a repeat.
- This example does not highlight significant distinct features
than the referral one just before.


There is no definite specification of the approach in XDW to
lock/unlock a workflow while an activity is in progress or
how "race condition" are resolved when paralell activities
are performed (two concurrent updates of the same XDW
instance). There is a definite need for a single well defined
mechanism for assuming ownership of a workflow, the issues
about "unlocking" this assumption of ownership, the rules
about expiration of such blocking. A common model is
needed beyond an example in volume 1 where an "in
progress" step is used.




The Content Creator must have special capability to handling
conflicts of update. Although discussed in the committee
this profile never addresses the case of two creators updating
near the same time. One will "win" the other will get an
error. We must put requirements on the creator to handle the
error, probably by posting an audit message and re-retrieving
an updated document to be updated and replaced. Have we
considered the clinical consequences of symultaneous
updates? At least this should be discussed somewhere in the
profile.
resolve conflicts in document updates?




edit/template comments


Although it states that some things are fixed by ITI and some
must be specified by definers of specific workflows, it is
never made clear which is which. I found myself guessing
and think it would be useful to state it explicitly.


Either open or closed issues should bring up and explain why
XDR, XDM and XCA are not addressed - presumably a
scoping decision.
The current XDW Profile proposal is supported by XDS, but
no clear statement is made about use of XCA in a federated
environment with multiple XDS domains. The support of
XDW with XCA cannot be ignored. If certain gaps are
identified, their resolution should be discussed in the
introduction to this supplement




This profile appears to overlook the significant
benefits of constraining XDS metadata values for
documents used within each workflow. E.g. what is
the document class /type/format code of the referral
document used in the process described here.
This is the first time in Vol 3 that folders are mentioned. It
is also the first time in Vol 3 where you need to go beyond
the capabilities of a traditional "Content Creator" (eg in
XDS, Doc Sources create folders, not Content Creators).
Your profile needs to mandate behaviors (create folders,
replace documents). I cannot think of another profile to use a
a model for this text.

One option is to create a section at this level (5.Y.4) named
something like "XDW and XDS behaviors (bad name) with a
stmt that appears a bit further down "The Cross-Enterprise
Document Workflow profile specifies both the content of
the Workflow Document and also the lifecycle
management of the Workflow Document. The XDW
Content Profile relies on XDS operations for
management of the Workflow Document. The XDW
Content Creator is grouped with an XDS Document
Source and an XDW Content Consumer is grouped with
an XDS Document Content Consumer. "

Then there would be subsections specifying rqmts for
folders, lifecycle, associations.
Formatting option: Rather than specifying all XDS metadata
attributes and marking many with "No special rqmts…" you
could choose to follow the pattern used for XDS-SD (ITI TF-
3:5.2.2) which states "XDS-SD is a CDA R2 document and
thus conforms to the XDS Metadata requirements in the
PCC TF-2:4 unless otherwise specified below. "

 ..and then just the deltas are listed.

You refer here to ITI TF-3:4.1.5. I think the PCC TF
reference is more proper.

Need to clarify the boundaries of XDS vs XDW vs
Workflow Definition.
Proposed Change                                                        Priority



It is strongly suggested to rely on the "referal use case" to introduce High
in volume 3 a sample WF document including the content of the WF
document at the end fo the referal (two steps).
The XDW profile should contain a sufficiently detailed example of
workflow definition to enable multi-party Connectathon testing.


Read the PCC documents for the model.                                  High




                                                                       High
                                                                       High
In example, it appears to be timestamps, but that is not specified.   High


Is there a customized use of these terms? In the bigger picture, IHE Medium
needs to figure out where/how to present this CDA introductory
material. It does not belong in the ITI documentation. Trying to be
helpful, but replication is not a good idea. Only include what is
specific to a Workflow document, everything else needs to be
stripped out. (ie., pull out through line 1070)

                                                                      High




                                                                      High




GAP-RJH: No comment. Need to check with Mark to see what the
issue is.




Remove the statement                                                  Low
The inherent complexity of the gateways is not necessarily lower       High
than XCA and we would urge you to reconsider publication of the
profile at all. With the current lack of use cases that favor XCF over
XCA (see later comments), I suggest further work needs to be done
to iron out this issue.




                                                                      High




                                                                      High


Might want to reduce scope to dynamic documents.                      Medium



Might want to generally introduce transformation option in XCA and Medium
XCF on both gateways



remove mitigation                                                     Medium

remove mitigation                                                     Medium

general comment, but may need to file CPs agains XDS, XCA, XCF Low
and others with the code
add rows stating so                                                     Low

remove mitigation; re-asses                                             High


see comment in row 17                                                   Low



remove sentence                                                         Low




remove bullet point                                                     Low

SOAP with MTOM: we should says "shall use..." And the request           Low
should also be SOAP 1.2 with MTOM


change example to use SOAP MTOM reference                               Low

I have no suggestion here; this is a hard case that also plays are role Medium
in XCA, but there it is always possible later on to issue another query
to get to this information, given that uniqueIds remain stable.


Suggest to change to: if any of the documents fail to pass the access   Low
control rules, they must not be sent to the Initiating Gateway", or
something similar.
remove requirement                                                      Medium




                                                                        Low


remove XCF from XDSUnknownPatientId row                                 Low

write section about signature handling or remove statements about       Medium
reliance on DSG



spell out audit message table and correct errors. Start off with the    Low
merger of ITI-18 and ITI-43 audits and correct the necessary fields.



                                                                        Low
Add rationale why HL7v3 was not taken into consideration, from XPID.3
closed issue
Just a friendly reminder to do just that before TI                   Low


Move final risk analysis to a stable URL                             Low


Change to original ACK mode (i.e., remove the text, as original      Medium
ACK mode is implied)


Add text to state that submission sets move with their documents.    Medium
This would be in addition to any text about folder handling, and
hence additional to text in the current supplement.




Add text to state that folders move with their documents where        High
appropriate, or fail otherwise. This would replace some text around
line #465 where implementation options are discussed. The current
text leaves too much open and requires "documentation" to solve it. I
would opt for a stricter approach




Suggest to add ParticipantObjectDetail with "to" and "from"          Medium
indication (or MRG-1 and PID-3)


                                                                     high



with a small amount of work to incorporate the changes mentioned
above, this profile could become a complete game changing step in
IHE development. One which would encourage USERS to get
involved in the definition of business processes, for XDS document
exchange.
as an example see ITI XCA section 18.3.3 for a good example          Medium




                                                                     High
I suggest that the format for the workflow document is replaced by high
BPMN 2 XML standard for document exchange, together with
guidines to constrain use. This will allow these processes to be
defined using existing open source tools such as Bonitasoft and other
proprietary tools. The adoption of BPMN would attract a new breed
of workflow engine vendors into the IHE fold, which would really
help IHE to develop better engagement with users.


Make the example a real example rather than a skeleton with
little information                                          Medium

Write what you mean, restating the standard or constraining
the standard                                                Medium
Strongly oppose the use of CDA for this pupose since the workflow   High
document has no clinical content. Investigate HumanTask in more
detail.
                                                                    Medium




                                                                    Low


Change "The following diagram represents the UML diagram            Low
representing" to "Figure XXX represents" Also this figure, and
many others, needs designations and titles.
Consider landscape format.                                          Low


need to add Figure titles everywhere                                Medium



The use of folders is not well spelled out in terms of the
requirements of their use. Perhaps a section could be used
to highlight this important feater and detail it explicitly.        Medium
Remove Append and Transform.
Specify that Replace shall not be used when the Workflow
progresses. An XDS Replace is used, but the Workflow document
shall not be versionned across the adddition of steps as the
workflow unfolds.
The section should be drastically simplified.
Find a place in the Workflow Document to store the Id of the
Workflow Instance.
x.2.2.1 be x.2.1.1; x.2.2.2 be x.2.1.2                               Medium


x.3 The CDA Document Content Structure is not typically put into     Medium
Volume 1. In PCC, it is put into Vol 2 (soon to be renamed Vol 3
for all Content Modules). Consider moving the current x.3 section
out of Volume 1.
No change suggested, just feedback.                                  Low


It is proposed to make this statement more specific: "Such workflow High
definitions are simply referenced by a unique identifier, which is
used as the Workflow Document Type Code and Meaning."

Consider including additional metadata in the document reference.
Add more details about th euse of the Human readeable aspects of
the Workflow Document.
Specify the behavior when the referenced document has been
deprecated.
Applies also to the Output document section.




I would suggest introducing two new actors into the profile to enable High
process definition documents to be published into XDS, to enable
participating applications to subscribe to one or more processes.
BPMN enables processes to be divided into 'role – swim lanes' which
can be used to address security and quality concerns. e.g. only the
XX system is allowed to send emails to the patient.




IHE ITI should consult with PCC on this matter.                      Medium
These need to be reconciled                                          Medium




you should consider grabbing 10 min of time from the PCC, QRPH,
and PCD committee meeting and do a roadshow on this profile if you
want it to be adopted because there are a lot of complex use cases
being defined out there right now that this would work for...

                                                                     High


This profile addresses only the linking of patient identifiers. Linking Medium
of patient identifiers supports an environment when multiple patient
identifier domains are being used and translation among those patient
identifiers is needed to enable patient identification across patient
identifier domains. Patient identifiers across patient identifier
domains can be linked, reflecting that the same patient is identified
by all linked identifiers, and can be unlinked, reflecting that it was
later found that the identifiers previously linked are not refering to
the same patient. This profile supports a subset of all link/unlink
events because it enables only linking with an XAD-PID and enables
link and unlink in a single transaction - Notify XAD-PID Link
Change.

Merging of patient identifiers supports an environment where two
patient identifiers, generally in the same patient identifier domain,
are found to refer to the same patient and one is subsumed by the
other. In this enviroment the subsumed patient identifier is no longer
used and all records are merged in with the surviving patient
identifier. Merge is supported within the XDS profile through a
Patient Feed message that communicates to the XDS Document
Registry thatto subsumed "and published to has been merged into a
Add "XDS" a sentence: patient identifier the XDS Document              Low
Repository and XDS Document Registry using that XAD-PID"

                                                                     Low



Look at existing Vol. 1 introductory sections and consider adding    Medium
this content in as a new section or addition to existing section.
Content would stay in this supplement, but be designated for an
introductory section in Vol. 1 so it isn't lost at FT time.

Replace the phrase "data concerns" with something that is more       Low
accessibly understandable to us English speakers
Replace second sentence with: "The alternatives (both existing and      Low
new additions) are summarized …"
"It is not possible to directly determine from a file itself if it is   Low
encrytped…"

Rewrite paragraph, I can't help since I don't know what it is trying to Low
say.

Delete "Media may amongst others include…" sentence since the      Low
following sentence makes this clear. The sentence I suggesting be
deleted suggests there are others and that you must do both CD ROM
AND USB, then the next sentence contradicts this… its confusing.

Replace "options below" with "as specified in the following             Low
subsections".

Come back next year and write another one for us                        High

"Thus a single transaction is significantly simpler to implement in     Low
scenarios, which involve multiple interacting domains because it
allows for stateless gateways. "
this phrase needs further explanation - maybe not here but
somewhere near the front. Need to document up front the
parameters which need to be agreed upon for this to work. Two
systems will never work "out of the box". Where does this get
documented? For example, are the differences which are
concealed coded values for XDS meta-data? or do you mean the
types of documents which are exchanged. Should be documented
insection x.3.3 - Usage Restrictions.                                   High
                                                                        Low




"When a Responding Gateway is supporting an XDS Affinity                Low
Domain, it may resolve Cross Gateway Fetch transactions by
grouping with an XDS Document Consumer Actor and using the
Registry Stored Query and Retrieve Document Set transactions to
interact with the XDS Document Registry and Document
Repository in its local Affinity Domain."
omit: "The XCF Profile allows for stateless gateway                     Low
infrastructures."




line section numbers and titles back up w/ Template; line 233 also
references Use Cases.                                                   Medium
                                                                        Low
keep it tabular, please
change "consumers" to "consumer's"                                      Low

change "Requestorr" to "Requestor"                                      Low
reduce text? Call it "current situation" (check wording with other
ITI profiles).                                                       Medium
…are split

                                                                     Low
…may occur

                                                                     Low
Perhaps it should be its own section, ie at the X.Y level            Low


This needs to be normative. "assumes" is not strong enough. Needs High
to be more explicit in defining what can be exchanged.




should be replaced with "returning an error code" -
                                                                     Medium
                                                                     Low


The contents of the data set are well specified in advance, and there Low
will be the only documents that is are sanctioned to will be
exchanged.
QED is Query for Existing Data                                        Low

                                                                     Low

include the entire profile name; probably not necessary for XDS.     Low

The reverse action is taken at the Initiating Gateway: the data      Low
received from the Responding Gateway is transformed at the
Initiating Ggateway transformed, translated and transcoded into
the local format.
                                                                     Low


                                                                  Low
is it requirements or recommendations? These are good, but separate.




                                                                     Medium

                                                                     Medium
Clarify what is required and what is not. (also see comment at line
405)
                                                                     Medium
Queries of A Responding Gateway which receives a fetch request Low
for unknown identifiers...
By The XCF profile does not defining an error code indicating that
the identifier is ill-formatted, you are to reduceing the ability of
applications to fish for data




insert paragraph break? (if that is what was intended)                Medium
Clarifiy whether this requirement implies behavior that should be     High
mandated on either actor, and if so, describe it in Vol 2.




                                                                      High
delete line 428 to 440 or just put a reference to "Generic Risk
Mitigations" in some other documents.
                                                                      Low

                                                                      High
explicitly say "required for the server" (we think)
                                                                      Low

Indicates whether related documents and their relationships are       Low
delivered
in the response. iIf parameter is
existent and set to “1”, then documents matching the query
criteria, and their relationships, are return. If parameter is
absent or set to "0" then. Nno related
documents and their relationships
will be returned if query parameter is
absent or set to “0”. See 3.Y.4.1.2.3.
Multiple Separate individual Fetch requests can be used to fetch      Low
data associated with different homeCommunityIds.
                                                                      High
The decision on what related documents are to be included is made Low
taken by the Responding Gateway. While t The Initiating Gateway
may only request whether it requests any related documents;
however, the Responding Gateway decides based on its local policy
what Association objects (linking the targeted DocumentEntries) and
related DocumentEntries are returned. This transaction is The
Responding Gateway only returns ing relationships between
documents as stated in IHE-TF-3:4.1-2; it never returns other
associations (such as hasMember) are never returned.



add it to the list here                                           Low


should be ITI TF-3:4.1.13                                         Low

                                                                  Low




                                                                  Medium
                                                                  Low

ITI TF-2a:3.18.4.1.2                                              Low

ITI TF-2b:3.43.5.1.2 (note 2a has been changed to 2b and IHE      Low
changed to ITI)
... encode relationships among the documents provided (see ITI-   Low
TF3:4.1.6.1 for details)


                                                                  Medium
Please clarify




                                                                  Medium
Please clarify




                                                                  Medium
either mandate BPPC or get rid of "shall" in this line.


                                                                      Medium
The Responding Gateway shall provide document metadata                Low
attributes MUST be used as per specified in ITI TF-3:Table 4.1-5.

E.g. if the Responding Gateway is unable to successfully process Low
a X-User Assertion, a fault should be thrown according to
WSSE1.1.




                                                                      Medium




                                                                     Medium
Be previously configured for their maximum acceptable response Low
size it supports. All transactions that If the response exceeds this
configured transaction size, the Responding Gateway shall returns
XDSTooManyResults and zero documents. The assumption is that
XCA is used for requests expected to return a large number of
documents. transactions of significant/exceeding size.

                                                                      High




                                                                      Low




                                                                      Low

Througout table and in the paragraph under the table, ensure all actor Low
nagmes are capitalized to read "Initiating Gateway" and "Responding
Gateway" since you are referring to actors in this profile, not merely
generic gateways.
is all of this text supposed to be duplicated in both XDR and          High
XDM? I am confused. Are we adding a new option and new
actor to XDM? Otherwise, you are changing the transaction out
from under the existing implementations.




                                                                      Low
spell this out in detail, these use cases in the Intro will be gone with   Medium
the Supplement since the Intro vanishes. To XDM also?

Typically one of the following two approaches is are used:




In particular, patient identifiers will likely not be useful but
patient demographics will be especially important.




add to process flow XDR and XDM                                            Medium




                                                                           Medium
Though you might think I am kidding, I am not. For
example, rather than using IHE_XDM directory structure add
a new directory for meta data limited files such as IHE_LTD
that this is radically different for existing implementations.
There needs to be something that is machine-processable
which will realize that it does not understand meta data
limited and then the user knows to go find the system
administrator.




                                                                           High
make R2                                                                    Medium
                                                                       High
There is only one Actor "Document Source". The XDS and
the XDR Document Source requirements are identical. Take
the "XDS" and "XDR" heading off of the Document Source
column and delete one column.




                                                                       Medium
At least tell the implementers to toss up an audit message or put it on High
a queue to deal with? Put something in the Expected Actions
section at the Profile level.
Requirements for use of metadata in the Provide and
Register Transaction are specified in ITI TF-2b: 3.41.4.1.2 and
those for Distribute Document Set on Media are specified in
ITI TF-2b: 3.32.4.1.2.2.
                                                                   Low
The following example markes marks the “DocEntry”
Document Entry as created via the less rigorous metadata
requirements.

                                                                   Low
<ExtrinsicObject id="DocEntry">
(…)
   <Classification classifiedObject="DocEntry"
  classificationNode="urn:uuid:
urn:uuid:ab9b591b-83ab-4d03-8f5d-
f93b1fb92e85”/>
(…)
                                                                   Low
can't it just be "R" for this Actor, period. No more new codes. You High
cannot add a new code for a single Actor. Instead, be
CONSISTENT in how we are stating technical requirements by
adding a column to Table 4.1-5 (line 620) - split the "Source"
column to two columns (as TAble 3.41.4.1.2-2 has been written).
Yet, another alternative (that we do not like as much) is to make the
attribute type R and put a note into that field that it is only required
to the Meta Data Lmtd actor...
   <Classification classifiedObject="SubmissionSet"
     classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-
b4633d873bdd"/>
   <Classification classifiedObject="SubmissionSet"
  classificationNode="urn:uuid: urn:uuid:5003a9db-
"/>

                                                                   Low




                                                                   Low




                                                                   Low
  <Classification classifiedObject="Folder"
 classificationNode="urn:uuid: urn:uuid:2c144a76-
29a9-4b7c-af54-b25409fe7d03"/>

                                                                       Low
ITI TF-2b: 3.41.4.1.3l and ITI TF-1:15.2.3




leave some patient id info as type R so a human can figure this out, if High
not a machine… OR consider dropping this new Actor out of XDR
and just leave it in XDM. The current definition of data types
forces manual intervention. (Note that the existing comment in line
464 gets deleted for TI.)
 Generation of additional metadata is likely to be needed in
order to integrate content exchanged through If a document
originates in XDR or XDM with lowered level of metadata
attributes requirements, it is likely that additional metadata
will need to be generated in order to integrate that
document into an XDS environment,; therefore we
encourage as much metadata be carried as is known by the
sender.
                                                                       Low




                                                                       Medium




                                                                      Low

change "effect" to "affect"
                                                                      Low




change "carying" to "carrying"
                                                                       High




Make this an option to XDS.b rather than a separate Profile.
spell out the acronym                                                  Low


change to "will probably"                                              Low


                                                                       High




spell out the acronym before you use it                                Low


capitalization of proper actor names is inconsistent throughout this   Medium
entire document. I thought that proper Actor names were supposed
to be upper case?
This consideration is of particular importance when evaluating
the impact of the collective changes to existing object
associations. After all changes have been performed, one or more
XDS Document Registry constraints required for such
associations for the updated objects may no longer be valid. For
example, a document may no longer have the same patientID as the
folder it belonged to previously. In this case, the XDS Document
Registry must enforce its integrity rules and consequently the
association cannot be re-established with the new version of the
objects. The XDS Document Registry will have to detect these
occurrences and provide the necessary documentation and alerting
actions.
How should this be tested at the Connectathon? A bad UI is not         High
IHE's problem, but still need to be able to verify that objects were
linked correctly.
In order for the XAD-PID link changes to be processed according to Medium
this profile, the following
assumptions are made about requirement applies to the Patient
Identity Cross-Reference Manager:
1. The Assigning Authority for every applicable sourcePatientId
is a source to the Patient
Identity Cross Reference Manager actor.
2. The Assigning Authority that manages the XAD-PID domain
is also a source to the
Patient Identity Cross Reference Manager actor.
3. - The Patient Identity Cross Reference Manager actor hasshall
have the ability to identify the
Assigning Authority for the XAD-PID domain.
The first two assumptions enable the Patient Identity Cross-
Reference Manager actor to establish
links between the sourcePatientId and the XAD-PID, while the
third assumption This enables it to
determine which identifier is the XAD-PID and when to trigger the
notification transaction.

In addition, the Affinity Domain in which the Patient Identity
Cross-Reference Manager and Document Registry resides has
these requirements:

1. The Assigning Authority for every applicable sourcePatientId
which may be relinked is a Patient Identity Source to the Patient
Identity good job
nothing, Cross-Reference Manager actor.                           Low


All XDS Stored Query transactions referencing the new identifier Low
(XAD-PID 11111) will return documents including those belonging
to the local patient identifier (MRN 22222).
Add a section at the beginning of the transaction, perhaps before or
after the "Scope" section, which lays out terminology used to
describe the different Patient IDs affected by this transaction. One
option follows in the next comment.




The Patient Identity Cross-Reference Manager shall notify a            Medium
Document Registry whenever there is has made a change in the
link between a patient's "local patient ID" identifier and its
corresponding XAD-PID.

The Patient Identifer Cross-Reference Manager shall encode the Low
Notify XPID Link Change message transaction shall be encoded
and communicated it using the ADT^A43 message.
The Patient Identity Cross-Reference Manager shall             Low
acknowledge eEach ADT^A43 message shall be acknowledged by
with the HL7 v2 Accept ACK message.
                                                               Medium




A single PID segment shall include a list with two identifiers in PID- Medium
3 as follows:
• The first repetition contains the "post-relink XAD-PID", to be
used from now on as the one the Patient Identity Cross-
Reference Manager has linked to the "local patient ID".
• The second repetition contains the "local patient ID" that has
triggered the event and which will be mapped to sourcePatientId
values in the Document Registry.
Each Both patient IDs included in PID-3 shall include a fully           Low
qualified Assigning Authority component.

                                                                        Medium


A single MRG segment shall include a single identifier in MRG-1      Medium
containing the "pre-relink XAD-PID" that was previously linked
to the local patient identifier. This should be the value of
patientId presently stored in all document entries assigned to the
given localpatient identifier. (I think this last sentence should be
omitted. The PIX Manager constructing this msg has no concept of
how this Patient ID was used in document entries)

The patient ID included in MRG-1 shall include a fully qualified
Assigning Authority component. The Assigning Authority
component returned shall include the subcomponents Universal ID,
and Universal ID type. It may include the namespace ID, in which
case it shall reference the same entity as is referenced by the other
two subcomponents.


Upon receipt of this message, the XDS Document Registry shall           High
perform all necessary actions to ensure that it has applied the XAD-
PID link change notification to all applicable objects within its
database.

The Document Registry shall version updates to Document
Entires according to the mechanism described in Volume 3,
Section 4.1.15 – Metadata Versioning Semantics (IHE Technical
Framework Supplement - XDS Metadata Update).

Since this profile transaction cannot make any assumptions about
on how information is structured and persisted within the XDS
Document Registry, it will just these Expected Actions describe its
expected behavior of the Document Registry observed once it has
processed the XAD-PID lLink cChange message notice is received.
Consider : The Document Registry must update its internal
representation of the meta data associated with documents to be
consistent with the update notification. Further behaviour of the
Document Registry is defined at the Profile level. This needs to be
addressed in the Grouping section of the Supplement (this section
appears to have been deleted in teh XAD-PID Supplement). It must
be in the X.1.1.1 ("Actor Descriptions and Requirements") - this
section knits together TRANSACTIONS for this Profile.
 After processing change, the XDS Document Registry shall ensure          High
that:

Note: In the points below “sourcePatientId” refers the local patient
identifier provided by the transaction in PID-3, “new patientId” refers
to the newly assigned XAD-PID also provided in PID-3 and “previous
patientId” refers to the currently assigned XAD-PID provided in MRG-
1


1. Responses to any subsequent stored query that retrieves a for
documents related assigned to the sourcePatientId "local Patient
ID" (ie sourcePatientId) will return a Document Entry shall
include, as appropriate given the query parameters, all
document for that sourcePatientId and containing a patientId
value of the "post re-link XAD-PID"assigned to the new
patientId. After correcting this, I then decided to strike this item
because I could not find in ITI-18 where a Consumer could query by
sourcePatientId.
2. Responses to any subsequent stored query for documents
relateding to the "post-relink XAD-PID" (ie patientId in the
Document) new patientID shall include, as appropriate given the
query parameters, all matching documents for that patientID
including those containing a sourcePatientId value of "local
Patient ID". of Document Registries must also
Implementorsassigned to the sourcePatientId . consider that in
addition to Document Entry updates, this transaction will also affect
existing associations (XFRM, APND, RPLC and XFRM_RPLC) and
folders that involve any of these updated Document Entries. The
key principle that must be observed is that the XDS Document
Registry is required to shall maintain all the appropriate validation
rules and constraintsed defined in the metadata model. This includes
the requirement that all members of folders and associations must
have the same patientId. As the XDS Document Registry processes
this transaction, this condition may no longer apply, requiring that
the Document Registry take some corrective action, . This will
occur fFor example if a folder contains Document Entries with
different values for sourcePatientId. Since the other documents will
preserve their current value for patientId, it becomes clear that they
cannot all remain together in the same folder. Similar situations can
occur with the other association types.

The manner by which the XDS Document Registry will handle these
situations is not mandated by IHE. also left for the implementers
to decide. Whatever However, the approach is use d, the XDS
Document Registry must uses shall preserve the consistency of its Medium
1. Preserve relationships when all participants have the same
sourcePatientId. In this approach, the XDS Document Registry
would create a new version (for folders)
                                                                          Low


                                                                          Low
The approach used in this profile is based on link change
notifications being sent from the PIX
mManager to the Document Registry, which will then perform an
automatic batch update to
possibly many objects within its database.the XDS Document
Registry. The changes reflect the new link
between a local patient identifier and the corresponding XAD-PID.
In order to maintain
referential integrity within the XDS Document Registry, tThese
updates must follow the same
technical requirements and behaviors defined in the Update
Document Set [ITI-57] transaction, as
each with change must resulting in a new version of the affected
object.



3.10.4.1.2.2 should be 3.Y.4.1.2.2                                     Low
3.10.4.1.2.3 should be 3.Y.4.1.2.3
3.10.4.1.2.4 should be 3.Y.4.1.2.4
                                                                       High




Do not put explanation into Intro which will be deleted (put it into
Section X).



This supplement examines where gaps there still exist gaps and fills Low
those gaps with:

                                                                       Medium




XDS and XDR and other IHE profiles require grouping with               Low
ATNA.
                                                                      Low




replace "anonimization" with "anonymization"                          Low




"Upon reception of receiving the encrypted document, the              Low
department assigns a particular cardiologist…"
Incorporate some (not all) of the Introduction in section X.




"It addresses the need to protect documents from partially certain
intermediaries in the document exchange path and provides
confidentiality to transports that do not have a confidentiality
mechanism."                                                           Low



This profile does not specify define any specific policy aspects to
allow for policy polices stemming ranging from regulatory,
organizational as well as privacy or consent policies (e.g., BPPC).   Low

what to encrypt, and encryption may …                                 Low



                                                                      Medium
" The IHE PWP and HPD profiles are shown to inform the reader of
their use for distribution of public certificates."              Low
Key management is The Document Encryption profile does not
explicitly specifyied the method for key management in order to
allow for multiple methods for identity and key management.

                                                                      Low
with flexibility in mind as systems should, for example, …
                                                                      Low


                                                                      Medium
… may not only affect that part of the document that part of
the document but the remainder of the document might not
be recoverable. may have as a consequence that the
remainder of the document cannot be recovered.               Low


                                                            Medium



                                                            Low


                                                            Low


                                                            Low
"In the case the media used is the ZIP file over Email, the
The Portable Media Creato actor that supports the ZIP over
Email option shall secure the XDM media content by
S/MIME (see IHE ATNA) and comply with the security
process as defined in…"                                     Low


                                                            Low
Fix section numbering.
                                                            Low

                                                            Low
Fix DICOM reference.

Same issue as line 498




                                                            Medium




                                                            Medium
                                                                Medium




                                                                Medium
The Portable Media Creator actor encrypts the content
encryption key for one or more recipients.
Key management here enables this by supporting the key
management methods and hooks.

For each recipient the Portable Media Creator actor shall
apply one or more of these key encryption methods: from
PKI, shared symmetric key, and password.
- PKI
- shared symmetric key
- password

The Portable Media Importer actor shall support all three
methods. There is no obligation to use all three methods in a
deployment as this depends on the environment with e.g.
availability of
keys, key management infrastructure, work-flow, etc.



The management of such certificate is out-of-scope of this
transaction profile, but implementers can for example use
the IHE PWP or HPD profile to obtain certificates.

                                                                Low




                                                                Low
The symmetric key can be pre-shared or involve key retrieval,
both of which are out-of-scope of this profile transaction.

                                                                Low
                                                                       Low
The recommendation from Teri, Steve, Lynn is to create a
new section in Volume 3.

This will change the template for Volume 3 across domains.
You should coordinate with the documentation group
(Jungers, Sippel, Carr, et. al.) to get this blessed.

                                                                       High
 It also presents the responsibilities of the Content Creator
actor and Content Consumer actors which are responsible for
encryption and decryption respectively.
                                                                       Low

                                                                       Medium
We should find a home for the IHE Encryption solution overview in     Medium
the security cookbook.
I noticed it on DEN, but all PDFs seem to lack embedded fonts. So High
they look different on Mac than on PC, and different depending upon
which fonts are installed on the system. This needs fixing in the
overall process for creating PDFs
Don't forget to copy the use cases                                  High

Text would need a little adjusting, but move table here.              Medium



                                                                      Low

Perhaps a home on the wiki? Or web site? I'm not sure what is best. Low



Find problem and fix PDF creation process. Done.                      High


I suggest revising the Introduction to be significantly shorter and   Medium
remove most of the duplicate information.

Perhaps a more detailed process flow diagram might help explain all High
this all works together. I'm not sure the simple creator/consumer
actors are sufficient for this content profile


First trim down each use case so it is a short, general paragraph and a High
nice clear diagram. Ensure all text is concise and to the point,
skipping all the extraneous details.
Second, move this trimmed down, succint text into the use case
section where it belongs.
Suggest that 90% of the words in this section be deleted. The
diagrams are self-explanatory and only need a quick paragraph to set
up the use case.                                                     Low
Suggest that 90% of the words in this section be deleted. The
diagrams are self-explanatory and only need a quick paragraph to set
up the use case.                                                     Low
Delete or rewrite this, last diagram is too small to be useful

                                                                         Low
 WITH:
The use of a defined structure for the Workflow Document, of a
common set of metadata and of their values and a common
management for the workflow document is necessary to guarantee
the interoperability of workflows cross-enterprise.

The structure of the Workflow Document and the general
requirements for managing Workflow Documents are specified by
the XDW profile. Different IHE domains or organizations will use
this XDW "infrastructure" and define workflows specific to their
domain by indentifying steps in their workflow, the inputs and
outputs of those steps (eg documents, codes) as well as specific rules
for managing those steps.




Suggest replacing:                                                       High
"This profile defines the content of a workflow document that
records past steps of a workflow and maintains the references to
health information input and output associated with each step.
Such shared workflow state information allows the various
participating systems to be aware of the history (past steps) of any
of the workflows known for a patient, access the workflow current
state and remain coordinated by updating this shared document
with the new steps they have performed."
By:
"This profile defines the content of a workflow document that
records past steps of a workflow and maintains the references to
health information input and output associated with each step.
Such shared workflow state information allows the various
participating systems to be aware of the history (past steps) of any
of the workflows known for a patient, access the workflow current
state and remain coordinated by updating this shared document
with the new steps they have performed according to the futures
steps as constrained by the workflow definition (see Appendix YYY
for a template definition)."

propose a template with requirements;                                    High
Correct text starting at the following lines:                            Medium
Line 512; Line 541; Line 557; Line 566;




See attached doc                                                         Low


explicitly state that all workflow must be within facilities which are   Medium
part of affinity domain.



                                                                         Medium




note that this comment is NOT in confict with a comment much
further down which takes the current section 5.y.5 which restructures
the grammar from being effectively informative and making it
normative as required for Vol 2
                                                                         High
It is proposed in the introduction to XDW to add the following, just High
before section X.1:




XDW coordinates execution of various workflow definitions

A Worflow definition is required in order to manage a specific set of
tasks. It is specified by IHE in what is called a Workflow Definition
Profile.
A Worflow Definition includes the set of possible steps that may
occure within the workflow and for each possible step it specifies
the relationships between possible previous steps and possible
subsequent steps, the required or optional types of document
content that may be reference as input or output to the step. A
generic template for a workflow definition is provided in appendix
It is proposed in the introduction to XDW to add the following, just High
before section X.1:




XDW coordinates execution of various workflow definitions

A Worflow definition is required in order to manage a specific set of
tasks. It is specified by IHE in what is called a Workflow Definition
Profile.
A Worflow Definition includes the set of possible steps that may
occure within the workflow and for each possible step it specifies
the relationships between possible previous steps and possible
subsequent steps, the required or optional types of document
content that may be reference as input or output to the step. A
generic template for a workflow definition is provided in appendix High
It is understood MIME/CMS is already supported within the
wider IHE profile set. While it certainly makes sense to use
this in a number of areas, such as for secure email where
S/MIME encryption is the established industry solution, ZIP is
already integrated within a number of the existing IHE use
cases such as those referencing ANNEX V or ANNEX W
(DICOM Part 12).

I expect everyone is familiar with ZIP to some degree. I
include here some broad aspects of ZIP as background for
anyone that may not be aware of the extensive use of ZIP in
the industry. Apologies if this information is already known
to you.

ZIP is an established, well-defined and stable format with
over 20 years of industry use. Recognized and widely
adopted as one of the most interoperable 'containers'
available, it has been incorporated within countless industry
solutions. A number of well known examples where ZIP has
been integrated into important industry standards include
the Oracle/SUN JAR format, EPUB, W3C Widgets, ISO/IEC
26300 and ISO/IEC 29500.

ZIP commonly is considered only as a "compression"
technology. However, ZIP has long provided capabilities for
compression, file archiving and data security. Each of these
capabilities has been extended to meet evolving needs within
the industry. While PKWARE has served as the principle       High




1) Rename the profile to ""Cross Enterprise Document
Workflow Record"
2) Rename the abbreviation to XDS-WFR to reflect that it is a
content profile
3) Keep open the concept and plan for a "real" "Cross
Enterprise Workflow as soon as possible (we would be willing
to contribute some work). We recognise that this would be a
significant undertaking, with addition of 1 or more new
actors.                                                       High
Consider a different paradigm, view only or view and replace.    High
Remove that sentence.                                                                     Low




                                                                                          Low

• custodian— Represents the organization from which the
document originates and that is in charge of maintaining the
document. The custodian can change in the different
versions of the Workflow Document and it is the steward of
the last version document
Every CDA document has exactly one custodian


Section seems unrelated to this particular type of document. Low



I suggest deleting this sentence as the next makes the same
point in a more general way.                                                              Medium


                                                                                          Low


                                                                                          Low


                                                                                          Low


                                                                                          Low
Replace with updated text:                                                                Medium
"The Cross-Enterprise Document Workflow (XDW) profile enables participants in a
multi-organizational environment to track the steps related to patient-centric
workflows as they systems hosting workflow management applications coordinate
their activities of the health professional they support. ItXDW builds upon the sharing
of health documents provided by other IHE profiles such as XDS, adding the means to
associate documents for conveying clinical facts to a patient-specific workflow. XDW
provides a common interoperability infrastructure upon which a wide range a
specific workflow “content” may be defined. It is designed to support the complexity
of health services delivery with much flexibility to adapt as workflows evolve.

This profile defines a shared workflow tracking data structure, called a “workflow
document” that records past steps of a workflow and maintains the references to
health information input and output associated with each step. Such shared
workflow state information allows the various participating systems to be aware of
the history (past steps) of any of the workflows known for a patient, access the
workflow current state and remain coordinated by updating this shared document
with the new steps they have performed according to a referenced workflow
definition."
Replace bullet by:                                                          Medium
"Facilitates the integration of multi-organizational workflows with the
variety of existing organization workflow management systems. It does so,
not by adding a centralized workflow management system, but by offering
peer-to-peer ( or federated) workflow synchronization beetwen the
participating workflow management systems in the point of care systems."


Replace bullet by:                                                          Medium
"Leave the driving of the workflow to the health professional, and
its system as a worklfow participant within the definition of the
workflow refenced at the time of workflow initiation. Future steps
are not managed in constrained by XDW, but left to the business
layer above XDW where requests or expectations are considered
integral to the outcome of previous steps (care plans, requests,
etc.)."

Remove any reference to Transform and append in CDA Header of               Low
XDW document.
Decide if Replace (RPLC) need to be used or not (do not leave
optional). There does not seem to be solid arguments to manage
RPLC, as XDW documents are unlikely to be stored in local
applications data stores.

As this example is not intended to specify the most generic        Medium
ePrecription workflow, it is recommended to simplify the example,
and have the pharmacist perform the validation at the same time as
the medication is dispensed. The step 11 query should be removed
and the advice and dispensation steps should be combined.




Replace:                                                                    Medium
"The process for updating the document is:
 • Open the existing workflow document
   o Add or update workflow steps
   o Re-register (update) the workflow document by performing a
document replace"
By:
The process for updating the document is:
 • Open the existing workflow document
   o Copy all previous workflow steps without any changes
 • Create a new workflow document
   o Insert all previous workflow steps without any changes
   o Add one or more new workflow steps
 • Re-register the new workflow document by performing a
document replace
Replace by: 5.Y.5.3 Add a workflow step with an associated clinical Medium
document
Whenever a worflow advances, a new Workflow Document with an
additional step is created and added to the same Workflow Context
Folder. If there are clinical documents related to this new step, the
Content Creator records the references to these documents inside
the input and/or output sections of the new step.

Replace 5.Y.5.4 by:                                                       Medium
5.Y.5.4 Get a clinical document associated to a workflow
Any Workflow Document contains details of each step that have
been performed for the specific workflow definition to which the
workflow document is related. The step includes the references to
zero or more input or output documents as the
DocumentEntry.uniqueId of all the referenced clinical documents.
As a result, a single stored query is sufficient to get all references to
the clinical documents. With these references the documents may
be directly retrieved.

The metadata for each of the referenced documents should be
added to the input or output reference section in the XDW
document specification to avoid the need to perform as many
queries as there are referenced documents. We suggest thes e be
added. the words "step status code" and "step status description" Medium
Replace
by "step code" and "step description".




Replace by: "This reflect the reality that in a multi-organizational Medium
environment future steps are an “expectation” shared by one
professional with others that will rely upon their medical judgment
and the latest information to perform or not such expected
activities within the constraints of the workflow description”.


Replace point 4 by:                                                     Medium
"4. This profile specifies no rules for controlling the succession of
steps except through the reference to a workflow definition as
specified by the workflow document typecode and description."

It is proposed to make it more simply : "These profiles built upon      Medium
XDW will be called Workflow Profiles."
Replace by:                                                            Medium
"This document is used to manage all context information about a
workflow. It references the specific workflow definition that
constraints the participants of the workflow. It also tracks the steps
of the workflow which is followed, manage the documents related
to each step of the clinical workflow and its changes as it evolves
step after step. The Content Creator shall be able to create XDW
Workflow Document as specified in ITI TF-3:5.3 (?)"
Replace by:                                                           High
"• The Inputs contains step-specific information to be recorded and
shared for future workflow participants that need to know what
information was relevant for performing the step. In particular it
will contain references to documents used in performing this step.
For example, this could contain a reference to a referral request. It
may also contain references to "parent" workflows to which this
workflow is a "child".
• The Outputs contains step-specific information to be recorded
and shared for future workflow participants that need to know
what information was produced as a result of performing this step.
In particular it will contain references to resulting documents. For
example, this could contain a reference to a report written by a
specialist. It may also contain references to "child" workflows
initiated by this workflow as a parent. "

                                                                     Medium



Rewrite in a factual way per the IHE ITI Tech Committee discussions High
and conlusion for the nitch to be addressed by XCF. See comments
on section 1.7 and 2.2.X


Replace: "Added the Cross-Community Fetch Profile for exchanging High
medical data between stateless gateways that facilitate multiple
dimensions of communication (trust, semantics, encoding,
legislation, authority, etc.)." by:
"Added the Cross-Community Fetch Profile for acessing limited
medical data between stateless gateways."
                                                                        High
Replace: "The Cross-Community Fetch (XCF) profile defines a single
transaction for exchanging medical data between gateways that
facilitate multiple dimensions of communication (trust, semantics,
encoding, legislation, authority, etc.). The profile is highly inspired
by the Cross Gateway Query/Cross Gateway Retrieve transactions
and integrates these originally distinct transactions 180 in order to
allow for keeping responding gateways to remain stateless,
controllable, and simple."
by: "The Cross-Community Fetch (XCF) profile defines a single
transaction for accessing limited medical data between gateways.
The profile is highly inspired by the Cross Gateway Query/Cross
Gateway Retrieve transactions and integrates the originally distinct
query and retrieve transactions when patient data to be accessed is
limited to a limited number of instances and types of documents,
without the need for document consumer selection. In exchange of
these limitations it allows for keeping responding gateways to
remain stateless."
Replace: "The Cross-Community Fetch Profile defines a transaction High
for exchanging medical data between gateways that utilizes pre-
negotiated processing to conceal differences in semantics, manage
legal constraints, etc. The transaction fetches a small number of
documents based upon a few retrieval parameters. This transaction
is simplified to permit easier implementation and excellent
performance. The simple fetch operation permits the
implementation to be stateless. Stateless gateways are much easier
to design and implement than stateful gateways.
The legal, security, and privacy considerations for a transaction can
be well defined and ramifications controlled. Transcoding and
translation of the documents and other data can be performed on
the gateway as part of the transaction. This transaction allows a
wide variety of privacy and security alternatives."
By:
"The Cross-Community Fetch Profile defines a transaction for
accessing medical data between gateways in specialized
environment that utilizes pre-negotiated processing to conceal
differences in semantics, have limited range of healthdata to share,
and do not forsee evolution to support the need to selective access
etc. The transaction fetches a small number of documents based
Remove statement                                                        Medium


This statement need to be corrected as there are other attributes    Medium
such XUA assertions that may be used.
Needs rewrite.                                                    Medium




Rewrite the following section (changes not suggested): "By using     Medium
the Cross Gateway Fetch transaction, the participating gateways
and actors do not have to take care of these identifiers and all the
intermediate formats and processing are fully hidden to the human
requestors and their IT systems. For accessing the requested,
transcoded data all security checks must only be performed once
(including certificate verification, consent fetching, policy
enforcements) and common information for policy discovery and
assessment (particularly patient identifier and document type) is
available at the responding gateway before any medical data has
been accessed."
Replace: "If the data matching the request is too large to be packed Medium
into a single response, an error is thrown by the Responding
Gateway."
By:
"If the set of documents matching the request is too large to be
packed into a single response, an error is thrown by the Responding
Gateway."
Replace: "Health data sharing among autonomous regions usually is High
limited to an agreed set of documents because, for example:
• Many of the use cases of cross-regional care cover unscheduled
care scenarios where a physician does not want to access the full
EHR of a patient but is rather interested in 310 aggregated health
status information
• Reimbursement regulations only cover specific phases of a
treatment (e.g., Dutch patients being allowed to go to Germany for
certain surgeries) that only require access to a defined set of
documents"
by:
"This genral use case can be supported either bY XCA or XCF. In this
general use case, the following refinement leads to a use case
suited for XCF.
The health data sharing among autonomous regions is limited to an
agreed set of one or two documents. For example:
• The use cases of cross-regional care is limited to cover
unscheduled care scenarios where a physician does not need to be
provided with access the full EHR of a patient but is offered only
access to aggregated health status information.
• Reimbursement regulations may cover only specific phases of a
treatment (e.g., Dutch patients being allowed to go to Germany for
certain surgeries) that only require access to a defined set of
documents".
Change arrows on left part and right part as dotted lines.           Medium



Change arrows on left part and right part as dotted lines.        Medium




Clarify.                                                          Medium


Clarify.                                                          Medium




                                                                  Low

Change "carying" to "carrying"
We need to validate and remove or correct.                        Medium
Recommend that changes that would cause inconsistency should not High
b processed automatically, and changes for the transaction require
manual intervention according to instituional policy and human
judgment.
Change "constraint" to "constraints"                               Low


Is it appropriate to use URLs that may not be permanent?             Medium


Change "just" to "only"                                              Low


Change "constrained" to "constraints"                                Low


Change "include" to "includes"                                       Low


Change "situation" to "situations"                                   Low


Recommend that em-dashes with no spaces for this usage.              Low


Change "for keeping responding gateways stateless and simple." to    Low
"responding gateways to be stateless and simple."
Change "multiple transactions" to "multiple transactions (i.e.,      Low
separate query and retrieve transactions)"
remove comma between "scenarios" and "which"                         Low

Change "decoupling" to "decoupled"                                   Low

This a a key question that needs to be answered, particularly wrt.   High
documentIds, before moving forward.
Need more clarification on this issue.                               Medium

Recommend that em-dashes with no spaces for this usage.              Low

This paragraph is unclear.                                           Medium

Change "max" to "may"                                                Low

Delete "away"                                                        Low

Delete "even"                                                        Low

Change "packed" to "returned"                                        Low

Do you mean "policies" instead of "services"?                        Low

Please use consistent convention for "data set" vs. "data-set".      Low
Preference is for the former.
Remove "depicted above" since layout may not remain consistent.      Low
Suggest changing "In this scenario" to "Though thee is no           Low
requirement that the responding gateway rely on any IHE profiles or
actors (e.g., XDS or XUA), in this scenario"
Change "and allowing" to "allows"                                   Low

Is it appropriate to use URLs that may not be permanent?                 Medium

Change "you are reducing" to "reduces"                                   Low

Change "lists below" to "listed" in Table 3.Y.4.1-1"                     Low

Change "etc. A technology that is used often is Encryption." to "and     Low
encryption."
Change "examines where there still exist gaps and fills thos gaps        Low
with:" to "addresses additional encryption mechanisms to support
confidentiality:"
Remove this redundant sentence: "This supplement supports                Low
situations not supported well with other transport specific encryption
means."
Change "some kind of" to "pre-existing"                                  Low

Change "guidance on use" to "guidance for use"                           Low

Remove this redundant sentence: "Policies may determine what to          Low
encrypt and encryption may enforce policies."
Change "IHE portfolio" to "IHE profile portfolio"                        Low

Under "IHE XDM Email Option (using S/MIME)" in the "When to              Low
use?" column change "upto" to "up to"
Under "IHE Document Encryption (NEW)" in the "When to use?"              Low
column change "intermediaries or more unanticipated" to
"intermediaries or unanticipated"
For use case 7 under the "Use case" column change "apriory" to "a        Low
priori"
Don't let orphan lines span pages within a row.                          Low

Add period to end of sentence.                                           Low

Is the password supplied "by" the patient or "to" the patient. The       Low
context is unclear. Is the patient given the password when they
receive the records, or does the patient give the password to the
recipient--both, right?
Recommend that em-dashes with no spaces for this usage.                  Low

Change "reconcile e.g." to "reconcile, for example"                      Low

Please consider onssitent spelling and capitalization of "e-Mail", "e- Low
mail", "email", or "eMail">
Change "with the applicable policies" to "with applicable policies" Low

Change "information is stored, is exposed or lost" to "stored            Low
information is exposed or lost"
Change "anonimization" to "anonymization"                                Low
Change "who each" to "each who"                                        Low

Add comma between "types" and "thereby"                                Low

Remove duplicated and redundant sentences: "The profile allows…" Low
and "This makes it suitable…"
Change "aspects to allow for policy ranging" to "and allows for" Low

Add comma between "together" and "for"                                 Low

Change "may still be decrypted and used." to "integrity has been       Low
maintained and its purported provenance reliable."
This implies a dependency to the "Support for Metadata-Limited         Medium
Document Sources" supplement.
Change "when encryption" to "when and how encryption"                  Low

Add ", or in combination" to the end of the sentence.                  Low

Change "Standard" to Standards"                                        Low

Add comma between "CBC" and "or"                                       Low

Bold "or"                                                              Low

Bold "and"                                                             Low

Some mention of CRLs would be useful in this section.                  Low

Add "(symmetric)" before "content" to make relationship between        Low
PKI and symmetric keys clearer.
Replace by:                                                            Medium
At any time, if a participant chooses to advance the workflow for a
specific patient, it shall create one (or more) new step by adding
this step to the most recent instance of the workflow document.
This new version of the workflow document is then published as a
replacement. The prior version being replaced is then placed in a
deprecated status so that only the most cuurenty workflow
document is active. The technical description of the updating of
the workflow document is specified in ITI TF-3:5.y.
Add an s to the last word of this section.                             Low
"If all participants in a workflow are part of the same XDS Affinity
Domain, by requiring that all documents referenced within a
specific Workflow Document be placed within the folder that
contains the Workflow Documents."
Medium




Medium
                                                                    Medium




                                                                    Medium




Suggest to encode this attribute as a ParticipantObjectDetail element Low
Add sentence.
Simplify the text within the table and introduce a section dedicated
to this status flag. The table entry should include:
"For a Workflow Document, two unique codes are defined for the
overall workflow status: Workflow Active and Workflow Inactive.
Each instance of the Workflow Document shall have in its
eventCodeList either Workflow Active or Workflow Inactive
indicating the choice made by the author of the most recent step."
A new section should be created to include:
"An overall workflow status code is required to be set by each
author of a new step. Such a status code is provided to be used as a
“key words” for queries to distinguish between active and non-
active workflows.
This activity status code is required to be present in every workflow
step, and shall take either the value active or inactive.
By setting this activity code to active, a step author indicates that,
per the workflow definition and the step author further steps are
expected to be performed. There are no XDW rule that prevent
By setting this activity code to Inactive, a step author indicates that,
per the workflow definition and the step author no further steps
are expected to be performed.
There are no XDW rule that prevent a workflow with an activity flag
set to inactive to be updated (further steps) with further steps, or
with an activity flag set to active to never be updated (no further
steps).
This activity code shall be present for all XDW documents in its
Replace by: " uniqueId - Contains the unique identifier for the
overall workflow instance. This identifier is created by the creator
of the first step and remain fixed, even as new workflow steps are
been added."
Replace by:
by:
"The steps within a Workflow Document can reference zero, one or
many clinical documents related to the workflow tracked"

Change "step by adding this step" to "steps adding"                        Low


                                                                           Low
Such workflow definitions are simply referenced by a unique
identifier.
                                                                           Low
Need to be tracked in distributed environments, so that the
workflow participants need to know the most recent step
performed, and what was the history of past steps. Only
“information about the workflow history so far”                      is
shared, ; no  centralized workflow manage               systems       is
needed for XDW.
add the acronym XDW in front of the titles in sections x.1, x.2    Medium
(delete words/text), x.5 (XDS??!) for consistency and so that the
TOC of is more readable (per Supplement Template)
e.g. "GP" should be "GP/Document Source/Content Creator" - this is Medium
in many places
x.2.1 should be x.3 and named "XDW Actor Grouping and Profile            Medium
Interactions";

You need to be very clear about this. Are all creators required to be    High
consumers to get prior input? If so, how would one start the
workflow? You are going to have a problem because you have two
things in conflict. Creators need the previous input but developers
may not want to take on that responsibility - The first actor does not
need to be a Consumer. Why does the man in the middle have
Document Import as an Option?
Be more precise. There is no longer an XDS profile. Do you mean          Medium
XDS.b or the XDS family?

… an XDW                                                                 Low


An XDW ..                                                                Low


                                                                         Low




                                                                         Low


The XDW document is used to track the steps of the clinical            Medium
workflow and to manage the documents related to that workflow. As
each step is executed, the XDW is modified by appending that step
information.
This new version of the workflow document is then published as a
replacement and the previous version is deprecated. The technical
description of the updating of the workflow document is specified in
ITI TF-3:5.y. All deprecated Workflow Documents, as well as the
most recent (active) Workflow Document are placed in a ―Folder‖so
that the folder uniqueId provides a stable reference to an instance of
a workflow, while the workflow document uniqueId is different for
each of the various past versions of the workflow.

There is no requirement that all referenced documents (clinical
documents referenced as Inputs or Outputs inside the Workflow
Document) be placed by reference within this same folder.
What is the "it" at the end of this sentence. There are two documents Low
floating around. Please be specific.

The wording in this sentence is awkward. Re-write                   Low


The following UML diagram represents …                              Low


All "Sequence Diagram" should be "Process Flow" - also true in      Medium
Appendix; current xx.1..2 "Process Flow" should be "Use Case"

This use cases described need to be regarded as possible
examples and not as an exhaustive solution to the real life
scenarios. The use case are not intended to constrain nor replace
future profile development that other IHE Domain would
perform.




This section describes the the content of the XDW...                Low


The XDW Content Profile is based on the rules specified on ― in Low
the Patient Care Coordination Technical Framework about how
organizes content modules are organized categorically by the base
standard. XDW uses one in the base standard, CDA Release 2.0.
So For CDA Release 2.0 where the modules are organized by
document, section, entry, and header elements.


The purpose of t The CDA header is to enables document exchange Low
across and within clinical institutions and facilitates document
management; the header of a Workflow Document contains all the
necessary informationins to identify the document it self, the
workflow type, the first author, and organizastion involved.

                                                                    High


                                                                    High
When the first step of a new workflow is completed, the XDW           High
Content Creator shall:
- create the first version of the Workflow Document and t

Then the grouped XDS Document Source shall:
- submit it the Workflow Document to the XDS Document
Repository using ITI-41 Provide and Register Document set. The
Document Source
 puts the Workflow Document in a new Workflow Context Folder.


For each subsequent step in the Workflow, an XDW Content Creator High
shall

- obtain the most recent version of the Workflow document, (eg
using a grouped XDS Document Consumer)
- updates the content in the Workflow Document (e.g., by adding a
new step.. ) and t

Then the grouped Document Source shall replaces the Workflow
Document with its new version. This new version is automatically
added
to the correct Workflow Context Folder by normal XDS rules for
document replacement in the context of a folder.

The process for updating the document is:
• Open the existing workflow document
   o Add or update workflow steps
   o Re-register (update) the workflow document by performing a
document replace
                                                                      High


                                                                      High




The GP examines him and some of his the reports in relation with      Low
related to his health problem.

Such shared workflow state information allows the various               Low
participating systems to be aware of the history (past steps) of any of
the workflows known for a patient, access the workflow's current
state and remain coordinated by updating this shared
document with the new steps they have performed.


Benefits many clinical and non-clinical domains by avoiding           Low
different competing approaches to workflow management.
interoperability.
There are two partially documented mechanisms that are                High
mentionned in the Public Document:
1 - Use the intra document CDA Replace (RPLC) versioning. The
document SetId could be workflow instance unique Id. However, it
is not queryable as absent from the XDS Document Entry. The
specification is not clear if the Document set Id should be the same
as the folder Id.
2 - A Folder shall be used and the folder Unique Id used for globally
identifying the overall workflow instance. All XDW WF documents,
from the first one throughout all the replacement XDW WF
documents would be placed in the same folder. The use of folder
has the weakness that creating of XDW documents across multiple
federated XDS affinity Domains with XCA is not curently supported.
One should note that introducing a new "Workflow Instance Id" and
track it as the Document Set Id, so that it is availble in every
replaced instance as the workflow steps unfold and adding it to an
existing XDS Metadata attribute, such as the event code list would
not offer the support of a "race condition resolution" between
concurent attempts to repalce the same XDW document.
It is therefore proposed to:
1 - Support the use of folders to identify the group of previous and
current workflow documents related to a single workflow instance.
Believe that the use of folders be entirely optional and the          Medium
organization entirely driven by the needs of the clinical/business
case.
Remove the requirement for workflow documents to be in folders.       Medium




An XDW profile defined code and display name are required. "XDW Medium
Workflow Context Folder" is fine as "codeListDisplayName". A code
value need to be assigned by IHE ITI for "CodeList".
                                                                    Medium




Consider using the PCC XDS-MS Referral document rather than a       Low
generic document.

Suggest that 90% of the words in this section be deleted. The        Low
diagrams are self-explanatory and only need a quick paragraph to set
up the use case.
                                                                     Medium




It is proposed to specify in XDW Volume 1 and Volume 3 a             High
"predefined" workflow step with a code "workflow locked", the
expiration date and time being placed in the end service time of the
XDW object. This expiration date/time for the lock is informative",
as care emergencies may require overriding this expiration time. If
a specific workflow definition needs to add any supplemental
information a document may be referenced in the workflow step
output. This will allow workflow mgt application to include the
locking support across any workflow.
In addition, there should be a new section added in volume 3 to
describe the handling of a race condition between two document
content creators/sources that perfrom a replace operation on a WF
document, and the provider and register transation replace
operation fails as the replaced document is deprecated. In this case
the XDW document creator shall be required to repeat the WF
document replacement, by first identifying the current workflow
document, and performing a new replace operation.

Explain requirements for handling simultaneous updates, in Vol. 1 in High
the general sense of a requirement on the actor and in Vol. 2 more
specifically.
it is entirely possible that I missed it, but I tried to step through all of High
the diagrams… what is the intent to either mitigate/eliminate/ or fix
the problem when two different locations/actors retrieve the WD
from the Document Repository, make changes independently/
simultaneously, and then re-submit to the Doc Repository? couldn't
a work step be lost when the next user replaces the existing
document?

x.4 should be "Use Cases" (get rid of dash); consider just deleting        Medium
the section labeled Story Board everywhere; not in the template




                                                                           Medium
                                                                           Medium


The design choices of XDW should anticipate XCA support as much High
as possible. It is clear that, based on these comments, and the open
issue on solution to support the back link from any document to
any referencing XDW objects, there is only one extension needed.
It is to ensure that the affinity domain in which an XDW Document
has been created (and its containing folder) shall exist within a
single affinity domain (race condition and identification of the
overall workflow through folder Id). Therefore the Home
Community Id where a workflow document resides shall be tracked
as an attribute of the workflow document, so that a federated use
of "XDR" may ensure that any replacing document is placed within
the initially created folder without requiring a complex discovery
process.
BPMN, enables processes to define 'documents' as 'message flows',
which can be annotated with Metadata values (data objects). The doc
class / doc type /format code , could be defined as
Eyecare/Referral/request within the eReferral message flow of this
process definition.
                                                               High




                                                               Medium




The XDW Document illustration shows how an XDW Document        Medium
containing a Workflow Definition is exchanged between "edge"
applications using Document Sharing infrastructure.
Authors Comments              tag   status




to do: example of CDA

the Vol3 is been changed
with a new standard           CDA   close
                              CDA
to do: table to explain CDA

the Vol3 is been changed
with a new standard                 close




true                          CDA


the Vol3 is been changed
with a new standard                 close
                           CDA
the Vol3 is been changed
with a new standard              close
                           CDA




the Vol3 is been changed
with a new standard              close
                           CDA




the Vol3 is been changed
with a new standard              close
                           CDA
the Vol3 is been changed
with a new standard              close
                                 CDA

the Vol3 is been changed
with a new standard                            close
                                 comment



                                               close
it is in confloict with many     description   close
others comments where is
said that the use case are too
described
                                 Doc Format    close

vol 3 is changed
                      Doc Format   close




vol 3 is changed
                      Doc Format   close

vol 3 is changed
                      Doc Format   close

vol 3 is changed
                      Doc Format   close

vol 3 is changed
                                   close




use case is changed   english
                      figure       close

ok
                      figure       close

ok figure titles
                      figure       close

figure nor readable
                      figure       close

ok figure titles




yes                   Folder       close




ok                    Folder       close
the use of folder should be
define t the livel of profile
and not of template             Folder       close
                                format       close

OPEN template format
                                format       close


it is an introduction
                                general      close
see Doc open isseu (just a
few comments)
                                             close

the use of a reference to the
template                      Info in the WD
                                             close




the XDW can not have clinical
info                          Info in the WD
                                New actors   close
nore in XDS there is a
controle, XDW doesn't want
a centralized system of
control but there could be
some brokers if need (shold
we introduce the broker?
This year?)
                                             close


OPEN PCC                        PCC
                                   close




ok                          PCC
                            PCC    close



comment
                            QPRH   close

qprh has analyzed the XDW
                         repetitions   close
the template says to
duplicate the sections
                         repetitions   close



ok
                         repetitions   close
 it was request by the
committee a general
introduction
                             repetitions   close


                             repetitions   close


                             repetitions

                                           close
                             repetitions   close




                                           close




ok: to do template definition template
 a step when it is write is                close
finished; a workflow
document can remain open
for long time                 template
                                         close




1) ok
2) ok
3)OPEN: discussion on duble
dispensation
4)no, could be 2 different
persons                     time window
                                  typo   close

OK
                                         close
for the first year we focuse
on a single Community but
XDW will support also XCA
iit dipends by the specific use          close
case; the rules will be defined
by the domain which will use
it
                                         close

the Vol 3 it has been
modified
                                         close
see rules human task (vol 3
changed)
close
close




close
This comment is not on XDW         close




1) the global idea of XDW
isn't a simple record of past
step; It suppose that there is
a sharing on knowlege
between the different actors
2) is it correct? Should this be
the format of the name?
3) every contribute is
welcome                            close



ok                                 close
ok   close


ok   close




ok   close


ok   close




ok   close


ok   close


ok   close


ok   close


ok   close




ok   close
ok                              close




ok                              close




ok                              close




close: the advice document
can be created by a different
author                          close




ok                              close
ok   close




ok   close




ok   close




ok   close




ok   close


ok   close
ok   close




ok   close


ok   close
ok   close




ok   close
ok   close




ok   close
ok   close




ok   close
ok   close




ok   close




ok   close
ok   close



ok   close




ok   close
     close

ok


ok   close




ok   close


NO   close


ok   close
no                               close




ok                               close


ok                               close


ok                               close


ok                               close
                                 close

ok



ok                               close
                                 close

ok



ok                               close
                                 close




ok: charles already substitute
it
                                 close




ok




ok                               close
                              close

ok
                              close

ok
                              close

ok


ok                            close

no: problem with pharmacy
and possible problem with
other domains if the
examples are not sufficient
detailed                      close


ok                            close


ok                            close




ok                            close




ok                            close


no                            close


no                            close
ok   close




ok   close


no   close




ok   close


ok   close
     close




ok
     close


ok
ok                                         close



no                                         close




OPEN: use of the folder and
mechanism                       Folder     open
                                Folder     open
use of the folder is still an
open issue
                                Folder     open



use of the folder is still an
open issue




the code of the metadata is
mandated by IHE or defined
by the Affinity Domain?         metadata   open
                              metadata      open




the code of the metadata is
mandated by IHE or defined
by the Affinity Domain?
                              PCC: XDS-     open
                              MS
open
                              repetitions   open


                              repetitions   open




cancel the use case?




lock a workflow (so a
workflow can remain locked
until an other workflow is
done) and race condition

where put it?                 time windowopen
                              time window open
                              time window open




race condition
                              use cases   open
OPEN: semplification of the
use cases

OPEN: creation of a section
which describes what the
different project/domain
have to customie                          open
                              work for domains
                              XCA         open

open
                                          open




ok homeCommunityId,
problem XCA                   XCA




                                          open
                                      open




                                      open




Ok we leave for PC, it is a
style decicision to take




                              close
Cross Community Fetch (XCF)
Cross-Enterprise Document Workflow (XDW)
Document Encryption (DEN)
Support for Metadata-Limited Document Sources
XAD-PID Change Management (XPID)
Other
High
Medium
Low

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:11/22/2012
language:Unknown
pages:214