Robust HIE Meeting Notes 040610
Jump to navigation
Jump to search
Notes from Robust HIE Interoperability Workgroup
Status of Notes: DRAFT
Date: April 6, 2010
Time: 2pm-3pm
Attendees: Honora Burnett, Arien Malec, Anand Shroff, Chris Voigt, George Cole, John Moehrke, Lin Wan, Matthew Weaver, Pam Waters, Peter DeVault, Thanos Tsiolis, Tom Silvious , Tony Mallia, Vassil Peytchev and Will Ross
Actions
Notes
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Discussion
· Vassil is going to be the lead on this group
· Frame up discussion that has happened on the IHE Implementation page
o Summarization: look at the discussion
o Destination to HSP to IHE transaction set is where we are getting stuck
o Two issues:
§ XDS transactions
· Registry stored query
· Single patient specific – don’t map to “my messages” concept
· Vassil’s suggestion: multi-patient query
· Mapping the status document
o Update metadata
Comment from John Moehrke
· This group is taking a different direction here as to other groups
· Other groups we are talking “mail transport”
· Arien’s Framing Discussion:
o Framing: we’ve already got a specification, and it is the document transaction over NHIN and IHE specifications – why can’t we just use that?
§ No assumption that these transaction sets are and should be applicable
o Framing: one of the goals of abstract model was to create an overall model to map to other implementations
o Other IHE Approaches that may fit this better, and why are they not on the table
§ Two other models:
· XDM can be used over SMPT (end point to end point) utilizing the same addressing we’ve been talking about
· Publishing environment: Nav profile which is a companion to a publish which delivers an email message
· How will NHIN Direct short term solution integrate with NHIN solution?
o Issue: should we be looking at the metadata as the core issue, not the transaction?
§ If the core issue is metadata, then the content packaging wg is heading towards a content package light – multipart MIME, content package rich - XDR
Comment from Lin Wan
· What are we trying to determine here?
· NHIN Project is adding XDR to transactions, and this will address HIE integration with a “push” how is that different from HSP – to – HSP
· If we decide to use mail, we are basically saying we don’t want to use SOAP
· Charter of this group is to provide advice back to full implementation group, “here are how these transactions fit within the larger frame that implement XCA or XDS”
· Premise, we have XDR, and it fits the source for HSP
o John’s proposed an counter view: glue behind transaction isn’t SOAP transactions, but it is the metadata packaging around the message that is the clear value
Comment from Matthew Weaver
· Maps well from Source-HSP and HSP-HSP, given that we’re worried about status from HSP-Provider
Comment from Thanos Tsiolis
· Separating HSP/Destination or Provider
· Breaking HSP from destination, we have a different conversation
· This notion of needing to be able to pull is confusing because which are the HSP’s that need to be pulled in order to get the data
· Situation where the provider that may need the data has many email accounts and to get their emails they have to pull from all of them
Comment from Tony Mallia
· Does this get us to the speed of deployment that we want with this or are we getting to another NHIN?
· Copy the NHIN piece
· Rapid deployment environment
· Use sources that are deployed to get things out quickly
· Could one subscribe to the information?
· Question reuse of standards – does this get us to the speed of deployment that we want with this or are we getting to another NHIN?
Comment from Vassil Peytchev
· Status updates
· Metadata is a major important piece of these transactions
· Requirements that come out of the abstract model
· Talk about point-to-point push, sequence of XDR transactions can be achieved so that the source can receive a note that the transaction was successful
· Tradeoffs we are making already to fit within an abstract model
· Arien:
o Take to User Story Workgroup: Confirm that the Status Update User Story is a must have
§ Need for definitive receipt/acknowledgement status is “nice to have” for referral and “must have” for a lab transaction
§ Could decide that we want to bite off for the first set of things the set of transactions that don’t require definitive status updates
o Take to Security and Trust Workgroup: does there have to be a separation between HSP and the destination?
o Take to Robust HIE: if I am an HIO serving a geographic area and I have HSP’s running NHIN Stack and are peers does that help me or hurt me?
§ True that if you make an assumption that the destination itself is an HSP or provides and HSP
§ Arguments against:
· Topic for Security/Trust Working Group: firewalls prevent security risks
· Concerns that NHIN Direct facilitates peer-to-peer transactions that don’t provide a space for an HIO
o A smart source can route directly to a smart destination and that provides a set of awkward topology fit with the model of HIO that is serving a community
o By having a two provider practice EHR with XDR document destination we are promoting peer-to-peer typology
· Arien is concerned by the amount of “passes”
o Discussion is good discussion
o Or wandering too far into the weeds in a level where some people who are less comfortable with XDR
o Is this the right level of conversation? Group says yes.
Comment from Tony Mallia
o In our focus on the use cases, there are a couple that emerge:
o Deliberate referral or transfer of care where two clinicians are handing off something
o Additional user story around laboratory results User Story
o Clinician getting information
§ Poly-provider
§ Breaks privacy model for NHIN direct -- bounding assumptions:
· Directed transaction from source to recipient
· Legal/regulatory decisions have already been handled in an administrative state (question of modality)
Wrap Up:
o Arien will frame up topics for next discussion
o Next time we will have a formalized discussion around John’s proposal: should we be looking at the metadata as the core issue, not the transaction?
o Take to User Story Workgroup: Confirm that the Status Update User Story is a must have
o Take to Security and Trust Workgroup: does there have to be a separation between HSP and the destination?
o Take to Robust HIE: if I am an HIO serving a geographic area and I have HSP’s running NHIN Stack and are peers does that help me or hurt me?
Status of Notes: DRAFT
Date: April 6, 2010
Time: 2pm-3pm
Attendees: Honora Burnett, Arien Malec, Anand Shroff, Chris Voigt, George Cole, John Moehrke, Lin Wan, Matthew Weaver, Pam Waters, Peter DeVault, Thanos Tsiolis, Tom Silvious , Tony Mallia, Vassil Peytchev and Will Ross
Actions
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 7 |
4/6/10 |
Arien will frame up topics for next discussion |
Open |
Arien |
4/13/10 |
| 8 |
4/6/10 |
Next time we will have a formalized discussion around John’s proposal: should we be looking at the metadata as the core issue, not the transaction? |
Open |
All |
4/13/10 |
| 9 |
4/6/10 |
Take to User Story Workgroup: Confirm that the Status Update User Story is a “must have” |
Open |
Arien |
4/13/10 |
| 10 |
4/6/10 |
Take to Security and Trust Workgroup: does there have to be a separation between HSP and the destination? |
Open |
Arien |
4/13/10 |
| 11 |
4/6/10 |
Take to Robust HIE: if I am an HIO serving a geographic area and I have HSP’s running NHIN Stack and are peers does that help me or hurt me? |
Open |
Arien |
4/13/10 |
Key Decisions
| # |
Date |
Key Decision |
Source |
| 2 |
4/6/10 |
Vassil Peytchev will be lead |
Open |
Notes
Agenda and Framing
· Review of last week’s action items
· Discussion
· Next Steps
Discussion
· Vassil is going to be the lead on this group
· Frame up discussion that has happened on the IHE Implementation page
o Summarization: look at the discussion
o Destination to HSP to IHE transaction set is where we are getting stuck
o Two issues:
§ XDS transactions
· Registry stored query
· Single patient specific – don’t map to “my messages” concept
· Vassil’s suggestion: multi-patient query
· Mapping the status document
o Update metadata
Comment from John Moehrke
· This group is taking a different direction here as to other groups
· Other groups we are talking “mail transport”
· Arien’s Framing Discussion:
o Framing: we’ve already got a specification, and it is the document transaction over NHIN and IHE specifications – why can’t we just use that?
§ No assumption that these transaction sets are and should be applicable
o Framing: one of the goals of abstract model was to create an overall model to map to other implementations
o Other IHE Approaches that may fit this better, and why are they not on the table
§ Two other models:
· XDM can be used over SMPT (end point to end point) utilizing the same addressing we’ve been talking about
· Publishing environment: Nav profile which is a companion to a publish which delivers an email message
· How will NHIN Direct short term solution integrate with NHIN solution?
o Issue: should we be looking at the metadata as the core issue, not the transaction?
§ If the core issue is metadata, then the content packaging wg is heading towards a content package light – multipart MIME, content package rich - XDR
Comment from Lin Wan
· What are we trying to determine here?
· NHIN Project is adding XDR to transactions, and this will address HIE integration with a “push” how is that different from HSP – to – HSP
· If we decide to use mail, we are basically saying we don’t want to use SOAP
· Charter of this group is to provide advice back to full implementation group, “here are how these transactions fit within the larger frame that implement XCA or XDS”
· Premise, we have XDR, and it fits the source for HSP
o John’s proposed an counter view: glue behind transaction isn’t SOAP transactions, but it is the metadata packaging around the message that is the clear value
Comment from Matthew Weaver
· Maps well from Source-HSP and HSP-HSP, given that we’re worried about status from HSP-Provider
Comment from Thanos Tsiolis
· Separating HSP/Destination or Provider
· Breaking HSP from destination, we have a different conversation
· This notion of needing to be able to pull is confusing because which are the HSP’s that need to be pulled in order to get the data
· Situation where the provider that may need the data has many email accounts and to get their emails they have to pull from all of them
Comment from Tony Mallia
· Does this get us to the speed of deployment that we want with this or are we getting to another NHIN?
· Copy the NHIN piece
· Rapid deployment environment
· Use sources that are deployed to get things out quickly
· Could one subscribe to the information?
· Question reuse of standards – does this get us to the speed of deployment that we want with this or are we getting to another NHIN?
Comment from Vassil Peytchev
· Status updates
· Metadata is a major important piece of these transactions
· Requirements that come out of the abstract model
· Talk about point-to-point push, sequence of XDR transactions can be achieved so that the source can receive a note that the transaction was successful
· Tradeoffs we are making already to fit within an abstract model
· Arien:
o Take to User Story Workgroup: Confirm that the Status Update User Story is a must have
§ Need for definitive receipt/acknowledgement status is “nice to have” for referral and “must have” for a lab transaction
§ Could decide that we want to bite off for the first set of things the set of transactions that don’t require definitive status updates
o Take to Security and Trust Workgroup: does there have to be a separation between HSP and the destination?
o Take to Robust HIE: if I am an HIO serving a geographic area and I have HSP’s running NHIN Stack and are peers does that help me or hurt me?
§ True that if you make an assumption that the destination itself is an HSP or provides and HSP
§ Arguments against:
· Topic for Security/Trust Working Group: firewalls prevent security risks
· Concerns that NHIN Direct facilitates peer-to-peer transactions that don’t provide a space for an HIO
o A smart source can route directly to a smart destination and that provides a set of awkward topology fit with the model of HIO that is serving a community
o By having a two provider practice EHR with XDR document destination we are promoting peer-to-peer typology
· Arien is concerned by the amount of “passes”
o Discussion is good discussion
o Or wandering too far into the weeds in a level where some people who are less comfortable with XDR
o Is this the right level of conversation? Group says yes.
Comment from Tony Mallia
o In our focus on the use cases, there are a couple that emerge:
o Deliberate referral or transfer of care where two clinicians are handing off something
o Additional user story around laboratory results User Story
o Clinician getting information
§ Poly-provider
§ Breaks privacy model for NHIN direct -- bounding assumptions:
· Directed transaction from source to recipient
· Legal/regulatory decisions have already been handled in an administrative state (question of modality)
Wrap Up:
o Arien will frame up topics for next discussion
o Next time we will have a formalized discussion around John’s proposal: should we be looking at the metadata as the core issue, not the transaction?
o Take to User Story Workgroup: Confirm that the Status Update User Story is a must have
o Take to Security and Trust Workgroup: does there have to be a separation between HSP and the destination?
o Take to Robust HIE: if I am an HIO serving a geographic area and I have HSP’s running NHIN Stack and are peers does that help me or hurt me?