Next meeting
Dennis Ballance
All,
At the meeting last week, we had discussed having a meeting tomorrow, as I will be out of town the week following. The AVI has a standing meeting at 10am, but would 9am PDT on Thursday May 30 work for everyone? We will continue discussion on the scope and approaches to a peer-to-peer sharing protocol. Here are the notes from last week.
1. Last time: VRRS Broker
a. Analogous design to internet mail, but using HTTP instead of SMTP
b. Providers and consumers all communicate directly with application brokers that have resolvable internet addresses.
c. How would a new broker become known to the other brokers?
d. Question about identity verification - how do you ensure that the message really came from the server it claims to be from?
e. Is there a nonrepudiation process to ensure receipt and completeness of a transmission?
f. How is document exchange handled in human health?
2. Questions
a. How to add broker to network?
1. Asteris authenticates by facility (practice provides authentication)
b. Return receipt
1. Generally the broker doesn't get return receipt.
c. How is this handled in human side?
3. Asteris
a. Offer to provide web services code -
4. Elements
a. Delivery framework
i. Bidirectional HTTP PUT
1. No polling
2. Both servers have to have firewall HTTP ports open
ii. Submit / poll
1. Requires authentication for each transaction
2. Only report server has to have HTTP ports open
b. Request structure
c. Request Content
5. Scope
a. Two options:
i. Server->Server only
ii. Client <-> Server
6. Topics for next week
a. Stabilize scope and identify actors
b. Identify requirements for communication within the defined scope
--Dennis
Aerik Sylvan
1. Last time: VRRS Broker
a. Analogous design to internet mail, but using HTTP instead of SMTP
b. Providers and consumers all communicate directly with application brokers that have resolvable internet addresses.
c. How would a new broker become known to the other brokers?
-> Same as b./a. : user addresses are similar to email and brokers (servers) are resolvable addresses (eg, "ae...@vrrsbroker.vetrocket.net") so brokers don't need to have foreknowledge of other brokers.
d. Question about identity verification - how do you ensure that the message really came from the server it claims to be from?
-> Suggestion: DNS lookup for originating broker, compare to calling IP address. Could even go farther and make a webservice call (either SOAP or REST) back to originating broker to confirm.
e. Is there a nonrepudiation process to ensure receipt and completeness of a transmission?
-> Suggestion: MD5 hash of the message body (do a checksum). There is an HTTP header for this already.
2. Questions
a. How to add broker to network?
-> Same as 1c above?
b. Return receipt
-> Is the questino about a return receipt all the way down to the client, or merely to the client's server? All the way to the client may be difficult, but to the client's server is easy.
--
You received this message because you are subscribed to the Google Groups "Veterinary Radiology Report Integration Work Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vrrs+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
YorkTechSolutions-GMail
Dennis, I’m available at 9a PDT tomorrow if you’re still looking to have the call at that time.
Evelyn
--
Dennis Ballance
My apologies all, but the notice is too short to schedule this effectively this week. I will schedule a make-up meeting for the week after next.
--Dennis
Dennis Ballance
2b – the question would be server-to-server.
Since we have to delay a couple weeks for the next meeting, I’d like to continue the discussion this way.
As Mike noted, limited scope is an important part of successful standards design. As such, I propose the following requirements be the extent of the scope for this phase of the project:
· Ability to transmit a request from one server (broker) to another.
· Ability to transmit a report from one server (broker) to another.
Expectations:
· The server (broker) will be responsible for communicating to its end users (hospitals, specialists, etc).
I believe that, except for the POC that VetRocket put together, no existing solution provides this functionality out of the box. Please correct me if I am wrong. I note that it is currently possible for one broker to masquerade as a hospital or specialist in order to send and receive data on behalf of that hospital or specialist, but that doesn’t really solve the problem (eg the masquerading broker would have to make numerous queries in order to retrieve data for all of its clients).
Note that I have not stipulated in the above requirements that the solution necessarily be PUT vs GET – use of the word “transmit” should not be read to imply PUT. That layer of detail is something we can get into once we are comfortable with the scope.
Incidentally, I was directed to Mirth, which is an open source standards interface engine. Mirth may in effect encapsulate much of the functionality we are discussing here, without the need to design a new protocol. Please take a look at Mirth and tell us what you think.
--Dennis
Michael Martin
I looked into Mirth briefly a few years ago. It is a fairly capable and flexible interface engine. It is used to implement a protocol you develop or adopt. Your group will still have to define all the specifics of your protocol. Mirth just makes it lots easier to implement than starting with a raw application server (or raw sockets code in C anyone?).
Mike
From: vr...@googlegroups.com [mailto:vr...@googlegroups.com]
On Behalf Of Dennis Ballance
Sent: Friday, May 31, 2013 3:58 PM
To: vr...@googlegroups.com
Subject: RE: [VRRS] Next meeting
2b – the question would be server-to-server.
Stuart Turner
In a large biosurveillance project (human) we deployed the leading commercial alternative to Mirth (Orion Rhapsody). The cost was approximately $25,000/license for each instance/server for a total of about $60,000 per implementation (e.g. coding LOINC/SNOMED, configuration, remote management). Multiply that by every hospital, public health and commercial laboratory. The biggest challenge at the time, despite stating the obvious intractable sustainability these costs would incur to a public health project with no business model, was even acceptance of an open source solution by state and federal agencies.
Mirth is commercial open source. They charge for support and training and sales of their appliances. Their Pico appliance is one example of a low-cost edge server than can be deployed at each clinic/institution. They are an important contributor to the healthcare open source community. As co-PI of the Open Enterprise Master Patient Index project (OpenEMPI), with code contributed by Los Alamos, we contributed a reified open source stack of OpenEMPI to the Open Source Health Tools Project. Mirth now has a Mirth Match component for entity disambiguation or master-patient indexing. Mirth Results and Mirth Connect are most relevant to this discussion.
As Mike points out, this is a well established toolkit, that is conformant to many existing open standards, but can be deployed and used for point-to-point or federated HIE solutions.
VRRS, as a draft standard designed to provide a logical and "implementable" specification, but not an implemented one, should persist an agnosticism to a specific "implemented" technology solution IMHO. What's missing in this discussion and as Mike eludes to, is that many of these exchange needs are cross-cutting across most domains (imaging, laboratory, structured documents, public health reporting, etc.) and as a community we should be working concurrently on policy as well the information and behavioral models and the conformance assertions that a specific technology provider should make such as nonrepudiation, privacy and confidentiality (requirements for encryption in transit, at rest and privacy assertions stated explicitly in the semantics of exchanged messages or documents) and so on.
I encourage the discussions and offers and opportunities for sharing specific products by those already on this list. There can be more than one solution, as long as there is consensus and conformance to a set of requirements, that we have yet to firmly establish. My experience has been in human HIE, so with that bias in mind, I would look at Mirth for any specific implementation and in the spirit of the open source community, would love to see the veterinary community contribute to extensions to enhance this product first before starting anew, especially if a given solution is nascent with more limited implementations and evaluation.
If there is interest, I can possibly introduce someone from Mirth to talk or someone who has used Mirth in RHIO/NHIN projects in the US.
~ Stuart
Aerik Sylvan
Stuart Turner
On Jun 6, 2013, at 10:03 AM, Aerik Sylvan wrote:
> I think we should avoid discussion of specific implementation technologies (Mirth, or C# / IIS, or Weblogic, or anything like that) and instead just try to define a scope and desired feature set. With a target feature set, it should be relatively simple to evaluate proposed protocols (not implementations or technologies, just protocols and specifications).
I could not agree more.
~ Stuart