Submitter Supplement Name Ot Vol Section # Line #
Name (click cell and select from he
felhofer Document intro 118
felhofer Document overview 145
felhofer Document overview 156
felhofer Document overview &
Encryption (DEN) use cases
felhofer Document use cases 247
felhofer Document use cases 258
felhofer Document 1 2.2.x 304
moore Document 1X 326
moore Document 1X 329
moore Document 1 x.3.1 349
felhofer Document 1 x.3.2 366
felhofer Document 1 x.4 369
moore Document 1 x.4 374
moore Document 1 x.5 391
moore Document 1 x.5 405
moore Document 1 x.5 427
felhofer Document 1 16.2.6 444
felhofer Document 2 3.32.3 475
felhofer Document 2 184.108.40.206.2.4 495
498 Document 2 220.127.116.11.2.4 496
moore Document 2 18.104.22.168.2.4 498
felhofer Document 514
Encryption (DEN) 2 22.214.171.124.4.1
moore Document 515
Encryption (DEN) 2 126.96.36.199.4.1
felhofer Document 518
moore Document 557
moore Document 567
felhofer Document 586 also
Encryption (DEN) 724
2 188.8.131.52.6.3 and 5.Y 2.2.3
felhofer Document 591
felhofer Document 603
felhofer Document 609
felhofer Document 614
felhofer Document 637
moore Document 659
felhofer Document 673
moore Document 826
Encryption (DEN) 3 5.y.5
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?
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
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)
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
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
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).
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?
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.
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?
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 184.108.40.206.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 220.127.116.11.2.4 and .5 as new
sections. Add an editor's box above these sections indication
"Add these new sections"
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 18.104.22.168.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
"If the Portable Media
Importer actor verifies signatures then it shall support the
It sounds like the PMI can choose to support verifying
signatures, or not. Is that correct? What if the PMC signs
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."
"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
What does it mean to handle the decrypted content with
care? Should I not drop it?
Proposed Change Priority
This supplement examines where gaps there still exist gaps and fills Low
those gaps with:
XDS and XDR and other IHE profiles require grouping with 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
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
" 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.
with flexibility in mind as systems should, for example, …
… 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
"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
Fix section numbering.
Fix DICOM reference.
Same issue as line 498
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.
- shared symmetric key
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.
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.
The symmetric key can be pre-shared or involve key retrieval,
both of which are out-of-scope of this profile transaction.
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.
It also presents the responsibilities of the Content Creator
actor and Content Consumer actors which are responsible for
encryption and decryption respectively.
Cross Community Fetch (XCF)
Cross-Enterprise Document Workflow (XDW)
Document Encryption (DEN)
Support for Metadata-Limited Document Sources
XAD-PID Change Management (XPID)