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 (f
Dear all
I am completely new to HL7. I just understood that there is a widely
implemented v2 flatfile format.
Also I've heard that there is a not so well adopted v3 version around.
Do transformers from v2 to v3 exist? Are they possible over all ? and if not :
where are the differences ?
And if
How about google groups? I think i works great for group conversations
Den 24/07/2012 22.26 skrev "James Agnew" :
> 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 be
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 probab
You got a point there, Ohr - your proposal seems sane, especially about the
encoding part
Den 24/07/2012 12.22 skrev "christian ohr" :
>
> 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
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
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
I also favor not mixing http protocol and the MLLP/ER7 protocol/format. HTTP
should be used just for transport. Positive transport flow should return code
200, anything else should be treated as communication error (i.e. host
unreachable, socket closed).
In aspect of configuring ESB, this approa
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
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 a
This is just an example for a file name - it does not exist anywhere. But you
can take any HL7 message file instead, like this:
https://hl7api.svn.sourceforge.net/svnroot/hl7api/trunk/hapi-mvn/hapi-test/src/test/resources/ca/uhn/hl7v2/parser/adt_a03.txt.
cheers
Christian
Derek Mahar-2 wrote:
>
11 matches
Mail list logo
