Documentation and Testing XDR-XDM Meeting 2010-10-29

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

• Moved to the next point in John's comments in the discussion
  • [1]
• Addressed the special headers (SOAP) case

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