Ballot Reconciliation

Secure HL7 transactions using Internet mail

Prepared by Gunther Schadow. April 23, 1999.

  1. Overview
  2. NAME

    ORGANIZATION

    VOTE

    Alan Stone

    Duke University Medical Center - IS

    AFFIRM

    Anthony Julian

    Mayo Foundation

    AFFIRM

    B. Patrick Cahill

    Mayo Foundation

    ABST

    Beverly Wilson

    SMS

    NEGAT

    Charles Meyer

    McKessonHBOC

    ABST

    Clement McDonald MD

    Regenstrief Institute for Health Care

    AFFIRM

    David Shaver

    NeoTool Development, LLC

    AFFIRM

    Denise Koo MD

    Centers for Disease Control and Prevention

    NEGAT

    George (Woody) Beeler Jr PhD

    Mayo Foundation

    AFFIRM

    Gunther Schadow M.D.

    Regenstrief Institute for Health Care

    AFFIRM

    Jean Spohn

    Group Health Cooperative of Puget Sound

    AFFIRM

    Jeanne Greet

    SMS

    NEGAT

    Joan Duke

    Health Care Information Consultants

    AFFIRM

    Joann Larson

    Kaiser Permanente

    AFFIRM

    Kathryn Blyler

    SMS

    NEGAT

    Lawrence Reis

    Wizdom Systems, Inc.

    AFFIRM

    Margaret Weiker

    Electronic Data Systems

    AFFIRM

    Mark Shafarman

    Oacis Healthcare Systems, Inc.

    AFFIRM

    Mark Tucker

    Regenstrief Institute for Health Care

    AFFIRM

    Michael Cassidy

    SMS

    NEGAT

    Michael Henderson

    Kaiser Permanente

    AFFIRM

    Norman Daoust

    Partners HealthCare System, Inc.

    AFFIRM

    Robert Dolin MD

    Kaiser Permanente

    AFFIRM

    Robert Mazanec

    NeoTool Development, LLC

    AFFIRM

    Stanley Huff MD

    Intermountain Health Care

    AFFIRM

    Stewart Haight PhD

    SAIC

    AFFIRM

    Susan Abernathy

    Centers for Disease Control and Prevention

    AFFIRM

    Wesley Rishel

    Wes Rishel Consulting

    AFFIRM

    Summary

    AFFIRM

    21

    80.8%

    NEGAT

    5

    19.2%

    ABST

    2

     

    TOTAL

    28

     

    The ballot passed in the first round.

    In addition we could work out agreements that would deal with all negative votes so that the voters can either withdraw their negatives (CDC) or turn it into an affirmative vote (SMS voters.) Comments for changes came from SMS and CDC. All comments and their disposition will be described in the following two sections that also contain draft motions to close each issue. The discussion and votes will be held at the Toronto SIGSECURE meeting on Tuesday April 27, 1999.

  3. SMS
  4. The reconciliation was negotiated with Glen Marshall, System Security Architect.

    1. Major Issues
    2. 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.

    3. Minor Issues
    4. 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 3rd paragraph 1st 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.

    5. Suggestions
    6. 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.

    7. Typos and editorial suggestions

    Editorial suggestions

    ID

    SECTION

    PAGE

    VOTE

    REVISION

    5

    1.3

    6

    ASUGG

    heeded

    6

    1.3

    6

    ASUGG

    heeded

    COMMENT: 1. 2nd paragraph indicates future references to a past (Jan/98) date. Suggest rewriting paragraph to be historical, rather than hopeful.

    2. Footnote #3 (from the 2nd paragraph) indicates E-mail list server names. Verify these are correct prior to final document version.

    RESPONSE: Those paragraphs that talk about the document in draft status are certainly obsolete now.

    MOTION 9: Delete paragraphs 2 and 3 of section 1.3.

    Clarification of language

    ID

    SECTION

    PAGE

    VOTE

    REVISION

    11

    3.1.5

    16

    ASUGG

    heeded

    COMMENT: Item 3 (Non-repudiation of commitment) – the first sentence is difficult to understand. It currently says:

    Non-repudiation of commitment is to assure that neither party that is involved in a transaction communicated by the exchange of messages can later deny the agreement to the information exchanged and its implied obligations.

    Would it also be correct to say it this way:

    Non-repudiation of commitment assures that neither party can later deny that they agreed to the information exchanged, and its implied obligations.

    RESPONSE: Yes

    MOTION 10: To implement the change as proposed.

    More editorial suggestions

    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

    COMMENT: 1. Page footers: Change publication date to be current (it currently says "December 15, 1998").

    2. Extend the Copyright date from "1998" to "1998, 1999".

    3. 4th paragraph, change "…can be browsed by all most (sic) mail programs including Netscape" to "…can be browsed by most mail programs".

    4. 1st paragraph, "…of a few tens of seconds" might better be expressed as "…of one-half minute".

    MOTION 11: To implement the changes as suggested.

    Typos

    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"(?)

    MOTION 12: to implement all changes (except ID 24) as proposed.

  5. CDC
  6. The changes where negotiated with Joseph Reid and Steven Steindel.

    1. Issues

