Documentation and Testing Meeting 2011-02-16
Jump to navigation
Jump to search
2:00 PM EST
Janet Campbell, John Moehrke, Karen Witting, Imran Chaudhri, Will Ross
Janet -
Voting is about to conclude on the Simple Health Transport document. There is also the XDR/XDM minimal metadata conversation. John/Karen, did anything else come of the IHE discussion on that? Everyone agreed to the spec, but there was some confusion about what we need to do with the author names.
Karen -
Ok, so we're talking about the problems with author attribute. There was a lot of confusion and misalignment. In Direct we want to do what the spec currently says which is that author is required and authorTelecommunications holds the author and the question that's open is what should authorPerson contain. I think I heard someone suggest that there should be some unknown code in there. The other option is that Direct is violating all kinds of other places in IHE and another suggestion I heard is saying that instead Direct could recommend at least one of the subslots of author. If you said that authorTelecommunications was filled in, you didn't need authorPerson.
John -
I think that's what Vassil recommended in the meeting.
Karen -
I like all of those suggestions, but I like the last one the best.
John -
Honestly, I don't really care. I didn't know that IHE had placed and subcomponent requirements. What I think has happened is because of the way we wrote the table at IHE breaking out the subcomponents, there is an implied requirement there.
Janet -
It's actually not. It's pretty obvious.
John -
I didn't realize we had any subcomponent requirement, we just had author as a requirement. That would be my answer. The last one would be my preference as well.
Karen -
Right now the sub attributes of author are authorInstitution, authorPerson, authorRole, authorSpecialty and then we're adding authorTelecommunication. I think that one of either authorInstitution, Person or Telecommunication, one of those three should be specified.
Janet -
I actually noticed that on our implementation we were already doing it wrong and I would be surprised given our reaction and that John was saying he didn't know it was required and things like that. I think most people are probably not enforcing that as strongly as they could be anyway.
Karen -
I kind of feel like authorPerson, although it says machine or human, it is an XDM and I think XDM is really designed for representing a human, not a machine. I think the description conflicts with the data type. Moving forward in IHE what I'm going to suggest is that we change the description of author to require one of: authorInstitution, Person or Telecommunication and we'll see how that flies.
Janet -
I think that sounds fine. I don't remember in the XDR/XDM minimal metadata spec if we had even addressed this at all.
Karen -
We have not addressed it. As far as I know an update hasn't gone in, but I haven't looked at it lately. What we should probably do in there, is say that we're violating the IHE spec…
Janet -
In fact I think I remember because what we need to remove in the spec is the bit that says that you provide the Direct address as part of the authorPerson.
John -
Yes, we may have to adjust where that goes.
Janet -
I can take a look at editing the spec, but could someone else volunteer?
John -
The urgency of the e-mails was because we were at the face-to-face and the topic had come up. I think we will continue to spiral in on this and as that happens, we can update the Direct spec.
Karen -
I'm updating it right now. I'll change the sentence to say "Even though author person is required by IHE, since authorTelecommunication is valued the authorPerson may be omitted."
Janet -
That does bring up a question with the XDR/XDM. It's going to continue to be a work in progress. It's more reliable than some of our other works in progress. The way that we've done that in the past is put it under "additional informational material." Or we could do our published works. I think I'd like to bring this to a little more prominence because it has been agreed upon and I know the Communications workgroup is eager to advertise that it's out there.
John -
One possibility is that we just have at the top a change tracking, because generally these things are very minor so what you do is just simply add that a change was made to the author in the submission set. They will see that at the top and say, "oh there has been a change made." But that way you do something very visible up front. It's just a single line of text.
Janet -
I think that the document is now at a more reliable state than it was when it was being written such that someone who is looking to implement the minimal metadata spec could use this document in order to do it. What I'm wondering is "is there a way to convey that by A) raising that to more prominence on the wiki page B) what do we call this? Published Work?"
Karen -
It should go into "Our Published Works." In my opinion the homepage of Direct, right now, is all about recent news, which is fine, but there should be a "Our Published Work" or "Approved Content" or something that gets people all of the stuff that has been officially approved by Direct. I think that would be great to have on the homepage.
Janet -
Yes. There is also this Documentation Library page, but it seems to be all over the place. Dave, can you make this page better? We need to put better links to the standards and also make sure that links in documentation library are a full collection of the artifacts. For example, there is only 1 in there from the Best Practices group, but they're done much more than that.
Can we move onto the compatibility document? Did anyone not receive the e-mail that John sent most recently to the newest revisions to this Compliance / Compatibility document?
There is a lot of history to this. What we're trying to do is come up with a statement that is closer to being readable and comprehendible by someone who is looking to a vendor or implementation and asking themselves "is that the Direct project, do they support he Direct Project?" People have been coming to it from different perspectives. There has been the point of view of an official compliance or certified compliance - and that's not this document. That's the secure health transport document - the main must/should document. There is also a group that I think is really targeted at protecting vendor interest and making sure as vendors "yes, I support the Direct project." And then there is another faction that is making sure that their own implementations are getting grant money. I don't mean to bash people's motives. There are a lot of good reasons for this. So we've got this document that is trying to do a lot of things and represent a lot of interests.
A good starting point may be to start with John's comments and work through those. So the first point was the sentence that says "when a solution defines itself as compliant … with whom they need to communicate." John picked up on an interesting distinction here. The point of writing that was that you could rely on the technical to respect your trust fabric versus "it is up to the trust fabric to define who you can exchange with. What I was trying to get at was that the system won't let you down assuming that you manage it correctly.
John -
I think that it steps into the boundary of overselling the solution and I think less is more in this case. It is just that making statements about an operational environment could be bad if it uses the Direct spec.
Janet -
So the reason why it went in there in the first place, it wasn't in the first draft, Andy felt like he needed a description of why he was reading it in the first place." Perhaps it would be worth adding one more sentence to the first paragraph that summarizes why compliance is important. And then he actually did the wording: "Defining an implementation as compliant gives confidence that they can exchange all of the messages they need with whom they need to communicate.
John -
I do understand your goal, and I have a hard time figuring out how to word it differently. All I can do is point out that we can't make statements about an operational environment; we can only make statements about the specification. When put into an operational environment that has Direct, the trust fabric won't tear. If we prefix it like that…
Janet -
Can we say something along the lines of "that their technology can support the exchange of" and say that it provides the means.
John -
Yeah, it provides the means, the technology.
Janet -
How about this: When a solution defines itself as compliant, purchasers and users can use it to support the exchange of health information they need with the senders and recipients with whom they need to communicate.
John -
What I'm trying to say is that compliance is not enough. If we were to say something more blunt like a solution that has put in place the identity management trust fabric, it's that setting of "when put into an operational environment that's secure the transport can handle security between those endpoints.
Janet -
When a solution defines itself as compliant, purchasers and users can use it with appropriate procedures and policies to support… Something like that?
Will -
Why are we saying purchasers?
John -
Earlier you created a term for the people who are using the compliant system - "participants". So you might as well reuse that instead of purchasers.
Janet -
We could also say "combine this with appropriate policies and procedures…".
John -
You brought in trust fabric earlier. Saying that the operational environment is responsible for creating the trust fabric should be understandable.
Janet -
"Participants can combine it with organizational trust fabric"? Something's not quite right. Combining it with a trust fabric sounds odd. This is going to go through another round anyway, so let's start with this.
The next one was "send to an endpoint vs. route messages to an endpoint" that came directly from Arien . I believe the difference he was getting at there was the capability to push a message and the capability to receive a pushed message.
John -
See, I would just assume remove those first two because you restate it with more detail in the third bullet. I was just wondering if there was an explicit reason for having those 3 bullets saying the same thing.
Janet -
I think the reason, I'm pretty sure sending and routing is based on if I'm a HISP or whatever, I receive a message pushed to me I can get that message to the appropriate end point. Actually if I'm a router or single system or whatever it is, it's just a lot simpler if there is only one user on the system.
John -
Which the third bullet says: "to send to and receive from any other Direct address." That's about as inclusive of a statement as you can have.
Janet -
I think the goal is to first focus on sending, then receiving, then focus on the fact that if there is a common identity and trust then we're okay.
Personally I find it easier this way because the bullets are smaller and more easily digestible rather than having one statement that combines them all.
John -
Yes, but by breaking these into independent pieces we add potential misunderstandings.
Janet -
This is something that someone generally wants to know: "what does it mean to have a system that says it's compliant/compatible." They can look at this and say sending, receiving, common identities of trust, SMTP, S/MIME and possibly other stuff.
John-
Right, but if I have a simple endpoint, it does absolutely no routing. The internet does the routing. Someone could come back and say "you're not compliant because you're not doing the routing.
Janet -
This is binding, it's explanatory.
John -
There is nothing in our specification about routing.
Janet -
What we're getting is not the routing that you're thinking of. I think the idea was that it can get to whomever it was addressed to.
Does anyone else have any comments?
For now I'm going to leave this as an in-line comment and when we open it up to the bigger group then they can all answer.
John -
I'm sure Arien will respond, so if those are indeed his words he will be the one to clarify in the e-mail thread. So we'll ultimately get his response.
Janet -
John, I'm not sure if I understand your last point in the e-mail.
John -
The paragraph where we talk about "pluggables": it seems to me that the goal here is just to simply say that what you do inside of your solution is immaterial, for example, and then you've got the bulleted points of example. I think by bringing in the term "pluggable" you'll be causing more confusion.
Janet -
I'm okay with removing "pluggable" here and using Direct compatible instead. I think the concern is that if my EMR only supports XDR and XDM but I do support the minimal metadata spec and I can work together with a HISP to exchange messages with the minimal metadata…
John -
And that's what the examples show, right?
Janet -
Yes, but I think that the goal was to specifically that a system that works like that can be called Direct compatible.
John -
So could one that's doing a bunch of other things. That's why I'm thinking that the examples are very illustrative. I think there is a better way to get the message across.
Janet -
Maybe if we remove the last sentence…
John -
All I'm saying is that simplicity of the message is better. And then I think you should put your buzzword compliant XDR in the example somewhere, and then the other part of that was, I'm surprised not to see a PHR example down there. We could probably convert one of the EHRs to PHR.
Janet -
I like that. We can change the first one.
John -
To me, that's the whole process of this stage is to make people understand that you don't have to have the software that the user is directly interacting with as long as the job gets done. By putting up a bunch of examples you are far more inclusive.
Janet -
I think that works and I've updated it to show that. I would like to keep the Direct compatible bit, but I took out the second sentence and the "pluggable" which just introduced another term. Any other comments that we can address right now?
Is there anything else that we need to talk about?
Great. Thanks everyone. I'll send this back out to the group. Safe travels if you are going to HIMSS next week!
Documentation & Testing Workgroup Call
Wednesday, February 16, 20112:00 PM EST
Janet Campbell, John Moehrke, Karen Witting, Imran Chaudhri, Will Ross
Janet -
Voting is about to conclude on the Simple Health Transport document. There is also the XDR/XDM minimal metadata conversation. John/Karen, did anything else come of the IHE discussion on that? Everyone agreed to the spec, but there was some confusion about what we need to do with the author names.
Karen -
Ok, so we're talking about the problems with author attribute. There was a lot of confusion and misalignment. In Direct we want to do what the spec currently says which is that author is required and authorTelecommunications holds the author and the question that's open is what should authorPerson contain. I think I heard someone suggest that there should be some unknown code in there. The other option is that Direct is violating all kinds of other places in IHE and another suggestion I heard is saying that instead Direct could recommend at least one of the subslots of author. If you said that authorTelecommunications was filled in, you didn't need authorPerson.
John -
I think that's what Vassil recommended in the meeting.
Karen -
I like all of those suggestions, but I like the last one the best.
John -
Honestly, I don't really care. I didn't know that IHE had placed and subcomponent requirements. What I think has happened is because of the way we wrote the table at IHE breaking out the subcomponents, there is an implied requirement there.
Janet -
It's actually not. It's pretty obvious.
John -
I didn't realize we had any subcomponent requirement, we just had author as a requirement. That would be my answer. The last one would be my preference as well.
Karen -
Right now the sub attributes of author are authorInstitution, authorPerson, authorRole, authorSpecialty and then we're adding authorTelecommunication. I think that one of either authorInstitution, Person or Telecommunication, one of those three should be specified.
Janet -
I actually noticed that on our implementation we were already doing it wrong and I would be surprised given our reaction and that John was saying he didn't know it was required and things like that. I think most people are probably not enforcing that as strongly as they could be anyway.
Karen -
I kind of feel like authorPerson, although it says machine or human, it is an XDM and I think XDM is really designed for representing a human, not a machine. I think the description conflicts with the data type. Moving forward in IHE what I'm going to suggest is that we change the description of author to require one of: authorInstitution, Person or Telecommunication and we'll see how that flies.
Janet -
I think that sounds fine. I don't remember in the XDR/XDM minimal metadata spec if we had even addressed this at all.
Karen -
We have not addressed it. As far as I know an update hasn't gone in, but I haven't looked at it lately. What we should probably do in there, is say that we're violating the IHE spec…
Janet -
In fact I think I remember because what we need to remove in the spec is the bit that says that you provide the Direct address as part of the authorPerson.
John -
Yes, we may have to adjust where that goes.
Janet -
I can take a look at editing the spec, but could someone else volunteer?
John -
The urgency of the e-mails was because we were at the face-to-face and the topic had come up. I think we will continue to spiral in on this and as that happens, we can update the Direct spec.
Karen -
I'm updating it right now. I'll change the sentence to say "Even though author person is required by IHE, since authorTelecommunication is valued the authorPerson may be omitted."
Janet -
That does bring up a question with the XDR/XDM. It's going to continue to be a work in progress. It's more reliable than some of our other works in progress. The way that we've done that in the past is put it under "additional informational material." Or we could do our published works. I think I'd like to bring this to a little more prominence because it has been agreed upon and I know the Communications workgroup is eager to advertise that it's out there.
John -
One possibility is that we just have at the top a change tracking, because generally these things are very minor so what you do is just simply add that a change was made to the author in the submission set. They will see that at the top and say, "oh there has been a change made." But that way you do something very visible up front. It's just a single line of text.
Janet -
I think that the document is now at a more reliable state than it was when it was being written such that someone who is looking to implement the minimal metadata spec could use this document in order to do it. What I'm wondering is "is there a way to convey that by A) raising that to more prominence on the wiki page B) what do we call this? Published Work?"
Karen -
It should go into "Our Published Works." In my opinion the homepage of Direct, right now, is all about recent news, which is fine, but there should be a "Our Published Work" or "Approved Content" or something that gets people all of the stuff that has been officially approved by Direct. I think that would be great to have on the homepage.
Janet -
Yes. There is also this Documentation Library page, but it seems to be all over the place. Dave, can you make this page better? We need to put better links to the standards and also make sure that links in documentation library are a full collection of the artifacts. For example, there is only 1 in there from the Best Practices group, but they're done much more than that.
Can we move onto the compatibility document? Did anyone not receive the e-mail that John sent most recently to the newest revisions to this Compliance / Compatibility document?
There is a lot of history to this. What we're trying to do is come up with a statement that is closer to being readable and comprehendible by someone who is looking to a vendor or implementation and asking themselves "is that the Direct project, do they support he Direct Project?" People have been coming to it from different perspectives. There has been the point of view of an official compliance or certified compliance - and that's not this document. That's the secure health transport document - the main must/should document. There is also a group that I think is really targeted at protecting vendor interest and making sure as vendors "yes, I support the Direct project." And then there is another faction that is making sure that their own implementations are getting grant money. I don't mean to bash people's motives. There are a lot of good reasons for this. So we've got this document that is trying to do a lot of things and represent a lot of interests.
A good starting point may be to start with John's comments and work through those. So the first point was the sentence that says "when a solution defines itself as compliant … with whom they need to communicate." John picked up on an interesting distinction here. The point of writing that was that you could rely on the technical to respect your trust fabric versus "it is up to the trust fabric to define who you can exchange with. What I was trying to get at was that the system won't let you down assuming that you manage it correctly.
John -
I think that it steps into the boundary of overselling the solution and I think less is more in this case. It is just that making statements about an operational environment could be bad if it uses the Direct spec.
Janet -
So the reason why it went in there in the first place, it wasn't in the first draft, Andy felt like he needed a description of why he was reading it in the first place." Perhaps it would be worth adding one more sentence to the first paragraph that summarizes why compliance is important. And then he actually did the wording: "Defining an implementation as compliant gives confidence that they can exchange all of the messages they need with whom they need to communicate.
John -
I do understand your goal, and I have a hard time figuring out how to word it differently. All I can do is point out that we can't make statements about an operational environment; we can only make statements about the specification. When put into an operational environment that has Direct, the trust fabric won't tear. If we prefix it like that…
Janet -
Can we say something along the lines of "that their technology can support the exchange of" and say that it provides the means.
John -
Yeah, it provides the means, the technology.
Janet -
How about this: When a solution defines itself as compliant, purchasers and users can use it to support the exchange of health information they need with the senders and recipients with whom they need to communicate.
John -
What I'm trying to say is that compliance is not enough. If we were to say something more blunt like a solution that has put in place the identity management trust fabric, it's that setting of "when put into an operational environment that's secure the transport can handle security between those endpoints.
Janet -
When a solution defines itself as compliant, purchasers and users can use it with appropriate procedures and policies to support… Something like that?
Will -
Why are we saying purchasers?
John -
Earlier you created a term for the people who are using the compliant system - "participants". So you might as well reuse that instead of purchasers.
Janet -
We could also say "combine this with appropriate policies and procedures…".
John -
You brought in trust fabric earlier. Saying that the operational environment is responsible for creating the trust fabric should be understandable.
Janet -
"Participants can combine it with organizational trust fabric"? Something's not quite right. Combining it with a trust fabric sounds odd. This is going to go through another round anyway, so let's start with this.
The next one was "send to an endpoint vs. route messages to an endpoint" that came directly from Arien . I believe the difference he was getting at there was the capability to push a message and the capability to receive a pushed message.
John -
See, I would just assume remove those first two because you restate it with more detail in the third bullet. I was just wondering if there was an explicit reason for having those 3 bullets saying the same thing.
Janet -
I think the reason, I'm pretty sure sending and routing is based on if I'm a HISP or whatever, I receive a message pushed to me I can get that message to the appropriate end point. Actually if I'm a router or single system or whatever it is, it's just a lot simpler if there is only one user on the system.
John -
Which the third bullet says: "to send to and receive from any other Direct address." That's about as inclusive of a statement as you can have.
Janet -
I think the goal is to first focus on sending, then receiving, then focus on the fact that if there is a common identity and trust then we're okay.
Personally I find it easier this way because the bullets are smaller and more easily digestible rather than having one statement that combines them all.
John -
Yes, but by breaking these into independent pieces we add potential misunderstandings.
Janet -
This is something that someone generally wants to know: "what does it mean to have a system that says it's compliant/compatible." They can look at this and say sending, receiving, common identities of trust, SMTP, S/MIME and possibly other stuff.
John-
Right, but if I have a simple endpoint, it does absolutely no routing. The internet does the routing. Someone could come back and say "you're not compliant because you're not doing the routing.
Janet -
This is binding, it's explanatory.
John -
There is nothing in our specification about routing.
Janet -
What we're getting is not the routing that you're thinking of. I think the idea was that it can get to whomever it was addressed to.
Does anyone else have any comments?
For now I'm going to leave this as an in-line comment and when we open it up to the bigger group then they can all answer.
John -
I'm sure Arien will respond, so if those are indeed his words he will be the one to clarify in the e-mail thread. So we'll ultimately get his response.
Janet -
John, I'm not sure if I understand your last point in the e-mail.
John -
The paragraph where we talk about "pluggables": it seems to me that the goal here is just to simply say that what you do inside of your solution is immaterial, for example, and then you've got the bulleted points of example. I think by bringing in the term "pluggable" you'll be causing more confusion.
Janet -
I'm okay with removing "pluggable" here and using Direct compatible instead. I think the concern is that if my EMR only supports XDR and XDM but I do support the minimal metadata spec and I can work together with a HISP to exchange messages with the minimal metadata…
John -
And that's what the examples show, right?
Janet -
Yes, but I think that the goal was to specifically that a system that works like that can be called Direct compatible.
John -
So could one that's doing a bunch of other things. That's why I'm thinking that the examples are very illustrative. I think there is a better way to get the message across.
Janet -
Maybe if we remove the last sentence…
John -
All I'm saying is that simplicity of the message is better. And then I think you should put your buzzword compliant XDR in the example somewhere, and then the other part of that was, I'm surprised not to see a PHR example down there. We could probably convert one of the EHRs to PHR.
Janet -
I like that. We can change the first one.
John -
To me, that's the whole process of this stage is to make people understand that you don't have to have the software that the user is directly interacting with as long as the job gets done. By putting up a bunch of examples you are far more inclusive.
Janet -
I think that works and I've updated it to show that. I would like to keep the Direct compatible bit, but I took out the second sentence and the "pluggable" which just introduced another term. Any other comments that we can address right now?
Is there anything else that we need to talk about?
Great. Thanks everyone. I'll send this back out to the group. Safe travels if you are going to HIMSS next week!