Documentation and Testing Meeting 2011-01-12
Jump to navigation
Jump to search
Status of Notes: FINAL
Date: January 12, 2011
Time: 2:00pm EST
Attendees: Arien, John, Janet, Karen, Andy, Will, David
Janet -
Michele, no longer able to participate.
XDR/XDM spec due for full consensus today. What's the plan for responding to comments? Arien, is that something you're going to do?
Arien -
Karen and I work best when I propose and she disposes. End of today is the end of the comment period. I'll take the comments today to make another revision of the spec and hand it off to Karen. We need the security inspection (risk analysis) before passing off for full consensus.
Karen -
There's one comment other than mine about what to do with the text of an email.
Arien -
John's proposed solution seems good.
Janet -
Agreed. This seems like a clearer solution than another proposed.
Karen -
Need to address it in the spec. I'm fine with John's solution.
Janet -
Anything else?
Next document is the deployment models document which John was going to go through the comments and revise?
John -
I made very few changes, but there is a lot of text in here that we need to discuss.
Arien -
We should put that document in the work in progress section.
Janet -
I'll add it to the WG page. Also the testing guides.
John -
My response to all of these was not necessarily an easy one. The first one is talking about how there might be other deployment models that come out of the pilots.
Arien -
We just need to classify this as an informative document, not a normative document.
John -
Not sure if there are any changes that are even being asked for today. Next, it's hard to tell what Epic's vote is. They had the same comment as Paris. It's true that you could have a particular implementation that can speak non-Direct project on one side and non-Direct project on another and never produce content that is compliant with the Direct project and ultimately get the use case done. This is being shown in the cases. If I know that the end point is XDR, I could route it. You get the job done, but ultimately that particular transaction was not Direct compliant.
Arien -
This is part of the "existential document" (What Does it Mean to Be Direct Compliant). It doesn't involve the core Direct specification. It doesn't require any transformation or involve much use of the XDR/XDM specification, but in terms of the labeling or the branding, the approach that I think we're taking for Direct compliant is that I can send or receive from any Direct compliant user . If my HISP is noting that we're XDR on both sides and gets the message through, but if the ultimate receiver were SMTP then that system is Direct compliant, even if the leg from beginning to end was XDR all the way through.
John -
We're saying the same thing. I'm not saying that the system that they have could not use Direct compliant transactions, but that the specific pathways that that message went by was not Direct compliant.
Arien -
Compliant is a loaded word. This one is a common enough question and it gets at the "existential document."
John -
Then I disagree with the existential document. You are starting to specify applications not specifications.
Arien -
The question is whether the deployment models should indicate a pure routed XDR to XDR connectivity. John's point is that that's neither here nor there in a Direct project perspective. We need to have that context in a definitional perspective and revisit this.
…
John -
XDR does not have a common patient ID.
Arien -
I propose this line of discussion is deferred to Janet's compliance document.
John -
Deployment model document as it's written today presumes that you have to have Direct compliant transactions to be called Direct compliant. I'll defer the discussion to a later time, but we're not saying that you could do HL7 v2 to HL7 v2 and just call yourself Direct compliant…
Visionshare made 3 comments. Changes were made. Those were the only comments that led to changes.
Janet -
It's noted that the one outstanding question with the other document will wait.
Secure Health Transport document. I haven't looked at the comments recently. Where there other things we need to discuss here.
Arien -
Karen had the substantive comments. I think we got a pass forward on all of them. I'll apply the same approach to XDR/XDM at the end of the day today or tomorrow.
Janet -
Anything else?
John -
I just put my current set of comments in there. I may have more by the end of the day.
Janet -
Next one is the testing guide. It was being handed over to RI group. Any updates?
Arien -
Rather than learning additional test cases from them, they have yet to run trough all of the test cases that we've specified. It seems like a good sign. This document was a good first take at a reasonable set of end-to-end verifications. I would move to elevate this document and push it to the implementation group.
Janet -
It never went through Documentation WG consensus. Is that necessary?
John -
I'm unclear how it can be reviewed without it being executed even once.
Arien -
We can take that approach as well just to make sure that the RI group actually executes all the steps.
John -
I'm unsure how to get this approved. I don't know of any other organization that does consensus like this.
Janet -
Good point. That's one of the things that was raised last time. We weren't committed to saying that this needs to go through this process because it's not really a pass-fail on compliance -- maybe it could be more of a working document.
Arien -
Could be an informative document that isn't formally consensed. We do have a section for that in the documentation library.
Janet -
My vote is that it shouldn't be formally consensed, but no strong feelings. For now let's let RI group run through all tests. Once they do we can see what they think. They're most affected by this. We'll see if they think it should be more official.
The process document -- reading the S&I Framework...
John -
On the testing document, we're going to put that under the additional informational material?
Arien -
Yes, that's the proposal.
John -
We would like to eventually elevate it to be more formal than those.
Janet -
That brings us to the Direct project compliance document. I wrote it based on Arien's blog post and my own understanding. I'm certainly open to suggestions. One question that everyone has brought up is "how inclusive is the Direct project." One of the things I felt was that it came up in the context of whether you knew the person you were sending it to (in a broader sense: if your systems knew each other). I had written it like "as long as we trust each other I can give you my business card with my Direct address on it and you can send to me. But it was brought up that does actually close out some exchanges like SureScripts and CCF because that's one end point. You might say that's not Direct, which I did. It is a push of documents so maybe from a broader perspective maybe we do want to call that Direct.
It's linked off of documentation priorities page.
John -
A system that is compliant to the specification has the ABILITY to use the specification. If operationally, any particular communications happen to be done more efficiently through other means that's outside the scope of any question of its compliance.
Arien -
That's a good way to use it. The metaphor is that it's email. If you and I are both using Gmail and Google doesn't use SMTP to get the message to point A to point B. It's still e-mail.
David -
I agree with John. ...
Arien -
Compliance is a system feature, not a transaction by transaction feature.
John -
Once you make that clear people will understand that it's ok to circumvent Direct specifications for efficiency sake. By doing that you're not becoming non-compliant, it's just that that transaction itself.
...
Arien -
If you turn off S/MIME your system is operational incapable of doing it, but if you're in a referral network where 100% of your referrals are handle by a propriety exchange but an outside entity COULD send communications to you -- you just happen not to ever do exchange for someone outside that referral network -- that system I would claim would be Direct compliant.
John -
To give a very specific example: When SureScripts offers their system and the 2 end points are within their network and it never goes to an SMTP message, but as long as SureScripts could send to someone that uses the Direct spec...
Arien -
We see the same question in the context of "I have an EHR, that EHR speaks XDR but the EHR combined with the HISP that implements the XDR and XDM and does the SMTP gateway function," that system is compliant even if the EHR alone is not.
Janet -
Other comment was about the content agnostic bit.
Arien -
A bit of context. There has been a lot of go around between Dixie, John Halamka, and myself. We all agreed that there will be systems that will use the Direct specifications that have business needs to lock down to a specific type of healthcare content. An example is RIQI wants to do a launch … doesn't have a business interest in opening an address that can handle unstructured… Essentially a branding question that says that a health system or physician who is using the direct project for continuity of care or HIE should be open to as broad of an IE as possible. There are certain contents like text or pdf that they should be open to. They may lock down certain addresses, but they should have at least one address that's open to a broad range of content. The reason for that is a policy concern, not a technology concern. The health system may end up putting walls around itself that would make it harder for a provider that's just using email. A policy belief that such systems should have at least one address that can accept less structured information. The best place to handle it would be in this branding oriented "what is direct" document.
Janet -
Our customers would balk at that. The idea that they had to use some kind of format, meaning they'd have to staff someone, have to be liable, etc. If you look at how Meaninful Use looks at exchange as being much more structured.
Arien -
My comment exactly to Dixie and John.
John -
We succeeded on getting them to understand this?
Arien -
I succeeded in kicking it from a technology to a policy discussion and pointing out that this would be a good place for the policy question.
John -
You can't force them to take something that they cannot deal with.
Janet -
For the most part, it should not be restricted technically.
John -
The fact that it's agnostic?
Janet -
Yes.
Arien -
The conclusion is that that specifications can say it's content agnostic. The "what is direct" will have language that will say something like "to preserve the broadest degree of HIE to allow health systems with sophisticated systems to exchange information with physicians we recommend that they have an address that can accept unstructured information." Keep it clearly in policy space.
Karen -
Where does that statement go? In particular, are we talking about the compliance document still? It shouldn't go in the compliance document.
Arien -
I think it goes some place there, but hopefully in a clearly marked policy section, not in the technology section.
Janet -
I'll give it a try.
John -
We should have a document on guidelines for using Direct specifications. There are other things that are littered throughout where we go slightly overboard. One was the concept of having dedicated addresses to particular workflows...
Karen -
This sounds like a best practices job.
Karen -
While trying to recommend that you have an end-point that accept structures, that doesn't mean that that is required.
Arien -
We're all on the same page, but we need to find a good way of saying this.
John -
We all agree that we should find some place formal where we say those things without saying it has anything to do with being compliant or not.
Karen -
We have said this. In the piece that Arien wrote.
Arien -
That was the language I wrote back to Dixie, we agreed that's fine in the spec, but we need another statement.
Janet -
Essentially I could deal with this in the same way by not trusting anybody who is going to send me junk.
John -
Think about SSA example. They have to trust providers to deliver them content.
One other related issue: There is a difference between trusting the identities and authorizing the identity to do something. The SSA can trust in providers but only authorize them to deliver a specific type of content.
Janet -
If the SSA doesn't want to receive unstructured content… I'll see what I can do.
Arien -
I think this really belongs in MU criteria, this whole discussion can go through that open and transparent process, but it's important for us to say something in a way that constrains things as little as possible.
Karen -
I think we've done that.
Janet -
This week take a look at that document (What does it mean to be direct compliant). There are some questions in it. I'll do my best to address other comments there. Any other questions, concerns?
Thanks, everybody!
Date: January 12, 2011
Time: 2:00pm EST
Attendees: Arien, John, Janet, Karen, Andy, Will, David
Janet -
Michele, no longer able to participate.
XDR/XDM spec due for full consensus today. What's the plan for responding to comments? Arien, is that something you're going to do?
Arien -
Karen and I work best when I propose and she disposes. End of today is the end of the comment period. I'll take the comments today to make another revision of the spec and hand it off to Karen. We need the security inspection (risk analysis) before passing off for full consensus.
Karen -
There's one comment other than mine about what to do with the text of an email.
Arien -
John's proposed solution seems good.
Janet -
Agreed. This seems like a clearer solution than another proposed.
Karen -
Need to address it in the spec. I'm fine with John's solution.
Janet -
Anything else?
Next document is the deployment models document which John was going to go through the comments and revise?
John -
I made very few changes, but there is a lot of text in here that we need to discuss.
Arien -
We should put that document in the work in progress section.
Janet -
I'll add it to the WG page. Also the testing guides.
John -
My response to all of these was not necessarily an easy one. The first one is talking about how there might be other deployment models that come out of the pilots.
Arien -
We just need to classify this as an informative document, not a normative document.
John -
Not sure if there are any changes that are even being asked for today. Next, it's hard to tell what Epic's vote is. They had the same comment as Paris. It's true that you could have a particular implementation that can speak non-Direct project on one side and non-Direct project on another and never produce content that is compliant with the Direct project and ultimately get the use case done. This is being shown in the cases. If I know that the end point is XDR, I could route it. You get the job done, but ultimately that particular transaction was not Direct compliant.
Arien -
This is part of the "existential document" (What Does it Mean to Be Direct Compliant). It doesn't involve the core Direct specification. It doesn't require any transformation or involve much use of the XDR/XDM specification, but in terms of the labeling or the branding, the approach that I think we're taking for Direct compliant is that I can send or receive from any Direct compliant user . If my HISP is noting that we're XDR on both sides and gets the message through, but if the ultimate receiver were SMTP then that system is Direct compliant, even if the leg from beginning to end was XDR all the way through.
John -
We're saying the same thing. I'm not saying that the system that they have could not use Direct compliant transactions, but that the specific pathways that that message went by was not Direct compliant.
Arien -
Compliant is a loaded word. This one is a common enough question and it gets at the "existential document."
John -
Then I disagree with the existential document. You are starting to specify applications not specifications.
Arien -
The question is whether the deployment models should indicate a pure routed XDR to XDR connectivity. John's point is that that's neither here nor there in a Direct project perspective. We need to have that context in a definitional perspective and revisit this.
…
John -
XDR does not have a common patient ID.
Arien -
I propose this line of discussion is deferred to Janet's compliance document.
John -
Deployment model document as it's written today presumes that you have to have Direct compliant transactions to be called Direct compliant. I'll defer the discussion to a later time, but we're not saying that you could do HL7 v2 to HL7 v2 and just call yourself Direct compliant…
Visionshare made 3 comments. Changes were made. Those were the only comments that led to changes.
Janet -
It's noted that the one outstanding question with the other document will wait.
Secure Health Transport document. I haven't looked at the comments recently. Where there other things we need to discuss here.
Arien -
Karen had the substantive comments. I think we got a pass forward on all of them. I'll apply the same approach to XDR/XDM at the end of the day today or tomorrow.
Janet -
Anything else?
John -
I just put my current set of comments in there. I may have more by the end of the day.
Janet -
Next one is the testing guide. It was being handed over to RI group. Any updates?
Arien -
Rather than learning additional test cases from them, they have yet to run trough all of the test cases that we've specified. It seems like a good sign. This document was a good first take at a reasonable set of end-to-end verifications. I would move to elevate this document and push it to the implementation group.
Janet -
It never went through Documentation WG consensus. Is that necessary?
John -
I'm unclear how it can be reviewed without it being executed even once.
Arien -
We can take that approach as well just to make sure that the RI group actually executes all the steps.
John -
I'm unsure how to get this approved. I don't know of any other organization that does consensus like this.
Janet -
Good point. That's one of the things that was raised last time. We weren't committed to saying that this needs to go through this process because it's not really a pass-fail on compliance -- maybe it could be more of a working document.
Arien -
Could be an informative document that isn't formally consensed. We do have a section for that in the documentation library.
Janet -
My vote is that it shouldn't be formally consensed, but no strong feelings. For now let's let RI group run through all tests. Once they do we can see what they think. They're most affected by this. We'll see if they think it should be more official.
The process document -- reading the S&I Framework...
John -
On the testing document, we're going to put that under the additional informational material?
Arien -
Yes, that's the proposal.
John -
We would like to eventually elevate it to be more formal than those.
Janet -
That brings us to the Direct project compliance document. I wrote it based on Arien's blog post and my own understanding. I'm certainly open to suggestions. One question that everyone has brought up is "how inclusive is the Direct project." One of the things I felt was that it came up in the context of whether you knew the person you were sending it to (in a broader sense: if your systems knew each other). I had written it like "as long as we trust each other I can give you my business card with my Direct address on it and you can send to me. But it was brought up that does actually close out some exchanges like SureScripts and CCF because that's one end point. You might say that's not Direct, which I did. It is a push of documents so maybe from a broader perspective maybe we do want to call that Direct.
It's linked off of documentation priorities page.
John -
A system that is compliant to the specification has the ABILITY to use the specification. If operationally, any particular communications happen to be done more efficiently through other means that's outside the scope of any question of its compliance.
Arien -
That's a good way to use it. The metaphor is that it's email. If you and I are both using Gmail and Google doesn't use SMTP to get the message to point A to point B. It's still e-mail.
David -
I agree with John. ...
Arien -
Compliance is a system feature, not a transaction by transaction feature.
John -
Once you make that clear people will understand that it's ok to circumvent Direct specifications for efficiency sake. By doing that you're not becoming non-compliant, it's just that that transaction itself.
...
Arien -
If you turn off S/MIME your system is operational incapable of doing it, but if you're in a referral network where 100% of your referrals are handle by a propriety exchange but an outside entity COULD send communications to you -- you just happen not to ever do exchange for someone outside that referral network -- that system I would claim would be Direct compliant.
John -
To give a very specific example: When SureScripts offers their system and the 2 end points are within their network and it never goes to an SMTP message, but as long as SureScripts could send to someone that uses the Direct spec...
Arien -
We see the same question in the context of "I have an EHR, that EHR speaks XDR but the EHR combined with the HISP that implements the XDR and XDM and does the SMTP gateway function," that system is compliant even if the EHR alone is not.
Janet -
Other comment was about the content agnostic bit.
Arien -
A bit of context. There has been a lot of go around between Dixie, John Halamka, and myself. We all agreed that there will be systems that will use the Direct specifications that have business needs to lock down to a specific type of healthcare content. An example is RIQI wants to do a launch … doesn't have a business interest in opening an address that can handle unstructured… Essentially a branding question that says that a health system or physician who is using the direct project for continuity of care or HIE should be open to as broad of an IE as possible. There are certain contents like text or pdf that they should be open to. They may lock down certain addresses, but they should have at least one address that's open to a broad range of content. The reason for that is a policy concern, not a technology concern. The health system may end up putting walls around itself that would make it harder for a provider that's just using email. A policy belief that such systems should have at least one address that can accept less structured information. The best place to handle it would be in this branding oriented "what is direct" document.
Janet -
Our customers would balk at that. The idea that they had to use some kind of format, meaning they'd have to staff someone, have to be liable, etc. If you look at how Meaninful Use looks at exchange as being much more structured.
Arien -
My comment exactly to Dixie and John.
John -
We succeeded on getting them to understand this?
Arien -
I succeeded in kicking it from a technology to a policy discussion and pointing out that this would be a good place for the policy question.
John -
You can't force them to take something that they cannot deal with.
Janet -
For the most part, it should not be restricted technically.
John -
The fact that it's agnostic?
Janet -
Yes.
Arien -
The conclusion is that that specifications can say it's content agnostic. The "what is direct" will have language that will say something like "to preserve the broadest degree of HIE to allow health systems with sophisticated systems to exchange information with physicians we recommend that they have an address that can accept unstructured information." Keep it clearly in policy space.
Karen -
Where does that statement go? In particular, are we talking about the compliance document still? It shouldn't go in the compliance document.
Arien -
I think it goes some place there, but hopefully in a clearly marked policy section, not in the technology section.
Janet -
I'll give it a try.
John -
We should have a document on guidelines for using Direct specifications. There are other things that are littered throughout where we go slightly overboard. One was the concept of having dedicated addresses to particular workflows...
Karen -
This sounds like a best practices job.
Karen -
While trying to recommend that you have an end-point that accept structures, that doesn't mean that that is required.
Arien -
We're all on the same page, but we need to find a good way of saying this.
John -
We all agree that we should find some place formal where we say those things without saying it has anything to do with being compliant or not.
Karen -
We have said this. In the piece that Arien wrote.
Arien -
That was the language I wrote back to Dixie, we agreed that's fine in the spec, but we need another statement.
Janet -
Essentially I could deal with this in the same way by not trusting anybody who is going to send me junk.
John -
Think about SSA example. They have to trust providers to deliver them content.
One other related issue: There is a difference between trusting the identities and authorizing the identity to do something. The SSA can trust in providers but only authorize them to deliver a specific type of content.
Janet -
If the SSA doesn't want to receive unstructured content… I'll see what I can do.
Arien -
I think this really belongs in MU criteria, this whole discussion can go through that open and transparent process, but it's important for us to say something in a way that constrains things as little as possible.
Karen -
I think we've done that.
Janet -
This week take a look at that document (What does it mean to be direct compliant). There are some questions in it. I'll do my best to address other comments there. Any other questions, concerns?
Thanks, everybody!