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

Comment from David Kibbe·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 oWill we use one? oShould we choose the same one as the existing NHIN oOr should we choose a different one oChoice 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” oWe should talk about examples of ways to do the within so that people can start building oGood idea for us to consider 1, 2 or 3 oProbably 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 oPull towards simple rather than up towards complex oThe majority of physician practices consider useful to be anything that can be read oIf 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? oQuestion for a content group oRecommend 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 o1) We will be working on these criteria pieces o2) 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 oBrian will arrange that we can track each Concrete Implementation Group’s status reports on the Wiki oEach Concrete Implementation Group will provide weekly status reports by Tuesday at noon