If we can reach an agreement I suggest an RFC should be written. In that
way we can maintain our 'MLLP over HTTP wrapping standard' in a document
and not just have a reference implementation.
2012/7/25 Rahul Somasunderam <r...@certifydatasystems.com>
>
> On Jul 24, 2012, at 1:24 PM, James Agnew wrote:
>
> 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 lot of time is wasted because most over the counter EMRs just support
> plain MLLP and don't support MLLP/TLS. So we have to setup SSH tunnels or
> VPNs to get them to securely transmit data. HTTP/TLS will mean that none of
> it is required.
>
>
> 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.
>
>
> You don't really need a restart. JVM allows you to manage keystores using
> code. Bouncycastle can be used to manage client keypairs and trust stores.
> If required that can also be applied to server keys, but a lot of admins
> prefer managing server keys at the apache/nginx level. And that leaves any
> eccentricities out of HTTP. The barrier to start HL7/MLLP for a new
> developer is significantly lower if we do things that almost all developers
> are familiar with.
>
>
> 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.
>
>
> Github please! I know a lot of people voted for git 1.5 years back in a
> survey, but it was shotdown because the most active devs were not
> comfortable with it, but Github has become much easier since then and also
> works well with all platforms.
>
>
> 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
