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
>
> On Jul 24, 2012, at 1:24 PM, James Agnew wrote:
>
> Hi Christian,
>
> I
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
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
think REST POST should be fine. Maybe JSON with only primitives (String,
List)?
Regards,
Jure Grom
From: Jens Kristian Villadsen [mailto:[email protected]]
Sent: Tuesday, July 24, 2012 10:39 AM
To: christian ohr
Cc: [email protected]
Subject: Re: [HAPI-devel] Re placing MLLP
Interesting
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
10 matches
Mail list logo
