Reference Implementation Meeting 2011-03-08
Jump to navigation
Jump to search
12:00 PM EST
Beau –
…The mirrors we were pointing to in our install docs were pointing to a 2.9 version that was no longer there. He upgraded that to 3.2 or something. I guess we've made the updates for at least the install package. The assembly package is still out of date.
Greg -
I'll make a note of that when we're ready to make the 1.1 release.
Beau -
I don't think we're tied to the 2.9 for any particular reason, so upgrading to 3.2 shouldn't cause any major issues. As we're testing we can probably notice any as they show up.
Mark -
A while ago I had sent an e-mail about operating our HISP behind firewalls. We ultimately just deployed our HISP in the cloud and got around that. I'm not sure if it's still an issue, but I posted the bug for it. Also, we were able to make the Java implementation have simultaneous listeners on secure and non-secure ports and do Direct messaging with SSL using SMTPS. So it's a definite possibility to do that with a single James instance. The other thing was using SSL messaging back to our servers behind the firewall to do webservices to our backend, so that can be done too. I think I should capture all of that configuration intelligence and post it because it because it seems that it would be a common way that people might use the RI.
Vince -
We basically have a call directly to a standard provide and register IHE service as part of the RI as a mail within James, so that if you already have an XDR implementation somewhere you can just point right at that, barring any problems with the metadata.
Mark -
I know we used M1 at HIMSS. In order to send our patient contacts we shoot an attachment, but the preferred way is XDM, right?
Vince -
The raw attachment form is when you really need the power of step up, you're going to be coming out with a lack of metadata. You could do either way, but probably the preferred would be XDM.
Mark -
Are there enough fields there that you think it could handle a general solution? I haven't looked enough to know whether it would actually fit with what we're doing in terms of having target OIDs and assigning authorities, etc.
Vince -
You're talking about the XD specification and the required/non-required fields? It's designed to be able to handle all of the recipients and everything it's designed to work in sync with the SMTP solution. It's giving you the option to not include some of the more esoteric fields like facility classification, class codes, etc. or giving you at least a default value for those. It stands to work correctly with almost any XDR solution really. We used it against our XDR at HIMSS as an endpoint and it worked fine, so it doesn't break anything really. At least with a reasonable set of metadata. We haven't tried it yet with the bare attachment. We're obviously breaking something now, so we need to fix that.
Beau -
That's where you start getting into cases where you don't have any metadata. Even if you're throwing a PDF into an e-mail you can't parse that for patient info, which is where it gets tricky hooking it up to the other end.
Mark -
As we were rushing to follow Bare Metal instructions I noticed that no instructions in there for installing ANT.
Beau -
Ok, we'll have to make sure we add that, because it's definitely required.
I wasn't able to make the Java meeting. We were going to discuss some changes to the UI that Brian was going to implement. What was the outcome of that discussion?
Greg -
There wasn't really any major outcome. We discussed future iterations potentially doing some workflow items for some of the settings, but we didn't push it further.
Beau -
It looks like we assigned all of the bugs for Java so we have a track of those.
Greg -
Bare Metal does have instructions for installing ANT.
Mark -
I was following another page which probably didn't get a parallel change.
Vince -
We do need a little space in the Bare Metal to talk about how to configure the webservice call.
Beau -
We definitely need to go back and add some details. Anything else from Java? [no]
Umesh -
For C# - last week we focused mainly on documentation - there is a ton of documentation now. We walked through the developer box setup and also added details on how to configure things, add anchors, etc. We have about 5x as many docs as before. Hopefully this will get people up and going.
FYI: If you're using links that contain anchors the Visual text editor on the Wiki breaks the links. You have to use the other editor.
Ali -
I'm adding caching for anchors on the SMTP agent. Really it's a performance optimization so we're not hitting the back end every time. After that I'm looking at being able to plug in resolvers. We have some defaults in the code base, but the feature here is to let people plug in external ones and they can interface to store their certificates or anchors anywhere else.
Umesh -
I think Java guys have had this for a while. I will probably put out a fresh build today. Last week we made several robustness fixes to the DNS server. We have tools in our production data centers that pretty much scan and try to find security holes / issues so that helped find some issues. Those are all fixed up and the code looks pretty good now. We'll put out a 1.1 release today or tomorrow. We're going to do a little more cleanup. FYI: we've deployed load balancing to production. I think we're basically going to start tapering this off now. The core features are in, the extension points will be in by the end of the week.
Beau -
Any update from Vassil on XD?
Umesh -
We have another volunteer for XD - Miguel Curi from Greenway Medical.
Greg -
Do we have a target for XD?
Beau -
Not yet. We should definitely address it. Maybe during the Java call on Thursday. We might specify a target for Java and let C# follow since they are still a little behind us.
Umesh -
We need to set a time-based deadline on this too.
Beau -
Anything else? [no] Thanks everybody -- talk to you next week.
Reference Implementation WG Call
Tuesday, March 08, 201112:00 PM EST
Beau –
…The mirrors we were pointing to in our install docs were pointing to a 2.9 version that was no longer there. He upgraded that to 3.2 or something. I guess we've made the updates for at least the install package. The assembly package is still out of date.
Greg -
I'll make a note of that when we're ready to make the 1.1 release.
Beau -
I don't think we're tied to the 2.9 for any particular reason, so upgrading to 3.2 shouldn't cause any major issues. As we're testing we can probably notice any as they show up.
Mark -
A while ago I had sent an e-mail about operating our HISP behind firewalls. We ultimately just deployed our HISP in the cloud and got around that. I'm not sure if it's still an issue, but I posted the bug for it. Also, we were able to make the Java implementation have simultaneous listeners on secure and non-secure ports and do Direct messaging with SSL using SMTPS. So it's a definite possibility to do that with a single James instance. The other thing was using SSL messaging back to our servers behind the firewall to do webservices to our backend, so that can be done too. I think I should capture all of that configuration intelligence and post it because it because it seems that it would be a common way that people might use the RI.
Vince -
We basically have a call directly to a standard provide and register IHE service as part of the RI as a mail within James, so that if you already have an XDR implementation somewhere you can just point right at that, barring any problems with the metadata.
Mark -
I know we used M1 at HIMSS. In order to send our patient contacts we shoot an attachment, but the preferred way is XDM, right?
Vince -
The raw attachment form is when you really need the power of step up, you're going to be coming out with a lack of metadata. You could do either way, but probably the preferred would be XDM.
Mark -
Are there enough fields there that you think it could handle a general solution? I haven't looked enough to know whether it would actually fit with what we're doing in terms of having target OIDs and assigning authorities, etc.
Vince -
You're talking about the XD specification and the required/non-required fields? It's designed to be able to handle all of the recipients and everything it's designed to work in sync with the SMTP solution. It's giving you the option to not include some of the more esoteric fields like facility classification, class codes, etc. or giving you at least a default value for those. It stands to work correctly with almost any XDR solution really. We used it against our XDR at HIMSS as an endpoint and it worked fine, so it doesn't break anything really. At least with a reasonable set of metadata. We haven't tried it yet with the bare attachment. We're obviously breaking something now, so we need to fix that.
Beau -
That's where you start getting into cases where you don't have any metadata. Even if you're throwing a PDF into an e-mail you can't parse that for patient info, which is where it gets tricky hooking it up to the other end.
Mark -
As we were rushing to follow Bare Metal instructions I noticed that no instructions in there for installing ANT.
Beau -
Ok, we'll have to make sure we add that, because it's definitely required.
I wasn't able to make the Java meeting. We were going to discuss some changes to the UI that Brian was going to implement. What was the outcome of that discussion?
Greg -
There wasn't really any major outcome. We discussed future iterations potentially doing some workflow items for some of the settings, but we didn't push it further.
Beau -
It looks like we assigned all of the bugs for Java so we have a track of those.
Greg -
Bare Metal does have instructions for installing ANT.
Mark -
I was following another page which probably didn't get a parallel change.
Vince -
We do need a little space in the Bare Metal to talk about how to configure the webservice call.
Beau -
We definitely need to go back and add some details. Anything else from Java? [no]
Umesh -
For C# - last week we focused mainly on documentation - there is a ton of documentation now. We walked through the developer box setup and also added details on how to configure things, add anchors, etc. We have about 5x as many docs as before. Hopefully this will get people up and going.
FYI: If you're using links that contain anchors the Visual text editor on the Wiki breaks the links. You have to use the other editor.
Ali -
I'm adding caching for anchors on the SMTP agent. Really it's a performance optimization so we're not hitting the back end every time. After that I'm looking at being able to plug in resolvers. We have some defaults in the code base, but the feature here is to let people plug in external ones and they can interface to store their certificates or anchors anywhere else.
Umesh -
I think Java guys have had this for a while. I will probably put out a fresh build today. Last week we made several robustness fixes to the DNS server. We have tools in our production data centers that pretty much scan and try to find security holes / issues so that helped find some issues. Those are all fixed up and the code looks pretty good now. We'll put out a 1.1 release today or tomorrow. We're going to do a little more cleanup. FYI: we've deployed load balancing to production. I think we're basically going to start tapering this off now. The core features are in, the extension points will be in by the end of the week.
Beau -
Any update from Vassil on XD?
Umesh -
We have another volunteer for XD - Miguel Curi from Greenway Medical.
Greg -
Do we have a target for XD?
Beau -
Not yet. We should definitely address it. Maybe during the Java call on Thursday. We might specify a target for Java and let C# follow since they are still a little behind us.
Umesh -
We need to set a time-based deadline on this too.
Beau -
Anything else? [no] Thanks everybody -- talk to you next week.