Comprehensive HIE Meeting 2010-06-01

From Direct Project
Jump to navigation Jump to search

Notes from Comprehensive HIE Workgroup


Date: June 1, 2010
Time: 2pm-3pm
Attendees
: George Cole, Didi Davis, Thanos Tsiolis, Vassil Peytchev, Noam Arzt, Karen Witting, Eric Heflin, Mark Stine, Wenzhi Li, Will Ross, Gary Christensen, Chaminda Gunaratne, Thomas Davidson, Tony Mallia, Rich Kernan, Arien Malec, Jackie Key
Actions from this week

#
Date
Action
Status
Owner
Due Date
30
6/1/10
Present NHIN Direct & Comprehensive HIE scenarios during the June face-to-face meeting
Open
WG
6/10/10
31
6/1/10
Update the NHIN Direct & Comprehensive HIE scenarios to reflect the new full/partial terminology and initiate an offline wiki discussion
Open
Vassil
6/1/10
32
6/1/10
Review and post comments on the updated NHIN Direct & Comprehensive HIE scenarios
Open
WG
6/4/10
33
6/1/10
Hold a call for consensus on the updated NHIN Direct & Comprehensive HIE scenarios
Open
WG
6/15/10


Actions from last week

#
Date
Action
Status
Owner
Due Date
29
5/25/10
Change assumptions given on the wiki to a clear list of definitions for comprehensive HIE, using full/partial terms suggested by Will Ross
Closed
Vassil
6/1/10


Agenda

  • Review last week's action items
  • Discussion
  • Next Steps

Notes

Feedback on the Comprehensive HIE Definitions

Name
Feedback/Comment
George Cole
Likes updates, particularly the notation under seamless interoperability. Full/partial definitions are becoming clearer.
Didi Davis
Full vs partial HIO capability needs more clarification and detail
Thanos Tsiolis
OK with definitions
Noam Arzt
  • What does a partial HIO do exactly?
  • Current definition for a partial HIO makes an explicit comment on applicability of NHIN Direct, but the full HIO definition does not explicitly address this
Karen Witting
Agree with previous comments
Eric Heflin
  • New definitions are a definite improvement. Should use these definitions/scenarios to vet the concrete implementation approaches and determine if there’s a gap between what they expect to provide
  • We should list minimum capabilities (required/optional) for partial/full
Mark Stine
Agree with previous comments
Wenzhi Li
Need to keep in mind that a partial HIO may have some point to point capability
Will Ross
Like definitions
Gary Christensen
pass
Chaminda Gunaratne
Wiki page should be better organized to show which go sections apply to partial/full
Thomas Davidson
pass
Tony Mallia
Question some of the assumption around seamless interoperability approach
Rich Kernan
Let’s focus on compatibility between transactions

Comment from Arien Malec

  • Distinction between full/partial capability is coming down to a HIO’s ability to solve the core NHIN Direct use cases

Comment from Vassil Peytchev

  • Agree with Arien’s view
  • In response to earlier request to define what is required for partial capability:
    • Not sure if we can define this
    • Instead, we should take Arien’s definition of full capability as providing a mechanism to solve all core use cases and partial as not being able to solve all of these core use cases
  • Goal for WG is to abstract how interactions occur between NHIN exchange and NHIN Direct


  • WG to present these definitions/scenarios during the June 10th/11th face-to-face meeting
  • Vassil to update the NHIN Direct & Comprehensive HIE scenarios to reflect the new full/partial terminology and initiate an offline wiki discussion by end of day today
  • WG to review and post comments on the updated NHIN Direct & Comprehensive HIE scenarios by Friday
  • WG to hold a call for consensus on these updated scenarios on the Tuesday following face-to-face meeting

Comment from Arien Malec

  • The scenarios as they are written should give enough guidance to the concrete implementation teams
  • We have a decent framework that has verbal consensus, though we still need to get to final consensus

Comment from Karen Witting

  • Seems that these scenarios assume that any interaction between NHIN Direct and non-NHIN Direct would use NHIN Direct protocols
  • Scenarios should be framed more abstractly, ie: in order to accomplish a particular use case you must do X

Comment from Vassil Peytchev

  • We haven’t stated what a HIO can provide to external entities that are not full HIOs
  • Assumption is that if you’re talking to a NHIN Direct actor, you are implementing a NHIN Direct transaction
  • Are translations between NHIN exchange and NHIN Direct within the scope of NHIN Exchange, NHIN Direct, our WG, another WG?

Feedback on Addressing NHIN Exchange to NHIN Direct Transactions

Name
Feedback/Comment
George Cole
pass
Didi Davis
  • Topic should be addressed by concrete implementations, but input from this group/collaboration is needed
  • Should stay within NHIN Direct
Thanos Tsiolis
  • Agree with Didi’s comment
  • NHIN Direct is responsible for determining how to mesh with NHIN exchange
  • This WG should support concrete implementations in determining these interactions
Noam Arzt
NHIN Direct should deal with this topic, but NHIN exchange should also be involved
Eric Heflin
There is overlap between this and the concrete implementation WG. We should assign ownership to one group and it should be this WG
Mark Stine
Seems logical that this group should look at this interaction. Should encourage NHIN exchange/NHIN Direct collaboration on this issue.
Wenzhi Li
pass
Will Ross
pass
Gary Christensen
Agree with Karen
Chaminda Gunaratne
pass
Thomas Davidson
pass
Tony Mallia
Discussion of this interaction belongs to group

Comment from Arien Malec

  • This type of interaction is consistent with the original mission and charter of this group: Providing requirements and an overall vision for how NHIN Direct interoperates with comprehensive HIE
    • The “how” for exactly how this happens belongs with the concrete implementations
    • This WG should provide the “what”

Comment from Vassil Peytchev

  • Suggest that this topic be addressed in the details of the scenarios
  • Vassil will specifically ask for items re this topic to be included in the details area

Comment from Karen Witting

  • Fine with this approach
  • Should make sure to address different types of translation