Robust HIE Meeting 2010-04-13
Jump to navigation
Jump to search
Notes from Robust HIE Interoperability Workgroup
Status of Notes: DRAFT
Date: April 13, 2010
Time: 2pm-3pm
Attendees: Honora Burnett, Arien Malec, Jackie Key, Vassil Peytchev, George Cole, Tom Silvinos, Tony Malia, Will Ross, Matthew Weaver, Ron Hess, Rodney Cain, Karen Witting, Parag More, Mark Stine, Dan Russler, Chris Monaco, Anand Shroff, Keith Boone & Didi Davis
Actions
· Address the tradeoffs – what do you get/what do you give up
· Limiting options, simpler choices have specific applications and more complex things can be more of everything to everyone
· What do you get if you only do the simple?
o Use Cases/User Stories are adjunct
o Specifications have to be adjunct in overall framing
o What do you get it you only do step one, or step two and how do those two things work at scale?
Comment from Didi Davis
· Clarifying for the general public – providers that weigh in from general public, describe NHIN Direct within the Push/Pull which has made it simple to address as a stakeholder when doing outreach because they understand document exchange concept, but physicians practice in a push model
· Defining these in the way of a User Story
Comment from Karen Witting
· Concern: tendency to characterize as push/pull
· Push in NHIN Robust is Endpoint to Endpoint
Comment from Parag More
· Assumption is that every concrete implementation that is proposed should address all the must and should user stories and each concrete implementation should be tested against the user stories
Comment from Anand Schroff
· IHE vs. REST
· Either or, or determining the order of priority
· Commentary around framing:
o WGs have commented that if we choose to do it one way (just SMTP) then there is more simplicity surrounding this
o If we decide an IHE mapping is appropriate/doable and meets the goals of implementation simplicity
o No bias that there is an either/or
· If this group is going to work on the IHE implementation, what groups are working on the SMTP and REST
· Spin up concrete implementation group, where this group will be a key feeder group to look at all concrete implementations
· This group will inform IHE specifications
· There is a direct workflow push model that is being discussed here as part of NHIN Direct
· Started with a Use Case that a patient who has maybe been seen somewhere else but can’t remember
· Description that in a pull use case, we already have NHIN specifications to do pull using discovery, discovery access capabilities
· Is it simplistic for the endpoints or for the whole process?
· A lot of the technology stack is there because the policy and workflow implications (I’m requesting the information holder and the holder needs to determine whether they want to release)
o One additional area of simplicity – policy simplicity when the information holder has already decided to transport information and the
Comment from George Cole
o Define usage similiaries/differences between Direct and Discovery
o Machine vs. Person – real usage difference
o Might find mappings to the user stories different
Comment from Tony Malia
o User Stories – first four of them tend to deal with Robust
o Retrieve mechanism – push/pull mechanism
o Unique user stories that don’t appear in NHIN Robust
o Individual communication at the endpoint
o Assume NHIOs and HSPs we could map out a composite to Abstract Model and we could see which communications in the model to use Robust and Direct – big distinction is in individual notification/access
o Include both Robust/Direct
Comment from Wil Ross
o Concerned that we’re being unnecessarily theoretical
o Stay grounded in discussion roadmap that leads us to the hard question at hand: is there a simple, last mile transport specification that we can accomplish here
Comment from Ron Hess
o Like idea of getting through theoretical to implementation we can build and test
o Let’s assume purity – that there is only one way of doing it
o All based on existing IHE transactions or simple modifications of these and how that would work
o Completely different (REST or SOAP) would that cause conflict …. Naturally fit?
o Explore as alternatives
Comment from Karen Witting
o Like simplicity – what is the stack/piece that disappears when you don’t have policy?
Comment from Parag More
o Ability to accept unsolicited document
o Receive the document in a pulling fashion ... take the document and not query something for fetching/polling
o Differences: valid point, unsolicited piece of information that comes to the destination
o Key difference is routing to the specified endpoint, and unsolicited is a key difference (also, and XDR transaction
Comment from Dan Russler
o Where do we want complexity
o What is the minimum configuration
Comment from Keith Boone
o What is the perceived complexity we need to do away with?
Status of Notes: DRAFT
Date: April 13, 2010
Time: 2pm-3pm
Attendees: Honora Burnett, Arien Malec, Jackie Key, Vassil Peytchev, George Cole, Tom Silvinos, Tony Malia, Will Ross, Matthew Weaver, Ron Hess, Rodney Cain, Karen Witting, Parag More, Mark Stine, Dan Russler, Chris Monaco, Anand Shroff, Keith Boone & Didi Davis
Actions
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 12 |
4/13/10 |
Arien and Vassil will frame up topics for next discussion |
Open |
Arien & Vassil |
4/20/10 |
| 13 |
4/13/10 |
Explore the assumption that NHIN Direct uses current NHIN specifications, using the current IHE Implementation proposal as a starting point (http://nhindirect.org/IHE+Implementation) |
Open |
All |
4/20/10 |
| 14 |
4/13/10 |
Explore the assumption that NHIN Direct uses either the REST or SMTP implementation proposals. How would that fit with or conflict with the current NHIN? |
Open |
All |
4/20/10 |
Review of Action Items from Last Week
· Arien will frame up topics for next discussion
· 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?
· Take to User Story Workgroup: Confirm that the Status Update User Story is a “must have”
· Take to Security and Trust Workgroup: does there have to be a separation between HSP and the destination?
· 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?
Issue Framing
Vassil listed the framing discussions here:
[1]
Discussion
Comment from Will Ross, Redwood MN
- Likes the framing as proposed
- Believes in simplicity as an outcome
Comment from George from Allscripts
- Likes the framing
- Still confused about interplay between
Comment from Tony from VA
- Started doing the position exercise
- Came up with three positioning
- Adjunct (push and pull) -- adjunct works well in one direct, but not the other
- Subset and simplification
- Alternative (perhaps better to simplify standard), typical cycle of standards development to move to simplicity
Comment from Tom
- Add to framing addressing the tradeoffs between simple and robust
Comment from Didi
- Agree to framing
- Carespark weighted in on the user stories, helped to describe the tradeoff as push vs. pull
- User stories are adjunct and user stories are perceived as adding physician value and makes sense to providers
- Arien noted that NHIN already has a push model
Comment from Matthew Weaver
- Likes the framing questions
Comment from Ron Hess
- Comfortable with the framing
Comment from Rodney Cain
- Needs to see how the services interplay
Comment from Karen Witting
- Framing questions seem appropriate
- Concerned about push vs. pull, mischaracterizes what is intended and NHIN currently has push
- NHIN didn't do routed to endpoint because weren't allowed
· Address the tradeoffs – what do you get/what do you give up
· Limiting options, simpler choices have specific applications and more complex things can be more of everything to everyone
· What do you get if you only do the simple?
o Use Cases/User Stories are adjunct
o Specifications have to be adjunct in overall framing
o What do you get it you only do step one, or step two and how do those two things work at scale?
Comment from Didi Davis
· Clarifying for the general public – providers that weigh in from general public, describe NHIN Direct within the Push/Pull which has made it simple to address as a stakeholder when doing outreach because they understand document exchange concept, but physicians practice in a push model
· Defining these in the way of a User Story
Comment from Karen Witting
· Concern: tendency to characterize as push/pull
· Push in NHIN Robust is Endpoint to Endpoint
Comment from Parag More
· Assumption is that every concrete implementation that is proposed should address all the must and should user stories and each concrete implementation should be tested against the user stories
Comment from Anand Schroff
· IHE vs. REST
· Either or, or determining the order of priority
· Commentary around framing:
o WGs have commented that if we choose to do it one way (just SMTP) then there is more simplicity surrounding this
o If we decide an IHE mapping is appropriate/doable and meets the goals of implementation simplicity
o No bias that there is an either/or
· If this group is going to work on the IHE implementation, what groups are working on the SMTP and REST
· Spin up concrete implementation group, where this group will be a key feeder group to look at all concrete implementations
· This group will inform IHE specifications
· There is a direct workflow push model that is being discussed here as part of NHIN Direct
· Started with a Use Case that a patient who has maybe been seen somewhere else but can’t remember
· Description that in a pull use case, we already have NHIN specifications to do pull using discovery, discovery access capabilities
· Is it simplistic for the endpoints or for the whole process?
· A lot of the technology stack is there because the policy and workflow implications (I’m requesting the information holder and the holder needs to determine whether they want to release)
o One additional area of simplicity – policy simplicity when the information holder has already decided to transport information and the
Comment from George Cole
o Define usage similiaries/differences between Direct and Discovery
o Machine vs. Person – real usage difference
o Might find mappings to the user stories different
Comment from Tony Malia
o User Stories – first four of them tend to deal with Robust
o Retrieve mechanism – push/pull mechanism
o Unique user stories that don’t appear in NHIN Robust
o Individual communication at the endpoint
o Assume NHIOs and HSPs we could map out a composite to Abstract Model and we could see which communications in the model to use Robust and Direct – big distinction is in individual notification/access
o Include both Robust/Direct
Comment from Wil Ross
o Concerned that we’re being unnecessarily theoretical
o Stay grounded in discussion roadmap that leads us to the hard question at hand: is there a simple, last mile transport specification that we can accomplish here
Comment from Ron Hess
o Like idea of getting through theoretical to implementation we can build and test
o Let’s assume purity – that there is only one way of doing it
o All based on existing IHE transactions or simple modifications of these and how that would work
o Completely different (REST or SOAP) would that cause conflict …. Naturally fit?
o Explore as alternatives
Comment from Karen Witting
o Like simplicity – what is the stack/piece that disappears when you don’t have policy?
Comment from Parag More
o Ability to accept unsolicited document
o Receive the document in a pulling fashion ... take the document and not query something for fetching/polling
o Differences: valid point, unsolicited piece of information that comes to the destination
o Key difference is routing to the specified endpoint, and unsolicited is a key difference (also, and XDR transaction
Comment from Dan Russler
o Where do we want complexity
o What is the minimum configuration
Comment from Keith Boone
o What is the perceived complexity we need to do away with?