Interesting remarks Ohr -
I still however favor not mixing HTTP protocol and the MLLP/ER7
protocol/format. In that way, it is much simpler to reach an initial
agreement between multiple vendors and the effort to implement it across
multiple systems. Furthermore, if some values are to be
duplicated/transformed/seeded into the HTTP protocol it introduces a much
more error prone implementation. Also, mapping e.g. error codes down/up to
HTTP response codes besides just using a single error code only introduces
an abstract artificial layer of complexity. IMHO, it is not only redundant,
it is also error prone as long as the error code is maintained in the HL7
message.
2012/7/24 christian ohr <christian....@icw.de>
>
> A few comments from my side:
>
> * to do RESTful communication, you need resources ("state") in the first
> place. That's what FHIR is primarily about (and it definitely should be
> pursued!!). HL7v2 messages are no resources in the strictest sense, so they
> can hardly be communicated RESTfully.
> * So I agree with James: agreeing on a somewhat regulated way to transport
> HL7v2 messags over HTTP does not compete with FHIR in any way or even slow
> its progress.
> * not sure if HTTP is actually much more secure than MLLP.... In order to
> encrypt, sign etc. you need to have SSL over your TCP layer, and you can
> achieve that with MLLP just as with HTTP. IHE ATNA profile mandates use of
> MLLPs, too. HTTP basic authentication is definitely not secure without
> encryption. HTTP digest authentication is a compromise.
> * Yes, there is way more HTTP tooling around (servers, clients, HTTP-based
> load-balancers etc.), and maybe this is the key advantage.
>
> My proposal (based on some experience with customers): Message "requests"
> are simply POSTed and the response code indicates if and how the message
> was
> processed: 200 (OK), 400 (Bad message, e.g. validation failure), 500
> (Internal error while processing). The body contains the response message
> (an acknowledgment or a HL7 response message). No custom HTTP headers.
>
> You certainly have to draw a line when a message is "bad" and when it is
> not. Messages are "bad" when they are either syntactically wrong or they
> somewhere violate some interface profile. Messages may not not be "bad"
> when
> they don't match the state of the receiving application, e.g. when a A40
> merge refers to non-existing patients.
> A few more details would remain to be clarified where HTTP headers may
> conflict with Message Header fields, e.g. how does "Date" relate to MSH-7?
> how does "Content-Type" (particularly the encoding part) relate to MSH-18?
> Furthermore, response codes like 401 (unauthorized) or 404 (not found) are
> often returned by the HL7-unaware HTTP server environment (like a servlet
> container). Would we still want to require a HL7 error message in the
> response body?
>
> cheers
> Christian
>
>
> This is a bunch of very interesting discussion so far! Thanks to everyone
> who has commented.
>
> I definitely don't see this initiative as being in competition with FHIR,
> or even filling the same niche. I've been following FHIR from a distance
> for a little while now, and I really like what I see. Frankly, I'd love to
> see HAPI provide an open-sourced option for implementing FHIR at some
> point, and at UHN we are examining it to see where it might fit. FHIR is
> (from my limited understanding) an entirely new data model and approach to
> interfacing, and will require significant rework to retrofit into existing
> applications. It is undoubtedly capable of being the "way forward" and
> supporting the needs of the next generation of software, but it's less
> likely that legacy vendors are going to invest the effort to adopt it when
> v2 perfectly models the types of transactions that need to be shared within
> hospitals. Putting this a different way, FHIR is a perfect candidate for
> building into our next-generation discharge summary app, but it's much less
> likely to be adopted as a means of copying Reg data from our ADT system
> into our RIS.
>
> At the risk of derailing this thread, I'm still not totally clear on where
> most of the action is with regard to day-to-day FHIR work. If anyone is
> plugged into that and was willing to get in touch I'd be very interested in
> having a chat.
>
> HL7v2 over HTTP is a solution to an entirely different problem: securing
> interfaces that exist today in production. The big problem that those of us
> in the hospital space all share is that our systems talk to each other
> perfectly well (meaning there is little incentive to make disruptive
> changes), but getting them to do it securely is a huge pain.
>
> In terms of the implementation, I see this materializing as fairly RESTful,
> but not in the same way that FHIR means it. Essentially because this is
> just a transport protocol, the REST methods would refer to "interfaces" as
> their business targets as opposed to "patients" or anything else more
> specific.
>
> A POST action would be used to send a message and receive a reply to a
> specific interface, analogous to sending a message to a target using MLLP
> and getting an ACK back. That is probably the only action that would need
> to be implemented, but I could also see a use for a GET action where a
> receiving application could query a sending application for any new
> messages waiting for it. (UHN's primary HIS actually uses a wacky
> connection mode where it will only accept messages to it over an MLLP
> socket connection that it itself initiates, where the sending system acts
> as the TCP server, so HTTP GET would probably fulfill that need)
>
> I think the use of HTTP would probably be very basic (none of SOAP's
> required custom headers, for instance). I would prefer for it to look like
> what Jens called the "simple proposal", where even a rejected transaction
> would return an HTTP 200, with the rejection continuing to be communicated
> within the HL7 ACK message.
>
> Cheers,
> James
>
>
>
> --
> View this message in context:
> http://old.nabble.com/Replacing-MLLP-tp34200634p34204021.html
> Sent from the hl7api-devel mailing list archive at Nabble.com.
>
>
>
> ------------------------------------------------------------------------------
> 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
>
--
Med venlig hilsen / Kind regards
Jens Kristian Villadsen
cand.polyt
Systemudvikler / System developer
Cetrea A/S, Denmark
phone : +45 38 40 05 81
address: Brendstrupgårdsvej 21F, DK-8200 Aarhus N.
e-mail : j...@cetrea.com
w^3 : http://www.cetrea.com/
------------------------------------------------------------------------------
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
