Robust HIE Meeting 2010-04-01

Notes Robust HIE WG 040110.doc

Notes from the Robust HIE Interoperability Workgroup

Date: April 1, 2010 
  Time: 10am-11am 
  Attendees: Arien Malec, Honora Burnett, Rich Kernan, Wes Rishel, Thomas Davidson, Lin Wan, Chris Voigt, Didi Davis, Matthew Weaver, Tony Mallia, Thanos Tsiolis, Parag More & Vassal Peytchev
 
 

Action Items

#	Date	Action	Status	Owner	Due Date
1	4/1/2010	Revise IHE Implementation page to match revised Abstract Model	Closed	Arien	4/6/2010
2	4/1/2010	Post an example of “intended recipient”	Closed	Arien	4/6/2010
3	4/1/2010	Comment on statement 3.2	Open	Thanos Tsiolis	4/6/2010
4	4/1/2010	Raise metadata related topics to the Content Packaging group, unless we define a key reason why the HSP, rather than the Source/Destination, needs to care about metadata.	Closed	Arien	4/6/2010
5	4/1/2010	Work with NHIN WG and ONC Policy Office to clarify the assumption that the NHIN Direct transactions are presumed to take place after a policy decision to transport data has already been made. If the endpoint does not transport electronically, will transport via fax, mail, courier, etc.	Closed	Arien	4/6/2010
6	4/1/2010	Review Robust HIE page with these questions in mind: Source-Destination HSP transactions HSP-HSP Transactions	Open	Group	4/6/2010

Key Decisions

#	Date	Key Decision	Source
1	4/1/2010	Assumption is that the holder of the data has already made the legal decision to release the data to the intended recipient	All

Notes

Introduction

• Framing
  • We have an IHE mapping to the abstract model that uses XDR in the HSP to HSP role, using intended Recipient to hold the metadata
  • There isn't a clean mapping of the IHE specs to the Destination-HSP connections
  • Edge connectivity
  • Explore whether it is appropriate for node-to-edge model that has a model that doesn’t use IHE web services, or should we alter the IHE to fit the model?
    1. Take the approach to fit the model
    2. Take a pass at web services to assure that they fit the overall architectural model
• Look at this in the middle of node-to-node transaction
  • Appropriate to have XDR in the middle?

• Two deliverables:
  • Make recommendation for going forward – which type of architectural models will be appropriate for an organization that adopts NHIN Direct
  • Definitive statement – how will these services fit together?
• Assume HIE means implementing IHE NHIN specifications there are two key questions:
  • Does the source-HSP connectivity does that need to conform to the same technology stack (IHE Web services) or does it make sense to use a simpler stack
  • Source-HSP and Destination-HSP is SMTP following secure mail conventions, we have NHIN transaction that is based on SDR transaction, is it a bad/neutral thing to follow the same edge semantics in the HSP-HSP world, or is that problematic?

Discussion

• Question/Comment from Tom Davidson: the terminology is not consistent
  • Node-to-edge
  • Node-to-node
  • Terminology of abstract model
  • We should use the abstract model terminology consistently

• Question/Comment from Tom Davidson: What do you mean by SMTP, because it's valid to send

SOAP over SMTP

• • When we say SMTP assume secure email unless otherwise specified
• Question/Comment from Lin Wan: HSP to HSP or Source to HSP
  • Workgroup can recommend source to HSP and destination to HSP
    1. Decide that we can use IHE Specs out of the box or modified
    2. Decide to use new set of IHE Specs
    3. Decide to use something new

• Question/Comment from Chris Voight: Talking about SMTP and IHE as different … NHIN Spec Factory is working on Document Submission that uses XDR Specifications for cross-community messaging
  • Home community ID
  • Intended recipient
  • Could use this for our work
  • Another pilot specification from Spec Factory which describes an administrative distribution built on HITSP
  • Concentrating on transport now, but content can vary in flavors

• Question/Comment from Didi Davis: HITSP has documented components at a high level, but they’ve also uncovered more specific information as well

• Question/Comment from Matt Weaver: shift because ONC hasn’t dictated or even suggested a method of communication between a source and HIE and HIO
  • Goal of NHIN is to incorporate providers seeking to achieve MU
  • This is the next step
  • On IG we have many of the leading EHR vendors
  • We have many of the key edge systems in this process
  • Large vendors are having the largest problems with jumping the hurdles, small vendors are more nimble and flexible

• Question/Comments from Tony Mallia: If we are attempting fast penetration it is desirable not to introduce new stacks that aren’t deployed. There might be a preference for standard email. Some tools are easier to implement than others. Don’t believe we are resolved from exercising HITSP TP20.
  • Founding simplifying assumption with NHIN Direct was that the premise is that the holder of the data has already made a data release decision and is making a choice of modality

• Question/Comments from Wes Rishel: What is a clear cut legislative requirement for an intermediary to be the policy agent connecting organizations?
  • This topic is essentially a policy topic, and not a technology topic
  • Arien will work with NHIN WG and ONC Policy Office to clarify the assumption that the NHIN Direct transactions are presumed to take place after a policy decision to transport data has already been made. If the endpoint does not transport electronically, will transport via fax, mail, courier, etc.
  • Assumption: legal requirements for disclosure have been made
  • Our work begins after any legal/process decisions have been made
  • Dependent on the type of content being distributed

• XML document being distributed would require Metadata
  • Arien will kick this topic to the Content Packaging group, unless we define a key reason why the HSP, rather than the Source/Destination, needs to care about metadata.
  • Our role: what is the key concern and role of the HIO and its enabling technology that requires technology that we’re talking about
  • Content working group needs to include or not include this premise in their work
  • Consider premise of downward compatibility

• Question/Comments from Tom Silvious: If the charter of this group would include addressing the provider/patient relationships – whether there is an HSP in the middle or not – any of these exchanges would need to have access to the relationship between providers conducting exchange and the patient in question. Otherwise, the ideas of S&P and protection of PHI won’t be accomplishable. DISCUSS NEXT MEETING
  • May be a discussion for another workgroup[
  • Key Point: Our assumption is that the holder of the data has already made the legal decision to release the data to the intended recipient

• Question/Comments from Parag More: Let’s ensure that we are integrating all the workgroups.

• Question/Comments from Vassal Peytchev: when will discussion point be posted? This will be a good discussion point.
• Question from Thanos Tsiolis: 3.2 this statement is not accurate, but it can be expounded upon in the comments section

• Addressing workgroup’s actions from Wes are to provide an existence proof’s mapping

Wrap up

• What we did today:
  • Framed the question, gotten everyone level set
  • We’ve gotten good feedback for key policy work, boundary lines
• For the next meeting, we should focus on the two framing questions Arien proposed today:
  1. Source-Destination HSP transactions
  2. HSP-HSP Transactions
  3. Thinking about the applicability of IHE transaction set
• Arien will do a pass at IHE Implementation page to match revised Abstract Model
• Arien will post an example of “intended recipient”
• Epic representative will comment on statement 3.2
• Arien will work with NHIN WG and ONC Policy Office to clarify the assumption that the NHIN Direct transactions are presumed to take place after a policy decision to transport data has already been made. If the endpoint does not transport electronically, will transport via fax, mail, courier, etc.
• Arien will kick this topic to the Content Packaging group, unless we define a key reason why the HSP, rather than the Source/Destination, needs to care about metadata.