Status of Notes: DRAFT
Date: October 29, 2010
Time: 2:00pm-2:30pm
Attendees: Yvan Charpantier, Chaminda Gunaratne, Arien Malec, John Moehrke, Vassil Peytchev, Jas Singh, David Tao, Karen Witting

Notes

Arien Malec
  • Reviewed the edits he placed to the XDR and XDM for Direct Messaging
  • Asked for a quick round on Arien Malec's edits
Chaminda Gunaratne
  • No comment
John Moehrke
  • Asked if Arien Malec took John Moehrke's comments into consideration
David Tao
  • Raised points regarding the XDR use-case
  • Volunteered to prepare a rough draft of this for review by Arien Malec
John Moehrke
  • Indicated he is not sure why the Direct Project would talk to about XDR-to-XDR use case
David Tao
  • Stated that Parag More and Yvan Charpentier/Bob Barker talked about this
  • Highlighted that XDR was not appreciated by the Standards Committee
  • Clarified that if vendors are sending XDR between themselves, that does not the Standards Committee objections
    • Therefore the scope can be expanded
    • Originally did not effect that many participants, but scope has already expanded
    • Suggested there will be a goodness even if there is no conversions
  • Addressed the major concern of MedAllies
    • If we are not separating the types of metadata
Arien Malec
  • Shared that he will be talking to Dixie Baker on Monday and will raise the issue
    • Main issue: minimal data access
  • Agreed with David Tao in general
    • Where to put the Direct Address?
    • Where do you put the SOAP headers?
Karen Witting
  • Indicated that she did a thorough review before Arien Malec completed his edits
  • Reported she did take a look at the changes
    • Need to align the headers
    • Not sure about all the details
  • Stated that she agrees with all of John Moehrke's comments
    • Will take a while to digest all of the comments and Arien Malec's changes
Vassil Peytchev
  • Announced that he just joined the call
  • Agreed with the general direction
Arien Malec
  • Suggested they look through John Moehrke's comments
  • Proposed looking at the "breaking single patient rule"
    • Most substantive in terms of content and not formatting
    • Summary: The reason XDR limits to a single patient for Security and Privacy risks
      • Point 1: Do a single transaction for each patient
      • Point 2: Non-patient concerns - special patient IDs
        • Concern: If I got a process that automatically assigns with his NPI, and "dirty up" his data
        • Since you don't have a patient ID, might as well break
Karen Witting
  • Indicated she wrote the section 6.3.1
    • The solution they came to was to say:
      • If you specify any of the patient ID data, then it is a single patient and you give a clue about said patient
      • If you don't specify anything, then don't give any advice
        • The receiver can always reject this if they want to do this
John Moehrke
  • Concerned about sending non-patient data through Direct specification
    • Not sure about how the workflows could change if the data is empty
    • Not sure how this will be handled
  • Conceded that the group may potentially becorrect that "its patient-related, might as well work"
    • Regardless, need to make sure the robustness is there
Vassil Peytchev
  • Asked for clarification about the issue
Karen Witting
  • Stated that in terms of the sender, if you have the information you have to put it in
  • Asked: In terms of the receiver, what do you do if you don't have the patient data?
    • Need to make sure its single patient data
      • Patient ID
      • Local patient identifier
      • Geographic data
    • This lets the receiver know that you have single patient data
      • If not, then its unknown
John Moehrke
  • Commented if that is the intention, then we should elevate to a more broad discussion about the receiver robustness discussion
    • Does not mind about pointing this thing about patients in the broader discussion
Arien Malec
  • Liked this idea of having a receiver robustness discussion and then including a special case for patients
Vassil Peytchev
  • Asked if they could make this separate
  • Raised a point that Arien Malec clarified was already included
Karen Witting
  • Indicated that she is okay at reassessing this
    • Sounds like no one is disagreeing with the intention
    • Just not expressing this in the right manner
Arien Malec
  • Volunteered to take a pass at this in his round of edits
    • Karen Witting will look at this afterward
John Moehrke
  • Raised a concern about multiple patients in the XDR and XDM for Direct Messaging
  • Recognized that he might have mixed up what is a receiver versus receivers in section 6.1
Karen Witting
  • Stated she is okay deleting that
  • Asked John Moehrke: Do you have the case addressed in your security assessment about multiple patients?
    • Needs to be address somewhere
    • Should this be placed in the risk analysis?
      • It is not addressed in any of the policy guidance
Arien Malec
Karen Witting
  • Asked Arien Malec for clarification about the receiver
Arien Malec
  • Clarified that the receiver is the "addressee"
  • Explained:
    • He has an SMTP message to XDR
      • How is this converted to a SOAP message?
        • Option 1: Take each addressee and create a SOAP message for each
        • Option 2: Take the two addresses in the same domain and create one SOAP message for them, and then one SOAP message to the other addressee
        • Option 3: Lump all together (not suggested)
John Moehrke
  • Responded that totally makes sense if that is the case
  • Raised a concern to not be too overly prescriptive
  • Recognized the two cases:
    • One path: MX records in SMTP world
    • Other path: Not needing anything in the XDR world aside possible configuration
  • Identified that there can be multiple records
Arien Malec
  • Stated that the comment about BCC does not belong in this specific conversation, but believes it could apply to this specification
    • Somewhere in the specification he says that users should use SMTP 2 command
  • Clarified that "BCC" is an operational transfer
John Moehrke
  • BCC should not be transferred to POP/IMAP
Arien Malec
  • There is no guarantee that the BCC header information will not be sent to the receiver
John Moehrke
  • Responded that this can fall into the SMTP Robustness Principle
    • No one should be blind carbon copied or their information is carried
Arien Malec
  • Decided he will briefly address this in his current round of edits
  • Highlighted that the specification is more package conversion that the content conversion
    • In response to a question by Yvan Charpantier
John Moehrke
  • Clarified that Arien Malec is suggesting to separate the routing from the metadata in the headers
    • And need to decide in that context the BCC
Yvan Charpantier
  • Asked question about the involvement of hospitals in the context of this example
Arien Malec
  • A clinical CC is a well-defined clinical use-case
    • In the XDR use-case there can be multiple use case
Yvan Charpantier
  • Asked if there is a way to clarify between a primary and secondary recipient
John Moehrke
  • Stated that this is something the XDR folk did not prepare for
    • Will have to dig through the intended recipients list and send to who they recognize
Arien Malec
  • Pointed to the intended recipient example on the XDR and XDM specification
  • Recognized that they are at the end of the call
    • Will do an editing pass
    • Karen Witting will do a second pass after Arien Malec
    • John Moehrke will also do another pass after Karen Witting
      • Also make sure everything is consistent with his risk assessment
David Tao
  • Asked Arien Malec who to send his little portion on XDR-to-XDR
Arien Malec
  • Responded David Tao should just send it to both him and Karen Witting