Concrete Implementation Agenda & Notes from 06182010 Meeting
Jump to navigation
Jump to search
Agenda
· Discuss potential approaches for concrete implementation path forward
Notes
Arien Malec
· Pleased to see a lot of collaboration over last week.
· We have a choice of getting together under a consensus proposal.
o Number of people, Epic and GE team included, going towards the SMTP Team
o Number of people, including Rich Elmore and David McCallie, going towards the SOAP Team.
· Hoping we can meet in the middle
· Come to realize over last week that the realistic choice is between Wes Rischel’s approach versus a consensus oriented path.
· The choice that we have as a group is a choice of moving together or accepting parallel pilots. I know that there are organizations that are willing to drive early implementation around a REST proposal, SMTP proposal, and a SOAP proposal.
o This would be good for innovation.
o This would be bad for getting to the clinical outcomes, care management outcomes and efficiency outcomes we want.
o It would be bad for vendors with limited development staff such as State HIEs.
§ Everyone has to solve these problems and they will have to solve it a different way knowing they may have to switch over time.
o In the long term, it would be bad for getting to the goal of universal addressing and routing for every provider and every patient in the country.
o Without consensus, islands will eventually need to be cross-mapped or “drained.”
· Would like to invite representatives of the teams that have been working together to share where they are and what remaining items we have. Would like Vassil and Janet to give us their sense of the SOAP Team first.
Vassil Peytchev
· At last minute, added comments on convergence proposal on the wiki.
· Approach to innovation is for universal addressing and routing so that there is one NHIN.
· Should look at the consequences of choosing an underlying protocol for NHIN Direct.
· Current convergence proposal provides for XDR gateway, SOAP gateway, etc. and that is the key feature that will bring us together.
· Looked at the bigger picture of how NHIN Exchange and NHIN Direct can work together. Diagram on wiki shows participants from NHIN Direct’s perspective where things move by SMTP. Also shows NHIN Exchange’s perspective where things move through NHIN Exchange protocols – direct push and others.
· HISP capabilities are key. The current proposal has an XDR gateway which sends and receives XDR/SOAP messages. The bridging capabilities for HISP provides for technical bridging for two views, depending on where you sit. That bridging capability is what we tried to look at. As we discussed this in more detail, we tried to figure out how bridging occurs between different participants.
· Further down the list, you can see a link for a variation of an earlier email based on John Moehrke’s suggestion and tries to pinpoint convergence points, with different capabilities for the source and matches to different entry points.
· It doesn’t include the REST entry point.
· Near the bottom, you’ll see SMTP and XDR between the HISP. This does not mean we’re advocating for two backbones.
· Concentrated on describing the capabilities of the HISP. This means we can send between HISPS and sources and destinations. If we start talking about capabilities and make sure that the SMTP capability is always required, then that path forward will allow us to have one NHIN with different protocols.
· It’s possible that users of NHIN Direct will only care about NHIN Direct. It’s also likely that many of these participants will need to use NHIN Exchange services such as record locator services. Having a HISP which has capabilities to support sending and receiving XDR packages achieves that capability for small practice providers. That ability will gradually grow into the capability to consume and provide NHIN Exchange services.
Janet Campbell
· The current convergence proposal is close. We want to make sure that we’re talking about HISP responsibilities and capabilities. We should allow XDR messages between HISPs. We should provide for those paths to eventually connect to NHIN Exchange services.
Arien Malec
· This means that if you send and receive XDR then you must choose the XDR path. If you know that the source and destination are both on the other side of an NHIN exchange node or equivalent, then you must use the native NHIN Exchange protocol.
· We are not saying that we must use the NHIN Direct backbone if you have another way to get there.
· What it comes down to is that an HISP is required to support an SMTP backbone, and if in NHIN Exchange, to be required to document submissions that are XDR backbone.
· I think that’s an approach that leads to more complexity at the HISPs as they need to discover where the endpoints need to talk. I would be more comfortable saying that there is an open NHIN Direct Backbone and one NHIN Exchange backbone and demonstrate the paths that are required to support them. If you happen to know you can get the message another way, then use that way.
Vassil Peytchev
· Need more discussion around details of implementation.
· The goal is not to make the HISP too complex. In the convergence proposal, at the starting point from a HISP, there is an XDR gateway capability. If that is there, then you’re 90% there for connecting between NHIN Exchange and NHIN Direct.
Brian Behlendorf
· The main scenario to avoid is one where a patient or a doctor is sending a message to another and since they’re not on the right network, they can’t get the message through.
Lin Wan
· Is the diagram saying that the backbone is SMTP plus XDR? Why can’t there just be one?
Vassil Peytchev
· This is an exercise for discovering capabilities of the HISP.
· Each diagram at the bottom has a different path. This was to discover capabilities.
Lin Wan
· Why is the connection between the source HISP and destination HISP SMTP/XDR versus XDR?
Arien Malec
· There is one standard backbone that serves the wide variety of NHIN Direct endpoints. But if there are two NHIN Exchange participants talking to each other then there’s every reason for them to use XDR as their backbone.
· Think of it less as how the two edges talk, and more about how the HISPs talk.
· Would like to switch to Rich to discuss the approach for XDR on backbone defined by the source and destination talk. The HISP is required to discover what the destination can talk and send appropriately. Is the choice defined by whether the source HISP and destination HISP can talk (in which case the HISP already has a mechanism for discovering what the destination can talk)?
David McCallie
· The philosophical approach that is driving input here is:
1) Universal addressing : Universal addressing means everyone has to communicate with everyone else regardless of their client and HISP.
· 2) Bootstrapping approach is the best way towards widespread adoption.
o Predicated on belief that by using the lowest common denominator SMTP backbone, we can guarantee all clients to talk to each other. By keeping the payload content neutral, we can scale upwards towards the most sophisticated interaction an XDR protocol would allow.
· On our wiki page NHIN Direct proposal, if you scroll to middle of the page, there’s a multi-colored diagram which is our summary that shows how an expanded HISP could expose to the senders and receivers either simple SMTP or a RESTful replacement for POP and IMAP or an XDM message depending on what’s found on received message.
· Backbone would be SMTP as a carrier or an S/MIME internet message or something quite sophisticated if they can wrap into an XDM message.
· XDM has same data as XDR but can be easily manipulated by systems that do not have full XDR capabilities.
· I think the debate that we need to have is the option of not using the SMTP backbone.
· I think everyone needs SMTP backbone. Optionally, they should be allowed to use an alternative.
Arien Malec
· Agree with what you said and would like to work with you to be stronger on the NHIN Exchange case.
o In the NHIN Exchange case, we recommend/require that the two NHIN exchange nodes use the protocol for NHIN Exchange for getting the message through.
o Two HISPs may communicate with a better mechanism, but they must support the minimum.
David McCallie
· I agree. Nervous about definition of the NHIN Exchange nodes. I understand it’s a legal notion, but does that mean something above and beyond? What about HISPs that want to use some of the NHIN protocols?
Arien Malec
· For the precise case, this means full legal DURSA compliance.
· For non precise cases, if you have a way to communicate, we’re not saying you must use the SMTP backbone, just support it.
David McCallie
· Then I’d agree with that. If within a hospital, a provider wants to send information within an EHR, even if he could use the NHIN direct address, he wouldn’t necessarily need to go out and come back if he can send this through the EHR. I think we’re saying that at the HISP level, if the HISP has a better way of getting the message to the recipient, then use the better way. But the HISP must support SMTP so it can receive a message from anyone.
Arien Malec
· I’d like to now encourage people to ask questions. Let’s do a Round-the-Room.
Round-the-Room
Steven Waldren
· Thrilled with the proposals. On the SOAP based message, going from Source A to the HISP, I’m assuming it’s a SOAP/XDR destination.
Ravi Madduri
· Sounds good. No comment.
Lin Wan
· Fine solution, but if you select XDR to XDR, you have a layer translation where you translate the XDR payload to S/MIME. If you flip it and use a SMTP server to deal with email client and package into XDR package, would that not still work?
Arien Malec
· This brings up the issue of the required level of support for a HISP. What you’re suggesting is appropriate if two HISPs already speak the same protocols. What you’re also saying is reluctance to make every HISP speak two protocols.
Lin Wan
· If we standardize on one, then the HISP is only required to see SMTP or XDR. If you’re a community with full XDR, and you talk XDR, then there’s no conversion. The HISP is only required to support one of the protocols. Is there a huge difference other than addressing?
David McCallie
· The minimum protocol for best chance of bootstrapping capability is SMTP and HISPs are able to use optional protocol if better. They can avoid complexity and speak native protocol if necessary.
Lin Wan
· So really it comes down to addressing.
David McCallie
· Anyone may use a more direct mechanism of connection if the recipient can support it. It should be tested against security constraints, etc. We’re not at the finish line, but feels like a real step.
David Kibbe /Greg?
· We support this proposal.
Vassil Peytchev
· Support. I think there are details to be sorted out.
Wes Rishel
· Support.
Jason Colquitt
· Question: If XDR and SOAP is not an option for the backbone, what if you have a system that speaks XDR and can’t pass to a HISP?
Arien Malec
· We’ll have to better express the wording so that current participants understand this.
o I will take on revision of the text in a way that expresses the points we have discussed and makes it clear that if the two HISPs can speak XDR end to end and know that they can do that and they are enabled and part of NHIN exchange that they are encouraged to do so.
Jason Colquitt
· Then I agree.
Nageshwara Bashyam
· Couple of thing s to understand – when we think about a HISP and we go back to capabilities of a HISP, we need to have a SMTP support and speak XDR.
· Are we going to make them required when doing a systems implementation to be compliant? If so, then I support making this a little more complex. If you have options, it may be more confusing.
Arien Malec
· These are key issues to write down.
Jeff Cunningham
· In favor as long as SMTP is default.
Sean Nolan
· Fully support. This sounds great.
Dan Kazzaz
· I support this.
David Tao
· I support the proposal.
· One friendly amendment as to how to communicate some of the points. Mostly concerned with the diagram. It was pointed out that Vassil/Janet diagrams are more complex but more precise. They speak to XDR endpoints and are able to talk XDR. We may consider them not NHIN direct conversations but NHIN exchange, but at least this makes it clear. Strong consideration should be given to adopting these kinds of diagrams. Maybe a further drill down would be good.
Arien Malec
· NHIN exchange with addressing is a good way to think about it. When we write it up, we’ll see where we get.
Brett Peterson
· We support it immensely. Two questions for next revision:
o 1) There needs to be an explicit decidable mechanism for choosing a backbone. How would this be done?
o 2) Will we specify that current and future NHIN exchange nodes will require a NHIN Direct address in order to communicate to them?
Arien Malec
· Can answer second question: Nobody can tell the NHIN exchange participants what to do. It is certainly possible we do a great job and NHIN Exchange, with well defined governance, decides to adopt the standards and specs we’re talking about. At that point, the semantics we’re talking about here would be an option for NHIN exchange participants. There’s no requirement to support all NHIN exchange specifications.
Karen Witting
· We’re responding to what Vassil presented, not what David presented.
· It says we’ll use an SMTP backbone – what this means is that if there’s already a participant in NHIN Exchange and they want to participate in NHIN Direct, this means they would need to support SMTP. We’re saying you’re excluded from participating if you don’t have SMTP.
Arien Malec
· If you’re two NHIN Exchange participants and you’re doing NHIN Direct things, then you should be using the XDR backbone that you already support.
Karen Witting
· What I heard is that the goal for this proposal that while it’s true that you’re an NHIN exchange you can interact with people who don’t have NHIN Direct addresses. But if you want to talk with NHIN direct addresses, you can’t do that without SMTP. Not that you have to use SMTP, which you have to support.
Brian Behlendorf
· It might be possible if all existing NHIN Exchange participants are assigned to a default SMTP server or default HISP that could handle SMTP protocols on their behalf.
Arien Malec
· That’s a good solution, but the clear answer to Karen’s question is yes.
Karen Witting
· Someone has to provide SMTP for you. I’m concerned because it’s telling NHIN Exchange that you have to adopt SMTP. I think we should keep this in mind and I’m concerned about it.
Arien Malec
· None of us have any power to force NHIN exchange to do anything. There’s an existing technical committee that has interim governance. There’s a current process in DURSA for accepting new specs and standards. There will be an ONC rulemaking governance process that will define a similar process. That is the only process for NHIN exchange to accept or not accept new specifications.
· If you want to create an XDR community, that’s fine.
Karen Witting
· That’s not what I want to do, but I will accept the majority position.
Mark Gingrich
· With David McCallie’s friendly amendment that HISPs can choose a better way, Surescripts supports the proposal.
Keith Boone
· You have email addresses that only receive and only send an outbound message. It’s not clear to me in the current proposal whether it’s possible to have an NHIN Direct message that receives and never sends or always sends and never receives. This needs to be clarified.
· In general, I’m very much in support of this convergent proposal. Think headed in right direction.
· Think we need to look at some clarifications. Also need to look at source and destination bridge actors which have specific responsibilities in order to bridge between NHIN Direct and Exchange protocols. And by separating it out, we are getting a little bit more clarity as to how all of this could work. This may also provide the opportunity for NHIN Exchange user to send outbound mail to other users, but can’t receive.
Arien Malec
· It looks like we have an outline and a verbal agreement for a common path forward which I’m thrilled about. We also have work to do to get it written down.
· I’d like to suggest a work team start work on that today. I’m going to suggest Rich, David McCallie, Janet, Vassil, Keith, and Karen. If I’m leaving people out, please let me know.
· Between these people, we have enough of the right of the common consensus represented and can get to the right place.
Karen Witting
· Please remove from list. I will definitely review the work, but do not have time for this.
David Kibbe
· Most people represent an EHR vendor, so perhaps other people?
· Steve Waldren?
Steve Waldren
· That’s fine.
Arien Malec
· Let’s try and get that common proposal out. I suggest we do an offline round of endorsement. I’ll be out of pocket June 21st and 22nd.
· We will reschedule the Tuesday Implementation WG meeting for Wednesday.
Notes from the Concrete Implementation Workgroup
Date: June 18, 2010
Time: 12pm-1pm
Attendees: Steven Waldren, Ravi Madduri, Lin Wan, David McCallie, David Kibbe/Greg?, Vassil Peytchev, Janet Campbell, Wes Rishel, Jason Colquitt, Nageshwara Bashyam, Jeff Cunningham, Sean Nolan, Arien Malec, Brian Behlendorf, Uvinie Hettiaratchy, Dan Kazzaz, David Tao, Brett Peterson, Karen Witting, Mark Gingrich, Keith Boone, Richard Elmore
Actions for next Week:
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 34 |
6/18/10 |
Will draft verbal agreement and initial outline of common proposal |
Open |
Arien |
6/22/10 |
| 35 |
6/18/10 |
Finalize verbal agreement and detailed unified approach |
Open |
Rich, David McCallie, Janet, Vassil, Keith, Steve |
6/22/10 |
Actions for this Week:
| # |
Date |
Action |
Status |
Owner |
Due Date |
| 32 |
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 |
| 33 |
6/16/10 |
Review updated design principles for completeness and post any suggested ordering of these principles |
Open |
WG |
6/22/10 |
Agenda
· Discuss potential approaches for concrete implementation path forward
Notes
Arien Malec
· Pleased to see a lot of collaboration over last week.
· We have a choice of getting together under a consensus proposal.
o Number of people, Epic and GE team included, going towards the SMTP Team
o Number of people, including Rich Elmore and David McCallie, going towards the SOAP Team.
· Hoping we can meet in the middle
· Come to realize over last week that the realistic choice is between Wes Rischel’s approach versus a consensus oriented path.
· The choice that we have as a group is a choice of moving together or accepting parallel pilots. I know that there are organizations that are willing to drive early implementation around a REST proposal, SMTP proposal, and a SOAP proposal.
o This would be good for innovation.
o This would be bad for getting to the clinical outcomes, care management outcomes and efficiency outcomes we want.
o It would be bad for vendors with limited development staff such as State HIEs.
§ Everyone has to solve these problems and they will have to solve it a different way knowing they may have to switch over time.
o In the long term, it would be bad for getting to the goal of universal addressing and routing for every provider and every patient in the country.
o Without consensus, islands will eventually need to be cross-mapped or “drained.”
· Would like to invite representatives of the teams that have been working together to share where they are and what remaining items we have. Would like Vassil and Janet to give us their sense of the SOAP Team first.
Vassil Peytchev
· At last minute, added comments on convergence proposal on the wiki.
· Approach to innovation is for universal addressing and routing so that there is one NHIN.
· Should look at the consequences of choosing an underlying protocol for NHIN Direct.
· Current convergence proposal provides for XDR gateway, SOAP gateway, etc. and that is the key feature that will bring us together.
· Looked at the bigger picture of how NHIN Exchange and NHIN Direct can work together. Diagram on wiki shows participants from NHIN Direct’s perspective where things move by SMTP. Also shows NHIN Exchange’s perspective where things move through NHIN Exchange protocols – direct push and others.
· HISP capabilities are key. The current proposal has an XDR gateway which sends and receives XDR/SOAP messages. The bridging capabilities for HISP provides for technical bridging for two views, depending on where you sit. That bridging capability is what we tried to look at. As we discussed this in more detail, we tried to figure out how bridging occurs between different participants.
· Further down the list, you can see a link for a variation of an earlier email based on John Moehrke’s suggestion and tries to pinpoint convergence points, with different capabilities for the source and matches to different entry points.
· It doesn’t include the REST entry point.
· Near the bottom, you’ll see SMTP and XDR between the HISP. This does not mean we’re advocating for two backbones.
· Concentrated on describing the capabilities of the HISP. This means we can send between HISPS and sources and destinations. If we start talking about capabilities and make sure that the SMTP capability is always required, then that path forward will allow us to have one NHIN with different protocols.
· It’s possible that users of NHIN Direct will only care about NHIN Direct. It’s also likely that many of these participants will need to use NHIN Exchange services such as record locator services. Having a HISP which has capabilities to support sending and receiving XDR packages achieves that capability for small practice providers. That ability will gradually grow into the capability to consume and provide NHIN Exchange services.
Janet Campbell
· The current convergence proposal is close. We want to make sure that we’re talking about HISP responsibilities and capabilities. We should allow XDR messages between HISPs. We should provide for those paths to eventually connect to NHIN Exchange services.
Arien Malec
· This means that if you send and receive XDR then you must choose the XDR path. If you know that the source and destination are both on the other side of an NHIN exchange node or equivalent, then you must use the native NHIN Exchange protocol.
· We are not saying that we must use the NHIN Direct backbone if you have another way to get there.
· What it comes down to is that an HISP is required to support an SMTP backbone, and if in NHIN Exchange, to be required to document submissions that are XDR backbone.
· I think that’s an approach that leads to more complexity at the HISPs as they need to discover where the endpoints need to talk. I would be more comfortable saying that there is an open NHIN Direct Backbone and one NHIN Exchange backbone and demonstrate the paths that are required to support them. If you happen to know you can get the message another way, then use that way.
Vassil Peytchev
· Need more discussion around details of implementation.
· The goal is not to make the HISP too complex. In the convergence proposal, at the starting point from a HISP, there is an XDR gateway capability. If that is there, then you’re 90% there for connecting between NHIN Exchange and NHIN Direct.
Brian Behlendorf
· The main scenario to avoid is one where a patient or a doctor is sending a message to another and since they’re not on the right network, they can’t get the message through.
Lin Wan
· Is the diagram saying that the backbone is SMTP plus XDR? Why can’t there just be one?
Vassil Peytchev
· This is an exercise for discovering capabilities of the HISP.
· Each diagram at the bottom has a different path. This was to discover capabilities.
Lin Wan
· Why is the connection between the source HISP and destination HISP SMTP/XDR versus XDR?
Arien Malec
· There is one standard backbone that serves the wide variety of NHIN Direct endpoints. But if there are two NHIN Exchange participants talking to each other then there’s every reason for them to use XDR as their backbone.
· Think of it less as how the two edges talk, and more about how the HISPs talk.
· Would like to switch to Rich to discuss the approach for XDR on backbone defined by the source and destination talk. The HISP is required to discover what the destination can talk and send appropriately. Is the choice defined by whether the source HISP and destination HISP can talk (in which case the HISP already has a mechanism for discovering what the destination can talk)?
David McCallie
· The philosophical approach that is driving input here is:
1) Universal addressing : Universal addressing means everyone has to communicate with everyone else regardless of their client and HISP.
· 2) Bootstrapping approach is the best way towards widespread adoption.
o Predicated on belief that by using the lowest common denominator SMTP backbone, we can guarantee all clients to talk to each other. By keeping the payload content neutral, we can scale upwards towards the most sophisticated interaction an XDR protocol would allow.
· On our wiki page NHIN Direct proposal, if you scroll to middle of the page, there’s a multi-colored diagram which is our summary that shows how an expanded HISP could expose to the senders and receivers either simple SMTP or a RESTful replacement for POP and IMAP or an XDM message depending on what’s found on received message.
· Backbone would be SMTP as a carrier or an S/MIME internet message or something quite sophisticated if they can wrap into an XDM message.
· XDM has same data as XDR but can be easily manipulated by systems that do not have full XDR capabilities.
· I think the debate that we need to have is the option of not using the SMTP backbone.
· I think everyone needs SMTP backbone. Optionally, they should be allowed to use an alternative.
Arien Malec
· Agree with what you said and would like to work with you to be stronger on the NHIN Exchange case.
o In the NHIN Exchange case, we recommend/require that the two NHIN exchange nodes use the protocol for NHIN Exchange for getting the message through.
o Two HISPs may communicate with a better mechanism, but they must support the minimum.
David McCallie
· I agree. Nervous about definition of the NHIN Exchange nodes. I understand it’s a legal notion, but does that mean something above and beyond? What about HISPs that want to use some of the NHIN protocols?
Arien Malec
· For the precise case, this means full legal DURSA compliance.
· For non precise cases, if you have a way to communicate, we’re not saying you must use the SMTP backbone, just support it.
David McCallie
· Then I’d agree with that. If within a hospital, a provider wants to send information within an EHR, even if he could use the NHIN direct address, he wouldn’t necessarily need to go out and come back if he can send this through the EHR. I think we’re saying that at the HISP level, if the HISP has a better way of getting the message to the recipient, then use the better way. But the HISP must support SMTP so it can receive a message from anyone.
Arien Malec
· I’d like to now encourage people to ask questions. Let’s do a Round-the-Room.
Round-the-Room
Steven Waldren
· Thrilled with the proposals. On the SOAP based message, going from Source A to the HISP, I’m assuming it’s a SOAP/XDR destination.
Ravi Madduri
· Sounds good. No comment.
Lin Wan
· Fine solution, but if you select XDR to XDR, you have a layer translation where you translate the XDR payload to S/MIME. If you flip it and use a SMTP server to deal with email client and package into XDR package, would that not still work?
Arien Malec
· This brings up the issue of the required level of support for a HISP. What you’re suggesting is appropriate if two HISPs already speak the same protocols. What you’re also saying is reluctance to make every HISP speak two protocols.
Lin Wan
· If we standardize on one, then the HISP is only required to see SMTP or XDR. If you’re a community with full XDR, and you talk XDR, then there’s no conversion. The HISP is only required to support one of the protocols. Is there a huge difference other than addressing?
David McCallie
· The minimum protocol for best chance of bootstrapping capability is SMTP and HISPs are able to use optional protocol if better. They can avoid complexity and speak native protocol if necessary.
Lin Wan
· So really it comes down to addressing.
David McCallie
· Anyone may use a more direct mechanism of connection if the recipient can support it. It should be tested against security constraints, etc. We’re not at the finish line, but feels like a real step.
David Kibbe /Greg?
· We support this proposal.
Vassil Peytchev
· Support. I think there are details to be sorted out.
Wes Rishel
· Support.
Jason Colquitt
· Question: If XDR and SOAP is not an option for the backbone, what if you have a system that speaks XDR and can’t pass to a HISP?
Arien Malec
· We’ll have to better express the wording so that current participants understand this.
o I will take on revision of the text in a way that expresses the points we have discussed and makes it clear that if the two HISPs can speak XDR end to end and know that they can do that and they are enabled and part of NHIN exchange that they are encouraged to do so.
Jason Colquitt
· Then I agree.
Nageshwara Bashyam
· Couple of thing s to understand – when we think about a HISP and we go back to capabilities of a HISP, we need to have a SMTP support and speak XDR.
· Are we going to make them required when doing a systems implementation to be compliant? If so, then I support making this a little more complex. If you have options, it may be more confusing.
Arien Malec
· These are key issues to write down.
Jeff Cunningham
· In favor as long as SMTP is default.
Sean Nolan
· Fully support. This sounds great.
Dan Kazzaz
· I support this.
David Tao
· I support the proposal.
· One friendly amendment as to how to communicate some of the points. Mostly concerned with the diagram. It was pointed out that Vassil/Janet diagrams are more complex but more precise. They speak to XDR endpoints and are able to talk XDR. We may consider them not NHIN direct conversations but NHIN exchange, but at least this makes it clear. Strong consideration should be given to adopting these kinds of diagrams. Maybe a further drill down would be good.
Arien Malec
· NHIN exchange with addressing is a good way to think about it. When we write it up, we’ll see where we get.
Brett Peterson
· We support it immensely. Two questions for next revision:
o 1) There needs to be an explicit decidable mechanism for choosing a backbone. How would this be done?
o 2) Will we specify that current and future NHIN exchange nodes will require a NHIN Direct address in order to communicate to them?
Arien Malec
· Can answer second question: Nobody can tell the NHIN exchange participants what to do. It is certainly possible we do a great job and NHIN Exchange, with well defined governance, decides to adopt the standards and specs we’re talking about. At that point, the semantics we’re talking about here would be an option for NHIN exchange participants. There’s no requirement to support all NHIN exchange specifications.
Karen Witting
· We’re responding to what Vassil presented, not what David presented.
· It says we’ll use an SMTP backbone – what this means is that if there’s already a participant in NHIN Exchange and they want to participate in NHIN Direct, this means they would need to support SMTP. We’re saying you’re excluded from participating if you don’t have SMTP.
Arien Malec
· If you’re two NHIN Exchange participants and you’re doing NHIN Direct things, then you should be using the XDR backbone that you already support.
Karen Witting
· What I heard is that the goal for this proposal that while it’s true that you’re an NHIN exchange you can interact with people who don’t have NHIN Direct addresses. But if you want to talk with NHIN direct addresses, you can’t do that without SMTP. Not that you have to use SMTP, which you have to support.
Brian Behlendorf
· It might be possible if all existing NHIN Exchange participants are assigned to a default SMTP server or default HISP that could handle SMTP protocols on their behalf.
Arien Malec
· That’s a good solution, but the clear answer to Karen’s question is yes.
Karen Witting
· Someone has to provide SMTP for you. I’m concerned because it’s telling NHIN Exchange that you have to adopt SMTP. I think we should keep this in mind and I’m concerned about it.
Arien Malec
· None of us have any power to force NHIN exchange to do anything. There’s an existing technical committee that has interim governance. There’s a current process in DURSA for accepting new specs and standards. There will be an ONC rulemaking governance process that will define a similar process. That is the only process for NHIN exchange to accept or not accept new specifications.
· If you want to create an XDR community, that’s fine.
Karen Witting
· That’s not what I want to do, but I will accept the majority position.
Mark Gingrich
· With David McCallie’s friendly amendment that HISPs can choose a better way, Surescripts supports the proposal.
Keith Boone
· You have email addresses that only receive and only send an outbound message. It’s not clear to me in the current proposal whether it’s possible to have an NHIN Direct message that receives and never sends or always sends and never receives. This needs to be clarified.
· In general, I’m very much in support of this convergent proposal. Think headed in right direction.
· Think we need to look at some clarifications. Also need to look at source and destination bridge actors which have specific responsibilities in order to bridge between NHIN Direct and Exchange protocols. And by separating it out, we are getting a little bit more clarity as to how all of this could work. This may also provide the opportunity for NHIN Exchange user to send outbound mail to other users, but can’t receive.
Arien Malec
· It looks like we have an outline and a verbal agreement for a common path forward which I’m thrilled about. We also have work to do to get it written down.
· I’d like to suggest a work team start work on that today. I’m going to suggest Rich, David McCallie, Janet, Vassil, Keith, and Karen. If I’m leaving people out, please let me know.
· Between these people, we have enough of the right of the common consensus represented and can get to the right place.
Karen Witting
· Please remove from list. I will definitely review the work, but do not have time for this.
David Kibbe
· Most people represent an EHR vendor, so perhaps other people?
· Steve Waldren?
Steve Waldren
· That’s fine.
Arien Malec
· Let’s try and get that common proposal out. I suggest we do an offline round of endorsement. I’ll be out of pocket June 21st and 22nd.
· We will reschedule the Tuesday Implementation WG meeting for Wednesday.