This is really interesting James. Good write-up on your blog. I think an idea like this holds a lot of promise but it really depends on how it is implemented. The question is: will HTTP be just the transport or will its features be used to the full? For example, SOAP treats HTTP like a cab driver: 'Take me where I want to go but don't talk to me.' It coerces basically everything to a POST, has its own status codes, etc.
So in this case would this new standard take into account using the full array of HTTP status codes or would everything be funneled to a 200 or a 500 with internal error info? What about using the four (at minimum) main HTTP methods? What about safety and idempotence? Rahul mentioned REST. Would there really be a RESTful approach based on running methods against resources (i.e. Patients, Providers) or would it be like SOAP, namely RPC over HTTP? (That seemed to be the way James was leaning in his write-up). If a RESTful approach were desired, would some sort of HATEOS be implemented with a hypermedia system to link from one resource to the next. Keep in mind my experience with HL7 is limited (just getting started with my first HL7 interface) so it's hard for me to wrap my head around the scenarios that others on this list are probably really familiar with and how those scenarios relate to HTTP not just as a transport but as a protocol (i.e. The HTTP RFC). I guess my point is if the idea is HTTP just as a transport and building another envelope inside HTTP (like SOAP did) then that's fine but then one would have to stay away from all the RESTful constraints because they just wouldn't fit. On the other hand if the desire is to really use HTTP as a protocol (the whole enchilada as they say) then the first step is to study the HTTP RFC and RESTful constraints and see if/how those might fit into HL7 interfaces and workflows. -- Paul Morris, Software Developer Northwestern Memorial Physicians Group<http://www.nmpg.com> 773.469.4330 | 312.926.6674 | pmor...@nmh.org From: Rahul Somasunderam <r...@certifydatasystems.com<mailto:r...@certifydatasystems.com>> Date: Monday, July 23, 2012 11:51 AM To: James Agnew <ja...@jamesagnew.ca<mailto:ja...@jamesagnew.ca>> Cc: HAPI Devel List <hl7api-devel@lists.sourceforge.net<mailto:hl7api-devel@lists.sourceforge.net>> Subject: Re: [HAPI-devel] Replacing MLLP I would love that (HTTP/RESTish). That makes a lot of things easier. Add to the list of benefits, Load Balancing. We don't need a new protocol. We need to use a protocol that is widely used so we can reuse all the good stuff we've already got that works. I had read sometime back that someone was implementing a similar technique in Australia. The downside to it is a lot of vendors I deal with live in the 19th century, and might not start supporting this for several years from now. But a push for HTTP in HL7 from HAPI would be the right thing for healthcare. R, rahul On Jul 23, 2012, at 8:20 AM, James Agnew wrote: Hi All, I'd like to solicit opinions on something I've been thinking over for a while now. I'm wondering if there is any interest or opinions in the HAPI community to come up with a new transport for HL7 messages that can be used in place of the (horribly outdated) Minimal LowerLayerProtocol. I've got a blog post up (sorry for the blog-link email, it's just an easier way to include pictures and things than email) http://onintegration.blogspot.ca/2012/07/a-call-for-new-hl7-v2-transport-hl7.html which outlines a proposal to implement an HTTP based transport. I would love to hear opinions on the idea, counter proposals, criticisms, etc. Cheers, James ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Hl7api-devel mailing list Hl7api-devel@lists.sourceforge.net<mailto:Hl7api-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/hl7api-devel This message and any included attachments are intended only for the addressee. The information contained in this message is confidential and may constitute proprietary or non-public information under international, federal, or state laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Hl7api-devel mailing list Hl7api-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hl7api-devel
