AFFIRM	21	80.8%
NEGAT	5	19.2%
ABST	2
TOTAL	28

1. Major Issues

Applicability

ID	SECTION	PAGE	VOTE	REVISION
1	all	all	NMAJR	resolved

COMMENT: Generally, SMS approves of the technical details as stated in the document. However, SMS has great difficulty accepting this as a method of exchanging real-time, event-based data. The potential problems in the area of support (e.g., determining why one or more transactions did not reach their destination) far outweigh the need for an inexpensive implementation. The methods described are acceptable in a query/response implementation, such as a care provider requesting a recent status of his patient(s); or a scheduled broadcast of the day’s schedule to a provider, but should not be used to transmit critical data for the purpose of updating a database.

RESPONSE: This specification is an informational document. Vendors are not required to implement or support this specification and users are not required to use it in any way they feel uncomfortable with. Since the question of applicability may be controversial, this specification abstains from suggesting or discouraging any specific use. Except that it may be useful for communication between "dispersed," and "independent" organizations.

On the other hand, with Internet mail, the determination of whether and why messages fail to reach their destinations is consistently handled through message delivery failure messages. In addition this specification refers to and describes the Message Disposition Notifications that provide irrefutable verification of delivery and failure (non-repudiation of receipt.)

MOTION 1: Append the following paragraph to section 2 [p. 10]:

Internet e-mail can be configured in different ways and implementers of this specification should be aware of the alternatives and their consequences. E-mail can be sent directly from end to end if the sender can reach the recipient with a direct TCP connection. This is possible over the Internet whenever HTTP or FTP is also possible. However, e-mail routing is often configured in a way to involve relays. If e-mail is relayed timing problems and sequencing problems can occur, which is why e-mail is often believed to be slow and unreliable. It is important to note that the performance of e-mail can vary dramatically depending on the configuration. Refer to section 6.1 for a more detailed discussion.

Dealing with pending HIPAA regulations

ID	SECTION	PAGE	VOTE	REVISION
12	3.2.2.4	23–24	NMAJR	ASUGG
14	4.1	25–34	ASUGG	ASUGG

COMMENT: Must identify unique individuals to comply with HIPAA NPRM §142.308(c)(1)(v)(B). Organizational responsibility can be established with chain of trust in X.509 certificates.

COMMENT: Specify all mandatory and optional functions, per HIPAA NPRM §142.310, e.g., countersignatures and multiple signatures.

RESPONSE: The current notice of proposed rulemaking does not clearly imply that digital signatures must be of individual persons. Especially the cited section is not about digital signatures but explicitly "to control individual access to information. The §142.310 about digital signatures is much less clear. It requires in §142.310(b)(3):

User authentication (the provision of assurance of the claimed identity of an entity.)

Where the term "entity" explicitly includes organizations and "user" may well include any agent of some legal or individual entity which has the legal attributes of being able to make independent decisions and can be held liable for the results of such decisions.

MOTION 2: We will not elaborate on the interpretation of the preliminary rule but rather wait for the final rule (expected December 1999.) However, we will not delay progress of this ballot until then. Rather we will

(1) extend the existing footnote 12 [p. 24] to append the following sentence:

Upcoming final HIPAA regulations may also entail a requirement for individual signatures, although it is not clearly stated now. In any way, the consciousness requirement of the German law practice seems to be absent. When the final HIPAA regulations are released, HL7 will revise this document carefully and amend it if necessary. Users and implementers of this specification are reminded that implementations of this specification must only be used in compliance with the laws and regulation effective for such users. HL7 has no responsibility for failure of users or implementers to verify that their use of this specification is lawful.

(2) Add a paragraph in section 1.3 (Status)

As of the time of publication of this document, the HIPAA rule making about security and electronic signatures is still ongoing. When the final HIPAA regulations are released, HL7 will revise this document carefully and amend it if necessary. Users and implementers of this specification are reminded that implementations of this specification must only be used in compliance with any laws and regulation effective for such users. HL7 takes no responsibility for failure of users or implementers to verify that their use of this specification is lawful.

