Concrete Implementation Meeting 2010-04-20
Jump to navigation
Jump to search
Notes
Purpose: Recommend a high level concrete implementation or set of concrete implementations mapping to the abstract model and meeting all Must User Stories
Goal
· Follow the recommendations (or request changes) of the Abstract Model, Addressing and Content Packaging WGs
· Meet the Must recommendations of the User Story WG
· Follow the input of the Robust HIE WG how concrete implementations should work with robust HIE services
· Balance the feedback and needs of:
o Simplicity (argues for only one concrete implementation)
o Supporting existing IHE specs and preserving at least one polling-based Source/Destination implementation
o Consider as input existing REST, SMTP and IHE straw cases
Shouldn’t feel constrained by only having REST, SMTP or IHE as our cases
Suggestion from David Kibbe:
· Add as framing: start with simplest Use Cases from the Must
Suggestion from Brett Peterson
· Will we run this the same way?
· Implementation group consensus
· Kick issues to other working group, so bring up at IG meetings
· Good to give other working groups lots of assignments
Suggestion from Brian Behlendorf
· Based on experience with running code
· Tracking implementation discussion
· Rough consensus working code
· Feasibility to code it up and feed
· Volunteers/thoughts about organization for code contribution
Suggestion from Brian Behlendorf
· Add tool
· Individuals to work on common implementation to have collaboration
· Reiterate on Code as we reiterate on Wiki pages
· Balance neutrality and effectives
Comment from Sean & Umesh
· Document with code is very effective
· .net implementation -- what is the common code, and what is attached to our products
Comment from Mark Stine
· Working code or technology?
o Spike Solution: XP/Tracer Bullet: Commercially friendly, open source license. Understandability that there is credibility to the claims we are making.
o Reference Implementation: open source, working reference implementation to be used and adapted by various parties used as scaffolding or incorporated. Commercially friendly, open source license.
o Priority Implementation
Comment from Vassil
· Great idea
· Is doing his own project based on this, and happy to share
Comment from David Kibbe
· Is there anyone missing that is essential to contributing consensus or working code that isn’t in there room yet
o Kaiser needs to be here
o Round on arms we want to twist
§ Should be part of this team that haven’t stepped up to Volunteer
§ David Kibbe will reach out to get a representative from AASP
§ Eric Heflin: SSA (Arien will reach out to SSA)
· Robust HIE WG will be exploring HIE concrete implementation
· REST/SMPT Based Implementation as a model for what this might look like
· Discussion of one vs. many – forcing functions towards one vs. forcing functions towards many
Comment from Sean Nolan & Umesh
· One over many
Comment from Vassil
· One: many end-to-end
· Different acknowledging for the different transactions (mapping abstract model to 1.x to use one, 2.x may use two)
· Variability on the edge than on the center
David Kibbe
· Agree with Sean & Vassil
· Keep this simple – build on simplicity faster!
Comment from Rob Wilmot & Eric Heflin & Troy Disinger
· Simple
Comment from Brett Peterson
· One end-to-end with the understanding that in the future the source-edge protocol become the source for variability – don’t want multiple backbone specifications
· Single spike end to end, but exchanges, HISPs can have novel ways for plugging the edge in
· Vassil will get a statement from the Robust HIE WG– what is critical for an implementation to do to ensure the care about with current NHIN or IHE based transaction
· Think about WG lead
· Technical and Implementation Details are important here!
· Nominate Brian or Sean as WG leads
· Homework assignment:
o Robust HIE
o WG to read the three concrete implementations on the table
o Catch up on Addressing Specification
o Catch up on Content
o Catch up on Abstract Model
Notes from the Concrete Implementation Workgroup
Status of Notes: DRAFT
Date: April 20, 2010
Time: 12pm-1pm
Attendees: Arien Malec, Honora Burnett, Sean Nolan, Umesh Madan, Mark Stine, Vassil Peytchev, David Kibbe, Rob Wilmot, Brett Peterson, Eric Heflin, Brian Behlendorf, Graham Evans, &Tory Disinger
Actions
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 1 |
4/20/10 |
David Kibbe will reach out to get a representative from AASP |
Open |
David Kibbe |
4/27/10 |
| 2 |
4/20/10 |
Arien will reach out to SSA |
Open |
Arien |
4/27/10 |
| 3 |
4/20/10 |
Vassil will get a statement from the Robust HIE WG– what is critical for an implementation to do to ensure the care about with current NHIN or IHE based transaction |
Open |
Vassil |
4/27/10 |
| 4 |
4/20/10 |
Homework assignment: · WG to read the three concrete implementations · Catch up on Addressing Specification · Catch up on Content Packaging Specification · Catch up on Abstract Model |
Open |
Entire Group |
4/27/10 |
Decision Points
| # |
Date |
Action |
| 1 |
4/20/10 |
Sean Nolan and Brian Behlendorf will be WG leads |
Notes
Purpose: Recommend a high level concrete implementation or set of concrete implementations mapping to the abstract model and meeting all Must User Stories
Goal
· Follow the recommendations (or request changes) of the Abstract Model, Addressing and Content Packaging WGs
· Meet the Must recommendations of the User Story WG
· Follow the input of the Robust HIE WG how concrete implementations should work with robust HIE services
· Balance the feedback and needs of:
o Simplicity (argues for only one concrete implementation)
o Supporting existing IHE specs and preserving at least one polling-based Source/Destination implementation
o Consider as input existing REST, SMTP and IHE straw cases
Shouldn’t feel constrained by only having REST, SMTP or IHE as our cases
Suggestion from David Kibbe:
· Add as framing: start with simplest Use Cases from the Must
Suggestion from Brett Peterson
· Will we run this the same way?
· Implementation group consensus
· Kick issues to other working group, so bring up at IG meetings
· Good to give other working groups lots of assignments
Suggestion from Brian Behlendorf
· Based on experience with running code
· Tracking implementation discussion
· Rough consensus working code
· Feasibility to code it up and feed
· Volunteers/thoughts about organization for code contribution
Suggestion from Brian Behlendorf
· Add tool
· Individuals to work on common implementation to have collaboration
· Reiterate on Code as we reiterate on Wiki pages
· Balance neutrality and effectives
Comment from Sean & Umesh
· Document with code is very effective
· .net implementation -- what is the common code, and what is attached to our products
Comment from Mark Stine
· Working code or technology?
o Spike Solution: XP/Tracer Bullet: Commercially friendly, open source license. Understandability that there is credibility to the claims we are making.
o Reference Implementation: open source, working reference implementation to be used and adapted by various parties used as scaffolding or incorporated. Commercially friendly, open source license.
o Priority Implementation
Comment from Vassil
· Great idea
· Is doing his own project based on this, and happy to share
Comment from David Kibbe
· Is there anyone missing that is essential to contributing consensus or working code that isn’t in there room yet
o Kaiser needs to be here
o Round on arms we want to twist
§ Should be part of this team that haven’t stepped up to Volunteer
§ David Kibbe will reach out to get a representative from AASP
§ Eric Heflin: SSA (Arien will reach out to SSA)
· Robust HIE WG will be exploring HIE concrete implementation
· REST/SMPT Based Implementation as a model for what this might look like
· Discussion of one vs. many – forcing functions towards one vs. forcing functions towards many
Comment from Sean Nolan & Umesh
· One over many
Comment from Vassil
· One: many end-to-end
· Different acknowledging for the different transactions (mapping abstract model to 1.x to use one, 2.x may use two)
· Variability on the edge than on the center
David Kibbe
· Agree with Sean & Vassil
· Keep this simple – build on simplicity faster!
Comment from Rob Wilmot & Eric Heflin & Troy Disinger
· Simple
Comment from Brett Peterson
· One end-to-end with the understanding that in the future the source-edge protocol become the source for variability – don’t want multiple backbone specifications
· Single spike end to end, but exchanges, HISPs can have novel ways for plugging the edge in
· Vassil will get a statement from the Robust HIE WG– what is critical for an implementation to do to ensure the care about with current NHIN or IHE based transaction
· Think about WG lead
· Technical and Implementation Details are important here!
· Nominate Brian or Sean as WG leads
· Homework assignment:
o Robust HIE
o WG to read the three concrete implementations on the table
o Catch up on Addressing Specification
o Catch up on Content
o Catch up on Abstract Model