COMMENT: The described transmission format cannot endorsed by CDC for transmission of data to public health.

According to our technical experts here at CDC, the document itself is a very good description of how to do secure Internet E-mail, but [1.] it implies in the opening pages that public health will accept information in this form. Based on the current thinking, we would prefer not to. If we did, it would not be in the format recommended in this document.

[2.] Secure Internet E-mail as a standard transport method for regular operations (rather than ad hoc) is a bad idea. Our technical experts think public response will be negative to the idea. Standards of encryption, signature, etc. including key length should be the target. Internet E-mail is an easy to imagine but flawed standard for transport.

[3.] In addition, the document makes no mention of key size. CDC will not accept sensitive information unless a minimum of 128 bits is used for the key and this needs to be stated and discussed.

RESPONSE: 1. The term "public health" is not limited to CDC and was not intended to refer to CDC.

2. Further clarification revealed the following threat for CDC. Since some e-mail is relayed on its way from the originator to CDC, there could be the opportunity for someone to intercepted and accumulated. Even though the messages are encrypted, the interceptors could make the claim they would posses significant amounts of privacy act related sensitive patient data. This mere claim could cause severe damage to the CDC or any other health surveillance agency. — We acknowledge the existence of this threat. We believe, however, that there are countermeasures available that would allow e-mail communication to be secured against this threat.

3. The document does discuss the issue of key length in considerable detail in section 3.2.1.2 and 3.2.1.3 [p. 18–20]. This includes the recommendation that the Data Encryption key should have a length of at least 128 bits.

RESOLUTION: 1. Joseph Reid did not believe that this very paragraph needed deletion or revision as long as issue number 2 is mentioned.

2. This matter will be discussed in a new paragraph to be added into the text of the document.

3. Issue withdrawn by Steven Steindel.

MOTION 13: To append the following paragraphs to section 3.1.4:

Intercepting of messages can pose an additional threat besides the actual unauthorized disclosure of information, traffic analysis and more subtle threats that can some public organizations may be vulnerable for. Traffic analysis is the gathering and recording of knowledge about data flows related to an entity or a group of entities. Even though no payload information is disclosed, merely taking notice of the fact that two entities communicate with each other can be a breach of privacy. For example, the fact that a patient consults a specialist in HIV may reveal that this patient may potentially be infected with HIV, and thus may it is a breach of the patient’s privacy.

The more subtle variant of intercepting traffic without disclosure of payload information is described in the following scenario: Suppose a major public health agency is collecting HIV surveillance data from health care practitioners all over the country . A group of activists is intercepting a portion of the messages directed towards the agency. This group can then claim in the media, that it posses large amounts of sensitive data protected by privacy laws.

Direct patient related traffic analysis is not an issue since HL7 messages are not sent directly between a patient and a health care provider. The other threat can be minimized by ensuring that as much data as possible is encrypted or bare of any interpretability. Furthermore routing and relaying through un-trusted nodes should be reduced to a minimum. This threat is relevant especially for e-mail communication, since e-mail may be relayed through un-trusted nodes. However, the delivery path of Internet e-mail is under the control of both communication partners who should make sure that e-mail is only routed through trusted nodes if they are subject to the traffic analysis threat.