Robust HIE Meeting 2010-04-20
Jump to navigation
Jump to search
Comment from George Cole
· Meta data should be maintained
Comment from Lin Wan
· Metadata is important … but how much are we trying to pack in
· Looking for a balance
· Minimum Metadata to maintain compatibility
· Robust security model is part of Robust HIE model
· Responsibility for creation of Metadata – Keith Boone has been doing work on the Wiki for this
· Tee this up for content packaging WG – Creation of Metadata
Comment from John Moehrke
· How do we derive the full metadata?
· Problems – maybe a HIE has chosen to use certain codes for certain things
· Allow for informality
· Allow for everything that can be dealt with out of band can be expressed so that when they are dealt with out of band
· What is the relationship between the Direct Project
· Frame this for a topic for a later go around: what will the relationship between someone actively using the Direct Project and reliable Nationwide Health Information Network?
Comment from Karen Witting
· Source, HISP, Destination HISP
· How different is an HISP from a “Gateway”
· What would this look like in the Nationwide Health Information Network?
· Building relationship for the part we have defined in the Nationwide Health Information Network
· Related to Goal Three: If there is a requirement for the Interaction between Destination and Destination HISP to enable polling, then we add complexity.
· Useful to map actors – later conversation
Comment from Gary Christensen
· Statewide HIE
· Thinking about architecture and moving forward
· Distinction between using the Direct Project and Reliable NwHIN is an important factor
Comment from Tony Mallia
· What should we be worrying about
· Trust Model
· Metadata
· Dynamic Interoperability
· Network Topology – what connects to what else? Collapsing of the concepts
· Concept of a bridge or gateway – between a robust NwHIN environment or the Direct Project (node or HISP)
· Interoperability of Security: Trusted user model/trusted user organization (like DURSA – organizational trust models in parallel to DURSA or DURSA) good point to bring to Security & Trust WG
· Dependency for Security and Trust Workgroup
· Known subset, may be fine
· Dynamic Interoperability in both push and pull models
Comment from Rich Kernan
· Fundamental guiding or architectural principals associated with the Direct Project
· LPE could give these fundamental or guiding principles (one pager) – where do they align/conflict with LPE – this could be a thought jogger for the Direct Project and then send to Arien and then will send onto the group
· Example: no one in NwHIN loved SAML, so they didn’t use it
· Formalize these with cross reference to equivalent tools for NwHIN Robust
Comment from Arien Malec
· Those concerned with Direct Project and the current NwHIN the two things he hears the most relate to the trust:
· Trust Model: Large organization and don’t want to get sued/held up to congress
· Content: Don’t want to take a step backward on content and interoperability
· "Don’t hear a concern about the protocols/transactions but I've been talking mainly to people on the business side"
· Summary Action Items:
· Volunteer action from Rich to compare guiding principles of NwHIN with design principles of the DirectProject
· Express dependency to S&T workgroup – Vassil will post to their page and make a comment and request that it becomes part of their discussion
· Responsibility of Metadata
· Can’t get distinguishing boundary between this WG and the Packaging WG
· Review existing Direct Project Metadata
· Define the necessary requirements from the review of Robust HIE Interoperability (ALL)
· Where do the User Stories cross (user behavior, or physician behavior)
· Functional compatibility
· In the beginning of the encounter, I’d like to find out where this patient has been and where they are going. At the end of the call, the clinical might want to publish this.
· Movement for the referral is not the same as the accessibility of the health record
· Essential difference between referring to a provider who has access to NwHIN capabilities and those who don’t
· High level workflow push component should be worked on to show how that also works in the Robust NwHIN and a Direct Project way and also in a Hybrid way (Tony & John volunteering)
Notes from Robust HIE Workgroup Meeting
Status of Notes: DRAFT
Date: April 20, 2010
Time: 2pm-3pm
Attendees: Arien Malec, Honora Burnett, George Cole, Lin Wan, Didi Davis, Ron Hess, Thanos Tsiolis, Vassil Peytchev, John Moehrke, Karen Witting, Parag More, Mark Stine, Will Ross, Gary Christensen, Larry Welcon, Tony Mallia & Rich Kernan
Actions for this Week
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 15 |
4/20/10 |
Provide the Nationwide Health Information Network Exchange design principles for comparison with design principals of the Direct Project (Rich) |
Open |
Rich |
4/27/10 |
| 16 |
4/20/10 |
Express dependency to S&T workgroup -- post to their page and make a comment and request that it becomes part of their discussion (Vassil) |
Open |
Vassil |
4/27/10 |
Review of action items from last week:
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 12 |
4/13/10 |
Arien and Vassil will frame up topics for next discussion |
Closed |
Arien & Vassil |
4/20/10 |
| 13 |
4/13/10 |
Explore the assumption that the Direct Project uses current Nationwide Health Information Network specifications, using the current IHE Implementation proposal as a starting point (http://wiki.directproject.org/IHE+Implementation) |
Closed |
All |
4/20/10 |
| 14 |
4/13/10 |
Explore the assumption that the Direct Project uses either the REST or SMTP implementation proposals. How would that fit with or conflict with the current Nationwide Health Information Network? |
Closed |
All |
4/20/10 |
Agenda:
- Discussion based on Issue Framing
- Review of actions from previous meeting
- Represent the abstract model using Nationwide Health Information Network/IHE transactions:
- Consider the simplest conceptual implementation (not necessarily simplest as in easiest to implement):
- If there is a requirement for the Interaction between Destination and Destination HISP to enable polling, then we add complexity.
- Review of actions and decisions
Issue Framing
- What is critical to maintain compatibility between the Direct Project and the Nationwide Health Information Network protocols? Based on the discussion from last time on Goal 1, what is essential for Robust HIE Interoperability:
- Availability of metadata?
- Protocol stack?
- Other?
Comment from George Cole
· Meta data should be maintained
Comment from Lin Wan
· Metadata is important … but how much are we trying to pack in
· Looking for a balance
· Minimum Metadata to maintain compatibility
· Robust security model is part of Robust HIE model
· Responsibility for creation of Metadata – Keith Boone has been doing work on the Wiki for this
· Tee this up for content packaging WG – Creation of Metadata
Comment from John Moehrke
· How do we derive the full metadata?
· Problems – maybe a HIE has chosen to use certain codes for certain things
· Allow for informality
· Allow for everything that can be dealt with out of band can be expressed so that when they are dealt with out of band
· What is the relationship between the Direct Project
· Frame this for a topic for a later go around: what will the relationship between someone actively using the Direct Project and reliable Nationwide Health Information Network?
Comment from Karen Witting
· Source, HISP, Destination HISP
· How different is an HISP from a “Gateway”
· What would this look like in the Nationwide Health Information Network?
· Building relationship for the part we have defined in the Nationwide Health Information Network
· Related to Goal Three: If there is a requirement for the Interaction between Destination and Destination HISP to enable polling, then we add complexity.
· Useful to map actors – later conversation
Comment from Gary Christensen
· Statewide HIE
· Thinking about architecture and moving forward
· Distinction between using the Direct Project and Reliable NwHIN is an important factor
Comment from Tony Mallia
· What should we be worrying about
· Trust Model
· Metadata
· Dynamic Interoperability
· Network Topology – what connects to what else? Collapsing of the concepts
· Concept of a bridge or gateway – between a robust NwHIN environment or the Direct Project (node or HISP)
· Interoperability of Security: Trusted user model/trusted user organization (like DURSA – organizational trust models in parallel to DURSA or DURSA) good point to bring to Security & Trust WG
· Dependency for Security and Trust Workgroup
· Known subset, may be fine
· Dynamic Interoperability in both push and pull models
Comment from Rich Kernan
· Fundamental guiding or architectural principals associated with the Direct Project
· LPE could give these fundamental or guiding principles (one pager) – where do they align/conflict with LPE – this could be a thought jogger for the Direct Project and then send to Arien and then will send onto the group
· Example: no one in NwHIN loved SAML, so they didn’t use it
· Formalize these with cross reference to equivalent tools for NwHIN Robust
Comment from Arien Malec
· Those concerned with Direct Project and the current NwHIN the two things he hears the most relate to the trust:
· Trust Model: Large organization and don’t want to get sued/held up to congress
· Content: Don’t want to take a step backward on content and interoperability
· "Don’t hear a concern about the protocols/transactions but I've been talking mainly to people on the business side"
· Summary Action Items:
· Volunteer action from Rich to compare guiding principles of NwHIN with design principles of the DirectProject
· Express dependency to S&T workgroup – Vassil will post to their page and make a comment and request that it becomes part of their discussion
· Responsibility of Metadata
· Can’t get distinguishing boundary between this WG and the Packaging WG
· Review existing Direct Project Metadata
· Define the necessary requirements from the review of Robust HIE Interoperability (ALL)
· Where do the User Stories cross (user behavior, or physician behavior)
· Functional compatibility
· In the beginning of the encounter, I’d like to find out where this patient has been and where they are going. At the end of the call, the clinical might want to publish this.
· Movement for the referral is not the same as the accessibility of the health record
· Essential difference between referring to a provider who has access to NwHIN capabilities and those who don’t
· High level workflow push component should be worked on to show how that also works in the Robust NwHIN and a Direct Project way and also in a Hybrid way (Tony & John volunteering)