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
[email protected]
https://lists.sourceforge.net/lists/listinfo/hl7api-devel
