Documentation and Testing XDD Meeting 2010-08-31

From Direct Project
Jump to navigation Jump to search

Attendees


Karen Witting
Dragon
David Tao
John Moehrke
Beau
Vassil
Ron Cordell
Janet

Goals


1) Where to put routing metadata
2) Content metadata minimization
3) Mapping between RFC 5322 and XDR, including XDM and S/MIME transformation

Re-use XDD specification

Where to Put Routing Metadata


Proposal: create SOAP header

Karen, Dragon, David, Beau, Vassil, Ron agree
John Moehrke -- wants to jump up a level, discussion Exchange

Karen volunteers to take a first take at the SOAP headers, with a separate namespace.


Discussion on Relationship to XDR Standard


Optional headers

Receivers who require headers may not be guaranteed to receive them

Metadata


Karen -- we need three levels of metadata

  1. Full XDS/XDR
  2. Small than full XDS/XDR, but includes patient ID
  3. Have nothing


Have nothing -- send the signal in the SOAP header, not in ebXML, and either include empty ebXML or omit ebXML

Dragon -- agree that signal should be in SOAP header

Adds a 4th category:

  1. Not patient related


David --

Should think through has nothing to can receive everything, vs reverse case.

John --

Full to minimal not an issue, because they can always step to XDM.

Needs to be clear that the scope of the problem is inbound from lower tech senders (ed. note: or blinded HISP).

Shouldn't mandate -- receivers (at the gateway or at the endpoint) may always reject transactions due to missing data.

Beau -- Agree with the SOAP header concept -- would prefer either known dummy values or no values

David -- should endorse a solution as a SHOULD, not a MAY

Vassil -- Not sure how useful the "I have nothing" option -- patient ID and document creation date can't have dummy or default values, other fields

Ron -- would like to use default values where possible

Next Steps


Karen suggests, and John agrees we need to walk through the metadata field by field, classify with regard to the no metadata case, not patient data cases

Objections to default:

  1. Misleads receivers that you have more information than you actually have
  2. Sets a precedent that certain fields (e.g., classCode) always have nonspecific information.


Objections to omission:

  1. Makes it harder for current implementation of XDS/XDR to adapt.


Did a first pass:

Class Code


Alternatives:

  1. Omit if not provided
  2. Use 47049-2 (Communication)

Karen, Dragon, David, Ron, Arien: Optional
John, Beau: torn, no opinion
Janet, Vassil: Default generic value
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Documentation_and_Testing_XDD_Meeting_2010-08-31&oldid=286"