Hi Christian,
I think you have a point about using the HTTP statuses as designed. Really
what I wouldn't want to do is replace the traditional HL7 NAK (AE/AR/etc)
messages because that would be a pretty invasive change, but returning (for
instance) a 500 with the v2 NAK in the response body probably meets the
best of both worlds. My one worry would be that implementations might treat
a 500 with a NAK as a pure "throw an exception and die" kind of situation,
where they might have passed the NAK up the chain for processing in the
MLLP world. Maybe the answer to this would be just to stipulate that if the
response comes with an HL7 mime-type, it should be processed by the
application regardless of the HTTP status? I don't know that I like that
approach terribly much either, but I do think that if we're using status
codes we need some way of distinguishing between situations like "the
server is broken right now" or "your credentials were bad" and other kind
of failure like "the message you sent was rejected because of a business
rule in the application and I want to tell you why".
As an added bonus to this approach, things like HTTP governance tools and
firewalls will be all the more productive if they can interpret the HTTP
codes coming through.
In terms of charsets, the ability to explicitly state the encoding seems to
be a huge advantage. I would certainly want the reference implementation to
always do so, and I would be tempted to make any specification either
strongly encourage the same or perhaps require it.
In terms of authentication, I would tend to disagree that HTTP auth doesn't
bring much value. Given that many HL7v2 implementations are sharing data
over private networks within a private data centre, the chances of network
snooping occurring are greatly diminished so even an unencrypted password
brings at least some security benefits. Then, the logical next step is to
secure the communication with SSL/TLS which means that nobody can snoop.
Obviously either of these approaches are possible today with MLLP and a
security token in the message, but this is something we do today out of
necessity and I can't stand it because it forces us to either store the
security token in plain text in our message journals, or to modify messages
before we journal them.
A number of people have very clearly stated "no custom headers" as being
something they feel strongly about (probably because they have also been
burned by SOAP's weird sometimes-required use of custom headers). That
said, I do think there is value in allowing one optional-but-standard
header containing a cryptographic signature of the HL7 message in question.
Many organizations have security policies requiring some kind of symmetric
crypto when talking with partners outside their own walls. This provides an
application-to-application guarantee of non-repudiation.
Certainly this can be accomplished just by using symmetric key TLS right on
the socket, but I have always found that approach hard to manage since it
usually requires JVM/server socket restarts any time a certificate changes
(not optimal if you are supporting 200+ interfaces). Using something like
an MD5/RSA hash in a header within both the request and the response would
be relatively trivial using a library like Bouncycastle and would provide a
nice manageable solution.
Does anyone have any opinions on that?
Overall, it seems like there is a fair bit of interest in this. Ideally,
I'd like to do two things with all of this: hack together a first pass of a
specification (nothing fancy, just a webpage that captures all of the ideas
being bounced around here) to enable more pointed commentary, and bang out
a quick reference implementation. Of course I will post a link as soon as
there is something worth looking at, but if anyone is interested in helping
out that would be great.
I also kind of wonder, would it be a good idea to move this discussion to a
better location than this list? A Google+ page could be an option, for
instance.
Cheers,
James
On Tue, Jul 24, 2012 at 6:21 AM, christian ohr <christian....@icw.de> wrote:
>
> Rest assured that I don't want to make this more complicated as necessary!
> However, when you use existing HTTP tooling and libraries, you have to face
> with what the HTTP standard mandates. And I think it's unresolved conflicts
> and loopholes in a spec that lead to error-prone implementations. I'm not
> interested in introducing redundancies, but when we intend to use HTTP we
> should use it according to the rules!
> The HTTP standard says that the request or response body can be any
> encoding, but by default is ISO-8859-1. If the HL7 message is e.g. UTF-8
> (and says to in MSH-18), you HAVE to set Content-Type to
> "text/plain;charset=UTF-8". (IMHO defining the charset of a message inside
> the message itself is a weird idea anyway).
> The response codes should also be used as intended by the HTTP
> specification. It would probably be enough to differentiate between 200,
> 400
> (it's the client's fault!) and 500 (it's the servers fault!).
> As mentioned, 401 (unauthorized) and 404 (not found) are often returned
> from
> outside the actual business logic anyway. Clients react on 401 by sending
> credentials (if they have not already done so preemptively). We should not
> mess this up.
>
> cheers
> Christian
>
>
>
> Jens Kristian Villadsen wrote:
> >
> > 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
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Replacing-MLLP-tp34200634p34204537.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
>
------------------------------------------------------------------------------
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
