Concrete Implementation Agenda 2010-05-11
Jump to navigation
Jump to search
· Big problem: how do we know when someone has won?
· Do our best to clarify this
Comment from Brian Behlendorf
· Minimum threshold was intended to be a first stab
· Wiki page next to current minimal threshold and WG should contribute
· What does it mean to just have one?
There was broad concern that “one implementation,” while appropriate for the backbone, may be overly-restrictive from an edge perspective. This was not controversial; mostly the discussion seemed to be a clarification of somewhat vague terminology and intent. ACTION: We will require at least one edge implementation from a concrete group, and include in the capabilities list a question about how multiple types of edge systems can connect.
Comment from Arien Malec
· 'Making one of three tradeoffs:
· In order to maximize interoperability we are going to constrain backbone to be XDR
· At least two backbone protocols
a. We can decide we want “Karen’s Cross”
b. Functions that send one way end to end for some organizations, and another way for NHIN notes
· Only one, but actually saying that we want two
· Less concern from the people that stand up HIE’s
· Value of supporting multiple things on the edge
Comment from Sean Nolan
· Two backbone option sounds like edges
· How do we characterize this as work that is actually being done instead of hiding behind gateways
Comment from Steven Waldren
· Perfect is the enemy of good
· A bunch of super nodes that are difficult to get up and running
Comment from Rob Wilmot/David McCallie
· Universal addressability and delivery
· Edge piece is the most important
Comment from David Kibbe
· Goal is to make it dead simple to move the data from their address to another client
Comment from Vassil Peytchev
· Simplicity for the users does not mean that we need technology simplicity
· We should state that we want simplicity for the users
· Right now talking about pilot implementation – not the final approach
· Many people brought up fax
· Should this be better than fax?
Comment from Eric Heflin
· Evaluation criteria is needed as a reference point
· Single protocol for the backbone
Comment from Mark Stine/Chris Moyer
· Strive for single backbone to guarantee interoperability
Comment from Karen Witting
· Backbone: transaction that goes from source HISP to destination HISP
o Will we use one?
o Should we choose the same one as the existing NHIN
o Or should we choose a different one
o Choice between:
§ XDR (consistency with NHIN)
§ Something else that can be translated with XDR (we will have to provide a translation either way)
· Edge: everyone has a different way of sharing the “within”
o We should talk about examples of ways to do the within so that people can start building
o Good idea for us to consider 1, 2 or 3
o Probably should be more than one, and everyone will define their own
· How a particular organization fits in is variable: hospitals might become an HISP and talk on the backbone, or small practices might have a contract with the HISP who will take on the burden’s of the backbone
· Receiver should get something useful and be able to handle
o Pull towards simple rather than up towards complex
o The majority of physician practices consider useful to be anything that can be read
o If we don’t fulfill this
Comment from John Moehrke
· Delivery of the content package and the ability to receive it is important
· Having the ability to convert from one for m to another where we support multiple types of delivery
· Confused by what we mean about backbone
· Trust Framework is a good way to define what a backbone is
Comment from Arien Malec
· How do organizations map from metadata that email gives vs. metadata for XDR transaction
Comment from Lin Wan
· It should be easier to meet the needs of XDR
· Content – MIME type and view
· Should patient demographics be required?
o Question for a content group
o Recommend metadata
There was major concern about the short timeline we were working against. This was particularly severe for the IHE group that had competing obligations over the last couple of weeks. ACTION: we agreed to extend this process by one month --- meaning that we will make a final recommendation the week of June 6, in teleconference and at our next face-to-face meeting. I will suggest at WG call tomorrow that we force a “demo day” during the call on the 25th (turn it into a Live Meeting) as an interim milestone.
· June 6th we need to be very concrete
· One interim milestone to show interim process “forcing function”
· Will have a “demo day” on the 25th which will be a LiveMeeting
· Update the specification documents along with the concrete implementations
Comment from Karen Whiting
· Uncomfortable with planning to make a decision when we haven’t determined what the decision is
· Reassess next week
Comment from Ravi Madduri
· Volunteer his group, would like guidance
o 1) We will be working on these criteria pieces
o 2) If REST is where you want to work, don’t wait! Join the REST group and begin working – go to the Wiki to do this
· Status update from each team, have each team post on the Concrete Implementation WG page and have them post their status – how far they have gotten towards their definition of success criteria, information and also risks
o Brian will arrange that we can track each Concrete Implementation Group’s status reports on the Wiki
o Each Concrete Implementation Group will provide weekly status reports by Tuesday at noon
Notes from the Concrete Implementation Workgroup
Status of Notes: DRAFT
Date: May 11, 2010
Time: 12pm-1pm
Attendees Arien Malec, Honora Burnett, Sean Nolan, Steve Waldren, Rob Wilmot, David McCallie, Rich Kernan, Jackie Key, Ravi Madduri, David Kibbe, Vassil Peytchev, Eric Heflin, Mark Stine, Chris Moyer, Sean Nolan, Umesh Madan, Brett Peterson, John Moehrke, Karen Witting, Brian Behlendorf, Matt Potter & Lin Wan
Actions for this Week:
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 13 |
5/11/10 |
Sean will build a wiki page next to current minimal threshold and WG should contribute |
Open |
Sean & WG |
5/17/10 |
| 14 |
5/11/10 |
Brian will arrange that we can track each Concrete Implementation Group’s status reports on the Wiki |
Open |
Brian |
5/17/10 |
| 15 |
5/11/10 |
Each Concrete Implementation Group will provide weekly status reports by Tuesday at noon |
Open |
Each Concrete Implementation Group |
Ongoing |
| 16 |
5/11/10 |
WG will have a “demo day” on the 25th which will be a LiveMeeting |
Open |
WG |
5/25/10 |
| 17 |
5/11/10 |
WG will update the specification documents along with the concrete implementations |
Open |
WG |
Ongoing |
Actions from last Week:
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 8 |
5/4/10 |
Sean will post a skeleton outline on the Wiki for the NHIN Direct Slides and ask people to contribute |
Closed |
Sean |
5/12/10 |
| 9 |
5/4/10 |
Group will track the notion of multiple addresses – take this to the User Story |
Closed |
Group |
5/12/10 |
| 10 |
5/4/10 |
Vassil will put some feedback on the challenges of SMIME on the Wiki |
Open |
Vassil |
5/12/10 |
| 11 |
5/4/10 |
Brief the S&T WG on security and trust issues related to concrete implementation |
Open |
Arien |
5/12/10 |
| 12 |
5/4/10 |
Dragon will get XMPP code into source code |
Open |
Dragon |
5/12/10 |
Agenda
- Debrief on face-to-face meeting and discuss each point (and others if needed) (bulk of the time)
- Quick status from each of the four groups (no more than 3 mins each)
- Open forum if time left
Notes
Debrief on face-to-face meeting and discuss each point (and others if needed) (bulk of the time)
The “Minimum Threshold” definition is not crisp enough to help people understand what they need to produce. We proposed to re-create this as a list of “capabilities” that must be demonstrated. Some will directly reference other workgroup artifacts like user stories, but not all may be so direct (e.g., “What is the story for integration with NHIN Connect?”). This will result in something that looks a little more like a response to an RFP, but that does not mean we are moving away from working code --- answers that shows an implementation of a capability will carry more weight than those that show a path. We expect that all groups will have some combination of code and mocks/descriptions. ACTION: On the WG call tomorrow morning I will ask for volunteers to build this list of capabilities.
Comment from Cerner
- Iterative process – avoid fine grained criteria
Comment from Arien Malec
- Accept
- Follow along specifications
· Big problem: how do we know when someone has won?
· Do our best to clarify this
Comment from Brian Behlendorf
· Minimum threshold was intended to be a first stab
· Wiki page next to current minimal threshold and WG should contribute
· What does it mean to just have one?
There was broad concern that “one implementation,” while appropriate for the backbone, may be overly-restrictive from an edge perspective. This was not controversial; mostly the discussion seemed to be a clarification of somewhat vague terminology and intent. ACTION: We will require at least one edge implementation from a concrete group, and include in the capabilities list a question about how multiple types of edge systems can connect.
Comment from Arien Malec
· 'Making one of three tradeoffs:
· In order to maximize interoperability we are going to constrain backbone to be XDR
· At least two backbone protocols
a. We can decide we want “Karen’s Cross”
b. Functions that send one way end to end for some organizations, and another way for NHIN notes
· Only one, but actually saying that we want two
· Less concern from the people that stand up HIE’s
· Value of supporting multiple things on the edge
Comment from Sean Nolan
· Two backbone option sounds like edges
· How do we characterize this as work that is actually being done instead of hiding behind gateways
Comment from Steven Waldren
· Perfect is the enemy of good
· A bunch of super nodes that are difficult to get up and running
Comment from Rob Wilmot/David McCallie
· Universal addressability and delivery
· Edge piece is the most important
Comment from David Kibbe
· Goal is to make it dead simple to move the data from their address to another client
Comment from Vassil Peytchev
· Simplicity for the users does not mean that we need technology simplicity
· We should state that we want simplicity for the users
· Right now talking about pilot implementation – not the final approach
· Many people brought up fax
· Should this be better than fax?
Comment from Eric Heflin
· Evaluation criteria is needed as a reference point
· Single protocol for the backbone
Comment from Mark Stine/Chris Moyer
· Strive for single backbone to guarantee interoperability
Comment from Karen Witting
· Backbone: transaction that goes from source HISP to destination HISP
o Will we use one?
o Should we choose the same one as the existing NHIN
o Or should we choose a different one
o Choice between:
§ XDR (consistency with NHIN)
§ Something else that can be translated with XDR (we will have to provide a translation either way)
· Edge: everyone has a different way of sharing the “within”
o We should talk about examples of ways to do the within so that people can start building
o Good idea for us to consider 1, 2 or 3
o Probably should be more than one, and everyone will define their own
· How a particular organization fits in is variable: hospitals might become an HISP and talk on the backbone, or small practices might have a contract with the HISP who will take on the burden’s of the backbone
· Receiver should get something useful and be able to handle
o Pull towards simple rather than up towards complex
o The majority of physician practices consider useful to be anything that can be read
o If we don’t fulfill this
Comment from John Moehrke
· Delivery of the content package and the ability to receive it is important
· Having the ability to convert from one for m to another where we support multiple types of delivery
· Confused by what we mean about backbone
· Trust Framework is a good way to define what a backbone is
Comment from Arien Malec
· How do organizations map from metadata that email gives vs. metadata for XDR transaction
Comment from Lin Wan
· It should be easier to meet the needs of XDR
· Content – MIME type and view
· Should patient demographics be required?
o Question for a content group
o Recommend metadata
There was major concern about the short timeline we were working against. This was particularly severe for the IHE group that had competing obligations over the last couple of weeks. ACTION: we agreed to extend this process by one month --- meaning that we will make a final recommendation the week of June 6, in teleconference and at our next face-to-face meeting. I will suggest at WG call tomorrow that we force a “demo day” during the call on the 25th (turn it into a Live Meeting) as an interim milestone.
· June 6th we need to be very concrete
· One interim milestone to show interim process “forcing function”
· Will have a “demo day” on the 25th which will be a LiveMeeting
· Update the specification documents along with the concrete implementations
Comment from Karen Whiting
· Uncomfortable with planning to make a decision when we haven’t determined what the decision is
· Reassess next week
Comment from Ravi Madduri
· Volunteer his group, would like guidance
o 1) We will be working on these criteria pieces
o 2) If REST is where you want to work, don’t wait! Join the REST group and begin working – go to the Wiki to do this
· Status update from each team, have each team post on the Concrete Implementation WG page and have them post their status – how far they have gotten towards their definition of success criteria, information and also risks
o Brian will arrange that we can track each Concrete Implementation Group’s status reports on the Wiki
o Each Concrete Implementation Group will provide weekly status reports by Tuesday at noon