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
On Mon, Jul 23, 2012 at 3:57 PM, Moehrke, John (GE Healthcare) <
john.moeh...@med.ge.com> wrote:
> I will note that the FHIR initiative is exactly in reaction to the issues
> you mention about HL7 v3. There is very strong emotion behind this. There
> is very strong interest, as you all know well. What you see as to the
> history is completely within Australia, by Grahame. It has just now been
> brought to HL7. ****
>
> ** **
>
> http://www.healthintersections.com.au/?p=502****
>
> ** **
>
> It has lots of interest. I would encourage you all to jump on board. The
> more highly motivated people the better. I could see a HAPI implementation
> of FHIR being a great way to move this ahead faster. Deviations from FHIR,
> or alternatives, will only cause slowness. That is not to say that HAPI or
> any individual on this mailing list should just fall inline with FHIR. What
> this means is get involve and move FHIR in the proper direction, where
> proper is defined by the largest sub-set of the community that is
> interested. Meaning participation will drive it far and fast. HAPI is a
> fantastic open ****
>
> ** **
>
> John****
>
> ** **
>
> *From:* Erik Gfesser [mailto:egfes...@gmail.com]
> *Sent:* Monday, July 23, 2012 2:44 PM
> *To:* Morris, Paul
> *Cc:* Moehrke, John (GE Healthcare); Rahul Somasunderam; James Agnew;
> HAPI Devel List
>
> *Subject:* Re: [HAPI-devel] Replacing MLLP****
>
> ** **
>
> John, I second the thanks. Paul, for what it's worth, progress of HL7
> specifications tend to move along rather slowly. For example, work on HL7
> version 3 (an XML-based implementation of HL7) started in 1995, but from
> what I understand has yet to be fully completed, and adoption of
> preliminary releases has been slow because so many healthcare organizations
> have already standardized on HL7 version 2.x.
>
> Erik
>
> http://www.erikgfesser.com
>
> ****
>
> On Mon, Jul 23, 2012 at 1:26 PM, Morris, Paul <pmor...@nmh.org> wrote:****
>
> Well FHIR pretty much addresses all the issues I mentioned. Looks like
> this has been kicked around for quite some time - even though the project
> is 0.0.5, there is a lot of info on implementation of RESTful design
> patterns, etc. even Atom feed integration.
>
> Thanks for sharing John.
> --
> Paul Morris, Software Developer
> Northwestern Memorial Physicians Group<http://www.nmpg.com>
> 773.469.4330 | 312.926.6674 | pmor...@nmh.org
>
>
> From: <Moehrke>, "John (GE Healthcare)" <john.moeh...@med.ge.com<mailto:
> john.moeh...@med.ge.com>>
> Date: Monday, July 23, 2012 12:13 PM
> To: Rahul Somasunderam <r...@certifydatasystems.com<mailto:
> r...@certifydatasystems.com>>, 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
>
> This is now an HL7 initiative called FHIR.
> http://wiki.hl7.org/index.php?title=FHIR
>
> From: Rahul Somasunderam [mailto:r...@certifydatasystems.com]
> Sent: Monday, July 23, 2012 11:52 AM
> To: James Agnew
> Cc: HAPI Devel List
> 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<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________%0AHl7api-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****
>
> ** **
>
------------------------------------------------------------------------------
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