(3) plan a revision of this document early next year to make all necessary amendments required for compliance with U.S. regulations, and

(4) as a result of such revision add an appendix to the document that is a detailed statement of applicability and compliance of specific provisions of the HIPAA regulations.

PGP

ID	SECTION	PAGE	VOTE	REVISION
15	4.2	34–37	NMAJR	withdrawn

COMMENT: Remove references to PGP: non-standard and non-exportable technology

RESPONSE: 1. PGP is not more or less a standard than RDA Data Security Inc.’s PKCS #7 (so called "S/MIME") Both specifications, PGP v2 and S/MIME v2 exist only as publicly available specifications and as Internet RFC documents rated "informational." 2. While it is true that U.S. has export restrictions on any strong cryptographic technology, this applies for both PKCS and PGP. PKCS software is exportable only through drastic limitation of the length of the data encryption key (DEK) to 40 bits (using the RC4 algorithm) or 56 (112) bits if DES (DES3) is used. None of those alternatives would meet the requirements for strong encryption, however (e.g., CDC mandates and this document recommends a minimal DEK length of 128 bits.) 3. While PGP does not support such weak DEKs in the first place, PGP is already available internationally. Both, the U.S. and International versions are compatible, so that vendors can ship products internationally using strong cryptography.

2. Minor Issues

Sequencing and Timing

ID	SECTION	PAGE	VOTE	REVISION
16	6.1.2	53	NMINR	ASUGG
17	6.1.2	54	NMINR	ASUGG

COMMENT: Make provisions for data to represent message relationships for application-controlled or database sequencing

Protocol should provide for time-out of time-sensitive messages

RESPONSE: 1. Sequencing: a) In negotiating this specification we have pursued this idea in the IETF. However, our proposal to the IETF EDIINT working group did not find much resonance at that time. We did, however, succeed in specifying a way to securely link pairs of request and response messages to each other [p. 32f]. This chain can be extended to link any follow up message with secure identification of a prior message that establishes the new message’s context. b)  Because we believe that there are simpler solutions, we also mentioned those in the text of the document [p. 33]. We did, however, not proceed in making this part of the specification because we are still hopeful that the idea will find resonance in IETF, so that we can maintain full compatibility to the Internet standards.

2. Timing: It is an interesting idea to allow giving each message a "time to live" after which the message expires and will not be processed any more. Part of this feature is already supported by the message disposition notification of type deleted/expired [p. 30f]. This feature could be controlled by a mail header such as "Expires: á timestampñ ".

MOTION 3: Since a change of the specification in this matter would be a substantial change that would require complete re-ballot and since the features are not critical components of the specification, we will not make these changes now, but rather continue to work on these ideas in order to include them in next year’s revision of the document.

Journalizing

ID	SECTION	PAGE	VOTE	REVISION
21	6.4	58–59	NMINR	heeded

COMMENT: There is far too much detail regarding how the processing should occur, especially in the discussion of journaled messages. This should be restated as "for example", thus allowing individual implementations to satisfy the requirements using the method best suited to their environment

RESPONSE: Both the introduction to the document [S. 1.1, p. 5] and the introduction to section 6 itself [p. 52] state that section 6 is not normative. It is true that if the section 6 was normative it would be too detailed. The purpose of section 6, however, is to explain the elements of an example implementations for implementers seeking such guidance.

MOTION 4: We will further clarify the language by changing S. 6.4 3^rd paragraph 1^st sentence to read:

For example, in order to establish that certain messages were exchanged and accepted, the organization could maintain […]

Save encrypted messages

ID	SECTION	PAGE	VOTE	REVISION
22	6.4	58	NMINR	heeded

COMMENT: The suggestion that outgoing messages be saved as unencrypted to allow occasional "quick searching and browsing" seems to advocate a security weakness. Perhaps I misinterpreted the section, but if "disputes should be very rare", then the messages could be saved as encrypted because the overhead of de-crypting them later should occur infrequently.

