Status of Notes: DRAFT
Date:
Time:
Attendees:

Actions


#
Date
Action
Status
Owner
Due Date
1






Decisions


#
Date
Decision




Notes


Agenda


  • Testing status
    1. Case 1
      1. Possible change to direct combined Source/Source HISP to combined destination/destination HISP transaction


Gerge: Pretty much ready;
MedAllies to Epic: is running
Justin:


    1. Case 2
      1. Epic to MedAllies - this is working

Tomorrow we'll do a test at 2 EST
Don't have XDM yet.

      1. Do we have a specified re
    1. Case 3
      1. Let's doCase 3 on Friday at 11am EST
        1. Status of constructing XDR package from structured e-mail attachment
        2. Designating a specific sender e-mail
        3. Status of code and code repository
          1. canhave the code posted in the next day or two
        4. Last-leg XDR transaction status
    2. Case 4
      1. Tomorrow at 10:30 EST
      2. Status of REST Source
        1. Status of XDM to XDR transform
        2. Status of code and code repository
          1. pending permission to post code
        3. Receiving XDM message – designating a specific recipient address
        4. Test tomorrow 3-4
        5. End-to-end Friday afternoon 3:00 EST

  • Presenting our case
    1. Review of Current Timelines
    2. Capabilities worksheet
      1. The case for SOAP based services - does it belong here? Yes. Vassil, Karen. will write it up. Janet and Peter will review (with others).
    3. Specification: Karen has written this. We'll flesh this out once we've won the bake-off.
    4. The case for IHE: Janet to send to the discussion group in full.
    5. Determining presenter(s): Peter to present with prep help from Lee and the group. Use discussion list to generate ideas.
    6. Presentation for June 8th: we'll develop what we'd like to present and modify per any guidance we get. Plan for 20 minutes presentation with rest for Q&A. Plan for lots of Q&A.
    7. Presentation for the Face-to-Face meeting: If there needs to be a presentation, Peter will do it.
  • Review of actions and decisions
    1. Next call: Med Allies to set up LiveMeetings for testing times
    2. Sch

Discussion

Patient identifiers: limitation in needing to pre-negotiate patient identifiers. Let's use more than one patient ID. Spin this as a capability; it's not an assumption of the protocol. A benefit of our model is the manifest that can carry patient identifiers independent of the content type. Other implementations must rely on a human opening the package to find out who the patient is. We must be able to accept any patient identifier, regardless of what the domain identifier is. Let's not bring it up until someone asks us about it. In the long run, this restriction has to go away.

Peter to get Karen a PDF of a CCD.

Wrap Up