Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

MetadataLimitedDocSrc_public-comment-lynn-smm-1-tms

VIEWS: 3 PAGES: 14

									Submitter   Supplement Name               Other Vol       Section #        Line #
Name        (click cell and select from   Docu
            list)                         ment
                                          Name
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   330




           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



           Support for Metadata-
           Limited Document
           Sources
           Support for Metadata-
           Limited Document
           Sources
Issue



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.

I know, you want to make this as easy as possible on
Your table has separate columns 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.
Proposed Change                                                            Priority



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?




                                                                           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.




                                                 High
make R2                                          Medium




                                                 High
                                                                       Medium
At least tell the implementers to toss up an audit message or put it on High
a queue to deal with?


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.       High


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


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

								
To top