RESPONSE: The issue is obviously pursuasive.

MOTION 5: We will delete this sentence entirely.

Implementation agreement contract

ID	SECTION	PAGE	VOTE	REVISION
27	6.5.2	60	NMINR	heeded

COMMENT: Any Implementation Agreement is a contract of the expectations of both sender and receiver. The section should be replaced with an encouragement to review any existing implementation agreements from a security perspective; however, the specifics about what such an agreement should contain, and implied consequences should not be part of this document.

RESPONSE: The purpose of section 6.5.2 is more an incomplete list of issues, that are technical in nature more than about security. We value the comment in two ways: (a) it shows how to improve the clarity of that section and (b) it suggests a good additional paragraph that not only adds to this particular section but is also a good conclusion of the entire document.

MOTION 6: 1. We will clarify the issue about contracts by slightly modifying the first sentence:

Because independent organizations are negotiating the interface, the agreement is a contract. This implies a higher level of scrutiny than is typical of HL7 Implementation agreements.

change to

Because independent organizations are negotiating the interface, the agreement is a contract. This implies a higher level of scrutiny than is typical of HL7 implementations within a single organization.

2. We will add a closing paragraph to section 6.5.2 as follows:

Organizations who implement communications based on this specification are encouraged to review their existing Implementation Agreements under a comprehensive security perspective. The details of such review, however, are beyond the scope of this document.

3. Suggestions

Confidentiality

ID	SECTION	PAGE	VOTE	REVISION
9	3.1.4	16	ASUGG	heeded

COMMENT: Should include sender and recipient privacy as well, e.g., non-observability

RESPONSE: This issue is about traffic analysis. It raises a valid point which will be handled together with the CDC related comment below.

MOTION 7: refer to Motion number 13

Common criteria

ID	SECTION	PAGE	VOTE	REVISION
13	4.1	25–40	ASUGG	ASUGG

COMMENT: Redo as a Common Criteria Protection Profile

RESPONSE: Rewriting almost the entire document would be a significant change and it is not clear that it would be appropriate for the audience of a technical specification. However, it is certainly a valuable suggestion to append an additional statement casting the propositions of the document as a Common Criteria profile.

MOTION 8: To put the preparation of such a profile on the agenda of SIGSECURE. The work product will be included in the upcoming revision of this document.

4. Typos and editorial suggestions

Editorial suggestions

ID	SECTION	PAGE	VOTE	REVISION
5	1.3	6	ASUGG	heeded
6	1.3	6	ASUGG	heeded

ID	SECTION	PAGE	VOTE	REVISION
11	3.1.5	16	ASUGG	heeded

ID	SECTION	PAGE	VOTE	REVISION
2	all	all	ASUGG	heeded
3	frontmatter	1	ASUGG	heeded
25	6.4	58	ASUGG	heeded
26	6.5.1	60	ASUGG	heeded

ID	SECTION	PAGE	VOTE	REVISION	COMMENT
4	1	4	ATYPO	heeded	First footnote of the document indicates "ibid." Needs to be a reference to the source (by name).
7	3.1.3	15	ATYPO	heeded	2nd paragraph, "sensible" should be "sensitive".
8	3.2.1.2	19	ATYPO	heeded	Last sentence before section 3.2.1.3 begins says "128 bit". Should be "128 bits".
10	3.2.1.3	19	ATYPO	heeded	1st sentence begins "As the terms". Should be "As the term".
18	6.1.2	53	ATYPO	heeded	2nd sentence, "trough" should be "through".
19	6.1.2	53	ATYPO	heeded	2nd paragraph, "services" should be followed by a colon (:).
20	6.1.2	54	ATYPO	heeded	Last sentence prior to section 6.2: 1) "is required and additional" should be "is required, then additional" and 2) "to to" should be "to".
23	6.4	58	ATYPO	heeded	4th paragraph, "recommendable" should be "recommended".
24	6.4	59	ATYPO	withdrawn	Caption on Table 6 says "Journalized". Should this be "Journaled"(?)

1. Issues