Concrete Implementation Agenda & Notes from 06152010 Meeting
Jump to navigation
Jump to search
Arien Malec
· Overall, we need to move from competition to consensus
· As we’ve seen what works and what doesn’t work, many solutions have evolved toward each other. However, there have also been islands of consensus.
· Two potential paths forward:
o 1) Wes Rishel suggested that we should let the choice drive the group. Under this proposal, we would split into one group focused on SOAP as the backbone with email at the edge and another group with REST/SMTP on backbone and email on the edge
§ We risk splitting our energy in two, but this approach would allow everyone to stay engaged
o 2) Coalesce on a single option that isn’t everyone’s first choice, but preserves shared values. Two possible options:
§ REST/SMTP on backbone with a focus on XDM and good reference implementation tools to manage XDM
§ Skinny down SOAP and make it easier/more amenable to email at the edge
· Each team was asked to address the issues raised during the consensus process. During today’s call, we could look at that now or we could review the approaches to drive to consensus
Round the room for feedback/reaction to approaches to drive to consensus
Ravi Madduri
· No comment
Didi Davis
· From Carespark’s perspective, we’ll support whatever is chosen, but we need to have a proper understanding of how policies will/won’t change. We need to make sure that Karen’s cross is addressed. Should focus on how policy and technology will come together to facilitate interoperability.
David McCallie
· Many of the threads of conversation over the past few days have offered promising paths to consensus.
· We should address the needs of small providers with simple a combination of backbone and edge, but also have a clear mechanism for stepping-up to a more sophisticated system
o SMTP team has been seeking to address this
· Arien Malec – One of the proposals previously described was to focus on XDM, create the right software tools/programmatic interfaces to create a XDM package, and highly encourage the use of XDM packaging while acknowledging that there will be use cases where providers without EHRs will be exchanging data.
o Initially, we may have been focusing too much on plain email with attachments and overlooked importance of metadata.
· David McCallie –Would be promising if we use something simple like SMTP, then write a sophisticated set of RESTful interfaces at the edge so that the XDM wrapping is transparent to the sender
David Kibbe
· Support Arien/David’s discussion. Think we may already have a new consensus around forking into two pathways.
· One group wants to go back to the concept of a basic, secure, simple, and affordable means of pushing health data for the purpose of allowing more physicians to become Meaningful Users. This group would make fast progress.
· Karen’s cross got us off on a tangent - this is NHIN CONNECT lite
· A liaison between these two groups would be useful, how to do the step-up/carry the XDM package would be useful
Shreyansh Shah
· No comment
Vassil Peytchev
· Some conversations have been happening offline. There seems to be an idea that you can have something that is easy on the edge and for the backbone. Don’t think this is possible, the complexity has to go somewhere and it can’t be on the edge, because small practices need to be able to use the solution.
· A HISP-in-a-box would provide an easy hook-up for an email client or RESTful interface for the end user, but there should be lightweight SOAP messaging between HISPs. This would be the right path forward to gradually work toward more complex NHIN messaging. Also, this wouldn’t be particularly difficult or costly.
Jason Colquitt
· In favor of a SOAP-based approach and agree with Vassil.
Nageshwara Bashyam
· In favor of the HISP-in-a-box idea which can support multiple edges. Would be good to support a single backbone, with a focus on XDM (whether IHE or REST). Would also be beneficial for the team, as we create test harnesses, etc to have a unified approach.
Karen Witting
· Agree with Nageshwara, would prefer to choose one path forward
· In response to the earlier statement that Karen’s cross isn’t a critical piece, if a majority of people feel this way, that’s fine, but I think it’s important. Whatever path we choose, we should talk about how we can get small providers talking to sophisticated, large systems. Would prefer IHE, but will support anything that carries metadata.
Don Jorgenson
· Would support any of the proposals right now. Each has issues in security and privacy that need to be addressed. We should determine what the metadata needs to be in order to move forward.
Matt Koehler /John Theisen
· No comment
Eric Heflin
· Everyone seems to see value in connecting to NHIN Exchange. We share compatible values, though with different priorities. We need to do a reconciliation of our values and identify/brainstorm on these. We’re close to indentifying all of the core values at this point.
· Propose to choose one path going forward.
Mark Stine
· Don’t want us to break into multiple groups, don’t want us to lose our synergy. Two groups would promote too much competition/divergence. Support the HISP-in-a-box idea.
· Agree with Eric that we need to regroup, reconcile our values, and find a common solution that supports the majority of values.
Sean Nolan
· Think it’s valuable to work to one solution. We need to determine whether this is possible. Microsoft is prepared to do this if we can find one solution.
· Encouraged by an emerging solution with SMTP as a base, with a REST API, and an understanding of how XDM could be used for interoperability with NHIN Exchange.
Dan Kazzaz
· Support anything with SMTP at the edge. Anything that reduces cost at the doctor’s office. Need to make sure we understand metadata and provide for an approach that will allow NHIN to interface with other communities, including payors. Fully support Arien’s statement.
Chris Lomonico
· Surescripts is willing to support REST and is also able to support other approaches according to market demands. Need to keep security in the forefront.
Brett Peterson
· To find a way forward, I’m in favor of pushing the metadata question into the content.
· Want to see a backbone such as SMTP, but this begs the question of how to bridge to NHIN Exchange.
· Whose responsibility is it to bridge the protocols? Is it every HISP or just HISPs that also want to serve as NHIN nodes?
· Arien Malec - If you use XDM as a package, the XDR translation is low. The key issue lies in trust, the trust assumptions for NHIN Direct and Exchange are different. Responsibility would most likely lie with a HISP that acts as a NHIN node.
· Brett Peterson – Any organization that wants to take on this responsibility can do so, but the rest of NHIN Direct shouldn’t have to do that
· Arien Malec - We should design in a way that makes the mismatch between Exchange/Direct as small as possible, such as by using XDM
· Brett Peterson – Agree
· Arien Malec – It’s within the rights of a large health system to receive the level of metadata it needs
Brian Hoffman
· No comment
Brian Behlendorf
· As someone who works on CONNECT, I try to be fair to all sides and focus on the process rather than particulars of the protocol.
· When I proposed the strawman at the face-to-face, it might have been a mistake. I like the direction of conversation over the weekend and am highly encouraged
Arien Malec
· We have 13 design principles that could form the basis of our shared values.
o Everything we’ve discussed is there except for the value of metadata, which is only indirectly referred to in one of the principles.
o Suggest adding a metadata principle to these design principles and offering this as our statement of values. If productive, we can debate the ordering of these principles.
Round the room for feedback on last set of discussions
Ravi Madduri
· No comment
Didi Davis
· In full agreement. Feedback we’ve received from Carespark members is that while REST is the future, there is distrust because it’s in the cloud. We need to move along more incrementally.
o Arien Malec – There is no implication that a REST solution needs to do cloud-based storage
o Didi Davis – That’s what they’re thinking, we need to communicate this clearly
David McCallie
· Important question: Assuming there’s a SMTP backbone, is the burden to step up/down on sender/receiver/or someone in between?
David Kibbe
· No comment
Shreyansh Shah
· No comment
Vassil Peytchev
· On the question of responsibility for performing transforms – Making a HISP too simple is a mistake and will prevent providers from expanding their capabilities in the future.
Jason Colquitt
· Support one path rather than two. Need a capability built-in to support complicated metadata for a small provider.
Nageshwara Bashyam
· No comment
Karen Witting
· No comment
Don Jorgenson
· No comment
Matt Koehler /John Theisen
· No comment
Eric Heflin
· Pleased with the direction of conversation, feel that we’re headed toward a path of reconciliation
Mark Stine
· No comment
Sean Nolan
· Looking to Arien for next steps
Dan Kazzaz
· In favor of putting metadata at the client end for when it’s needed. Client pieces would need to be able to support the different types of metadata used.
Chris Lomonico
· No comment
Brett Peterson
· Want to better understand Vassil’s opinion, don’t fully understand his last comment on HISP being simple.
Brian Hoffman
· No comment
Steve Waldren
· Feel that things are not connected and am having trouble understanding where the consensus is.
· Troubled by the use of the term metadata. No problem with using XDM to define use of metadata. Metadata for transport is very minimal – we shouldn’t mix content and transport.
· Don’t think we’re as close as we think we are to consensus, we need to look at our values and the order of these values.
· Arien Malec - Your view is consistent with that of the privacy and security tiger team. The perspective of the P&S team is that it’s best for a HISP to perform only routing without PHI.
o Think we’re talking about having a standard way for source and destination to package content to enable the destination to perform automated workflow processing. Would be valuable to make sure that the content container would allow for automated processing.
o Steve Waldren – To say that you must have metadata for every transaction conflates content/metadata with [missed the end of this sentence]
Arien Malec
· Proposed consensus view on metadata:
o Access to robust metadata allows for automated workflow processing at the destination, which at some destinations is required for business needs.
o It’s reasonable for a destination to expect and ask for certain levels of metadata.
o This level of metadata may not be what a typical small practice is capable of providing, but we should move toward greater levels of metadata because small practices will eventually have systems that are capable of high levels of metadata processing, with the adoption of certified EHR technology.
o Steve Waldren – As a small practice, you could send a message through NHIN Direct that doesn’t have content metadata
o Arien Malec – We should say that supplying this type of content metadata is recommended, not optional
Round the room for feedback on proposed metadata approach
Ravi Madduri
· Agree with approach
Didi Davis
· Agree with approach
David McCallie
· In agreement, but I have a few questions about metadata. What is the shape and method for communicating metadata (XDM) as well as the metadata itself, how many fields are option/required etc?
o Do we always require a XDM package and if we do, what’s in it?
o At the edge, we should build RESTful services that make it easy for the user to use metadata
Shreyansh Shah
· No comment
Vassil Peytchev
· There is confusion between metadata required for transport and metadata required for processing. There is no reason to think that the two are conflated in a way that is prohibitive or problematic.
o This confusion may have come from IHE to/from approach.
· It is incorrect to say that if someone doesn’t use metadata, it shouldn’t be sent to them. If someone doesn’t use it, they should ignore it.
· Arien Malec – I was thinking something different, if you have a sender who can’t create metadata, standards shouldn’t get in their way. Use of metadata is recommended, even for receivers who can’t process it because they may be able to process it later. Should be easy to ignore if you can’t process it.
Jason Colquitt
· Agree
Nageshwara Bashyam
· Agree with Arien, but we need to be careful to define the structure as we go forward
Karen Witting
· Agree with Arien and would like to see this written clearly.
· Arien’s metadata summary rephrased:
o There are two forms of metadata 1) routing and 2) describing content
o These should be carried in different, but consistent, ways and should be easy to translate between protocols.
o Need to define consistent, standard ways to do this
o A source/destination needs to be able to reject message if metadata is needed.
· Arien and Karen to write-up a summary of the metadata consensus view
Matt Koehler /John Theisen
· No comment
Eric Heflin
· No comment
Mark Stine
· Agree
Sean Nolan
· Can get behind a solution that moves toward more metadata
Steve Waldren
· In favor of more automated processing and metadata, but don’t want this level of metadata to be a requirement now.
Dan Kazzaz
· Agree
Chris Lomonico
· Agree
· Metadata is complex
· Arien Malec – This is where developer tools come in
Brett Peterson
· We need a clear definition of what “recommended” means.
· Arien Malec – We use IETF’s definition
· Brett Peterson- Our use of the word has an implication that recommended might move toward requirement
·
Brian Hoffman
· No comment
Arien Malec
· I’ve updated design principles to include two new design principles
· Everyone should review these principles to make sure they are complete
· If there is ordering that people think is useful, they should post their suggested ordering to wiki
· I will write a proposed consensus statement on metadata, in particular content metadata, for the WG to review and drive toward consensus
Notes from the Concrete Implementation Workgroup
Date: June 15, 2010
Time: 12pm-1pm
Attendees: Steven Waldren, Ravi Madduri, Didi Davis, David McCallie, David Kibbe, Shreyansh Shah, Vassil Peytchev, Jason Colquitt, Nageshwara Bashyam, Karen Witting, Don Jorgenson, Matt Koehler, John Theisen, Eric Heflin, Mark Stine, Sean Nolan, Arien Malec, Jackie Key, Brian Behlendorf, Dan Kazzaz, Chris Lomonico, Brett Peterson, Brian Hoffman
Actions for this Week:
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 33 |
6/16/10 |
Write a proposed consensus statement on metadata, in particular content metadata, for the WG to review and drive toward consensus |
Open |
Arien/Karen |
6/22/10 |
| 34 |
6/16/10 |
Review updated design principles for completeness and post any suggested ordering of these principles |
Open |
WG |
6/22/10 |
Actions from last Week:
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 29 |
6/8/10 |
Post presentation materials for each approach to wiki in a widely usable format |
Open |
Concrete Implementation Teams |
6/10/10 |
| 30 |
6/8/10 |
Document the minimal edge specification for each approach |
Open |
Concrete Implementation Teams |
6/10/10 |
| 31 |
6/8/10 |
Continue to discuss use of SAML assertions by ANL REST implementation on wiki |
Open |
Lin Wan/Ravi Madduri |
6/10/10 |
| 32 |
6/8/10 |
Further discuss HISP-HISP authentication during the face-to-face meeting |
Open |
Implementation Group |
6/11/10 |
Agenda
- Discuss potential approaches for concrete implementation path forward
Arien Malec
· Overall, we need to move from competition to consensus
· As we’ve seen what works and what doesn’t work, many solutions have evolved toward each other. However, there have also been islands of consensus.
· Two potential paths forward:
o 1) Wes Rishel suggested that we should let the choice drive the group. Under this proposal, we would split into one group focused on SOAP as the backbone with email at the edge and another group with REST/SMTP on backbone and email on the edge
§ We risk splitting our energy in two, but this approach would allow everyone to stay engaged
o 2) Coalesce on a single option that isn’t everyone’s first choice, but preserves shared values. Two possible options:
§ REST/SMTP on backbone with a focus on XDM and good reference implementation tools to manage XDM
§ Skinny down SOAP and make it easier/more amenable to email at the edge
· Each team was asked to address the issues raised during the consensus process. During today’s call, we could look at that now or we could review the approaches to drive to consensus
Round the room for feedback/reaction to approaches to drive to consensus
Ravi Madduri
· No comment
Didi Davis
· From Carespark’s perspective, we’ll support whatever is chosen, but we need to have a proper understanding of how policies will/won’t change. We need to make sure that Karen’s cross is addressed. Should focus on how policy and technology will come together to facilitate interoperability.
David McCallie
· Many of the threads of conversation over the past few days have offered promising paths to consensus.
· We should address the needs of small providers with simple a combination of backbone and edge, but also have a clear mechanism for stepping-up to a more sophisticated system
o SMTP team has been seeking to address this
· Arien Malec – One of the proposals previously described was to focus on XDM, create the right software tools/programmatic interfaces to create a XDM package, and highly encourage the use of XDM packaging while acknowledging that there will be use cases where providers without EHRs will be exchanging data.
o Initially, we may have been focusing too much on plain email with attachments and overlooked importance of metadata.
· David McCallie –Would be promising if we use something simple like SMTP, then write a sophisticated set of RESTful interfaces at the edge so that the XDM wrapping is transparent to the sender
David Kibbe
· Support Arien/David’s discussion. Think we may already have a new consensus around forking into two pathways.
· One group wants to go back to the concept of a basic, secure, simple, and affordable means of pushing health data for the purpose of allowing more physicians to become Meaningful Users. This group would make fast progress.
· Karen’s cross got us off on a tangent - this is NHIN CONNECT lite
· A liaison between these two groups would be useful, how to do the step-up/carry the XDM package would be useful
Shreyansh Shah
· No comment
Vassil Peytchev
· Some conversations have been happening offline. There seems to be an idea that you can have something that is easy on the edge and for the backbone. Don’t think this is possible, the complexity has to go somewhere and it can’t be on the edge, because small practices need to be able to use the solution.
· A HISP-in-a-box would provide an easy hook-up for an email client or RESTful interface for the end user, but there should be lightweight SOAP messaging between HISPs. This would be the right path forward to gradually work toward more complex NHIN messaging. Also, this wouldn’t be particularly difficult or costly.
Jason Colquitt
· In favor of a SOAP-based approach and agree with Vassil.
Nageshwara Bashyam
· In favor of the HISP-in-a-box idea which can support multiple edges. Would be good to support a single backbone, with a focus on XDM (whether IHE or REST). Would also be beneficial for the team, as we create test harnesses, etc to have a unified approach.
Karen Witting
· Agree with Nageshwara, would prefer to choose one path forward
· In response to the earlier statement that Karen’s cross isn’t a critical piece, if a majority of people feel this way, that’s fine, but I think it’s important. Whatever path we choose, we should talk about how we can get small providers talking to sophisticated, large systems. Would prefer IHE, but will support anything that carries metadata.
Don Jorgenson
· Would support any of the proposals right now. Each has issues in security and privacy that need to be addressed. We should determine what the metadata needs to be in order to move forward.
Matt Koehler /John Theisen
· No comment
Eric Heflin
· Everyone seems to see value in connecting to NHIN Exchange. We share compatible values, though with different priorities. We need to do a reconciliation of our values and identify/brainstorm on these. We’re close to indentifying all of the core values at this point.
· Propose to choose one path going forward.
Mark Stine
· Don’t want us to break into multiple groups, don’t want us to lose our synergy. Two groups would promote too much competition/divergence. Support the HISP-in-a-box idea.
· Agree with Eric that we need to regroup, reconcile our values, and find a common solution that supports the majority of values.
Sean Nolan
· Think it’s valuable to work to one solution. We need to determine whether this is possible. Microsoft is prepared to do this if we can find one solution.
· Encouraged by an emerging solution with SMTP as a base, with a REST API, and an understanding of how XDM could be used for interoperability with NHIN Exchange.
Dan Kazzaz
· Support anything with SMTP at the edge. Anything that reduces cost at the doctor’s office. Need to make sure we understand metadata and provide for an approach that will allow NHIN to interface with other communities, including payors. Fully support Arien’s statement.
Chris Lomonico
· Surescripts is willing to support REST and is also able to support other approaches according to market demands. Need to keep security in the forefront.
Brett Peterson
· To find a way forward, I’m in favor of pushing the metadata question into the content.
· Want to see a backbone such as SMTP, but this begs the question of how to bridge to NHIN Exchange.
· Whose responsibility is it to bridge the protocols? Is it every HISP or just HISPs that also want to serve as NHIN nodes?
· Arien Malec - If you use XDM as a package, the XDR translation is low. The key issue lies in trust, the trust assumptions for NHIN Direct and Exchange are different. Responsibility would most likely lie with a HISP that acts as a NHIN node.
· Brett Peterson – Any organization that wants to take on this responsibility can do so, but the rest of NHIN Direct shouldn’t have to do that
· Arien Malec - We should design in a way that makes the mismatch between Exchange/Direct as small as possible, such as by using XDM
· Brett Peterson – Agree
· Arien Malec – It’s within the rights of a large health system to receive the level of metadata it needs
Brian Hoffman
· No comment
Brian Behlendorf
· As someone who works on CONNECT, I try to be fair to all sides and focus on the process rather than particulars of the protocol.
· When I proposed the strawman at the face-to-face, it might have been a mistake. I like the direction of conversation over the weekend and am highly encouraged
Arien Malec
· We have 13 design principles that could form the basis of our shared values.
o Everything we’ve discussed is there except for the value of metadata, which is only indirectly referred to in one of the principles.
o Suggest adding a metadata principle to these design principles and offering this as our statement of values. If productive, we can debate the ordering of these principles.
Round the room for feedback on last set of discussions
Ravi Madduri
· No comment
Didi Davis
· In full agreement. Feedback we’ve received from Carespark members is that while REST is the future, there is distrust because it’s in the cloud. We need to move along more incrementally.
o Arien Malec – There is no implication that a REST solution needs to do cloud-based storage
o Didi Davis – That’s what they’re thinking, we need to communicate this clearly
David McCallie
· Important question: Assuming there’s a SMTP backbone, is the burden to step up/down on sender/receiver/or someone in between?
David Kibbe
· No comment
Shreyansh Shah
· No comment
Vassil Peytchev
· On the question of responsibility for performing transforms – Making a HISP too simple is a mistake and will prevent providers from expanding their capabilities in the future.
Jason Colquitt
· Support one path rather than two. Need a capability built-in to support complicated metadata for a small provider.
Nageshwara Bashyam
· No comment
Karen Witting
· No comment
Don Jorgenson
· No comment
Matt Koehler /John Theisen
· No comment
Eric Heflin
· Pleased with the direction of conversation, feel that we’re headed toward a path of reconciliation
Mark Stine
· No comment
Sean Nolan
· Looking to Arien for next steps
Dan Kazzaz
· In favor of putting metadata at the client end for when it’s needed. Client pieces would need to be able to support the different types of metadata used.
Chris Lomonico
· No comment
Brett Peterson
· Want to better understand Vassil’s opinion, don’t fully understand his last comment on HISP being simple.
Brian Hoffman
· No comment
Steve Waldren
· Feel that things are not connected and am having trouble understanding where the consensus is.
· Troubled by the use of the term metadata. No problem with using XDM to define use of metadata. Metadata for transport is very minimal – we shouldn’t mix content and transport.
· Don’t think we’re as close as we think we are to consensus, we need to look at our values and the order of these values.
· Arien Malec - Your view is consistent with that of the privacy and security tiger team. The perspective of the P&S team is that it’s best for a HISP to perform only routing without PHI.
o Think we’re talking about having a standard way for source and destination to package content to enable the destination to perform automated workflow processing. Would be valuable to make sure that the content container would allow for automated processing.
o Steve Waldren – To say that you must have metadata for every transaction conflates content/metadata with [missed the end of this sentence]
Arien Malec
· Proposed consensus view on metadata:
o Access to robust metadata allows for automated workflow processing at the destination, which at some destinations is required for business needs.
o It’s reasonable for a destination to expect and ask for certain levels of metadata.
o This level of metadata may not be what a typical small practice is capable of providing, but we should move toward greater levels of metadata because small practices will eventually have systems that are capable of high levels of metadata processing, with the adoption of certified EHR technology.
o Steve Waldren – As a small practice, you could send a message through NHIN Direct that doesn’t have content metadata
o Arien Malec – We should say that supplying this type of content metadata is recommended, not optional
Round the room for feedback on proposed metadata approach
Ravi Madduri
· Agree with approach
Didi Davis
· Agree with approach
David McCallie
· In agreement, but I have a few questions about metadata. What is the shape and method for communicating metadata (XDM) as well as the metadata itself, how many fields are option/required etc?
o Do we always require a XDM package and if we do, what’s in it?
o At the edge, we should build RESTful services that make it easy for the user to use metadata
Shreyansh Shah
· No comment
Vassil Peytchev
· There is confusion between metadata required for transport and metadata required for processing. There is no reason to think that the two are conflated in a way that is prohibitive or problematic.
o This confusion may have come from IHE to/from approach.
· It is incorrect to say that if someone doesn’t use metadata, it shouldn’t be sent to them. If someone doesn’t use it, they should ignore it.
· Arien Malec – I was thinking something different, if you have a sender who can’t create metadata, standards shouldn’t get in their way. Use of metadata is recommended, even for receivers who can’t process it because they may be able to process it later. Should be easy to ignore if you can’t process it.
Jason Colquitt
· Agree
Nageshwara Bashyam
· Agree with Arien, but we need to be careful to define the structure as we go forward
Karen Witting
· Agree with Arien and would like to see this written clearly.
· Arien’s metadata summary rephrased:
o There are two forms of metadata 1) routing and 2) describing content
o These should be carried in different, but consistent, ways and should be easy to translate between protocols.
o Need to define consistent, standard ways to do this
o A source/destination needs to be able to reject message if metadata is needed.
· Arien and Karen to write-up a summary of the metadata consensus view
Matt Koehler /John Theisen
· No comment
Eric Heflin
· No comment
Mark Stine
· Agree
Sean Nolan
· Can get behind a solution that moves toward more metadata
Steve Waldren
· In favor of more automated processing and metadata, but don’t want this level of metadata to be a requirement now.
Dan Kazzaz
· Agree
Chris Lomonico
· Agree
· Metadata is complex
· Arien Malec – This is where developer tools come in
Brett Peterson
· We need a clear definition of what “recommended” means.
· Arien Malec – We use IETF’s definition
· Brett Peterson- Our use of the word has an implication that recommended might move toward requirement
·
Brian Hoffman
· No comment
Arien Malec
· I’ve updated design principles to include two new design principles
· Everyone should review these principles to make sure they are complete
· If there is ordering that people think is useful, they should post their suggested ordering to wiki
· I will write a proposed consensus statement on metadata, in particular content metadata, for the WG to review and drive toward consensus