X12 EDI Over REST

[Michael Kling]

In the health insurance space X12 EDI is a standard transmission format for HIPAA compliant communications. There are some companies that have built JSON equivalents to EDI, which is great, but there are a large number of companies that would benefit from being able to leverage there existing EDI infrastructure. What are some good ways to handle this in a RESTful service? Custom EDI format in Accept header? Model after RESTful file upload? JSON wrapper for EDI payload? Again it's a given that we could always come up with an equivalent JSON format, but how can we support EDI as a transmission format in a RESTful service.

[Jørn Wildt]

EDI seems like quite a broad topic of which I know zilch beside what I just read on edibasics.com ... is there something special you already have in mind? What does a RESTful service imply for you in this context?

From a very high level perspective EDI is about exchanging standard documents on all sorts of message transport protocols ... FTP, HTTP, SMTP - you name a TLA and they got it. How would you expect EDI to benefit from implementing "REST" - what ever it means in this context?

REST is about about identifying and transfering resources (states). Could EDI documents be resources? Can you identify such documents with URLs and GET them with HTTP? Can you embed links in such documents and would it make sense? Can clients modify documents on servers - or do EDI only reason about transportation of documents?

/Jørn

Den tirsdag den 31. marts 2015 skrev Michael Kling <mike.s...@gmail.com>:

In the health insurance space X12 EDI is a standard transmission format for HIPAA compliant communications. There are some companies that have built JSON equivalents to EDI, which is great, but there are a large number of companies that would benefit from being able to leverage there existing EDI infrastructure. What are some good ways to handle this in a RESTful service? Custom EDI format in Accept header? Model after RESTful file upload? JSON wrapper for EDI payload? Again it's a given that we could always come up with an equivalent JSON format, but how can we support EDI as a transmission format in a RESTful service.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

--
/Jørn

[darrel...@gmail.com]

Michael,

The same media types that were defined to allow EDI documents to be sent over email[1] can be used to return EDI documents over plain old HTTP.

Simply by returning a Content-Type header of application/edi-x12 and the EDI document as the payload will allow you to take advantages of all the benefits of REST.  There is no need to try and treat the EDI document as a file or try and embed it into a JSON wrapper.  It naturally fits very nicely into the standard HTTP model.

Darrel

[1] http://tools.ietf.org/html/rfc1767

Sent from Surface

--

[mca]

the last time i used EDI/HIPAA over the Web (5+ years ago?) it was via XML. There are a number libraries and tools to help this along.

IIRC, most EDI interactions are "file-transfer" style and don't need much interaction information (e.g. no affordances inline).

i suspect, if i was on an EDI project today, i'd be using the "representor"[1] implementation pattern to get clear separation between the internal models and the representation format and then use any of the standard formats for Web client interaction (HAL, Cj, Siren, Mason, UBER, etc.) and offer EDI/EXI-XML in responses for consumers expecting that format.

IOW, treat EDI (or EDI-XML, etc.) as just another format, not a protocol or full-stack implementation constraint.

[1] https://github.com/the-hypermedia-project/charter#representor-pattern

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

[Manoj Agarwal]

Usually when EDI data is transmitted through HTTP, people use AS2 (http://en.wikipedia.org/wiki/AS2).

AS2 defines rules about security, reliability to transmit flat-file EDI data over HTTP.

[darrel...@gmail.com]

Manoj,

Big enterprises fascinate me.  HTTPS is not good enough security, so we need to layer AS2 over the top for added “protection”.  But, hey, if you don't support EDI, it's ok, we can fax you documents or email a PDF.  Or my favorite SAP integration mechanism… fill in the Excel template and upload the Excel file via a HTML form.

The cynic in me says that AS2 was introduced so that the process remained sufficiently complex so that the VANs could stay in business.

Darrel

Sent from Surface

[Jørn Wildt]

> Big enterprises fascinate me.  HTTPS is not good enough security, so we need to layer AS2 over the top for added “protection”.

One argument could be that you get end-to-end security using AS2 - not only transport layer security while transmitting over HTTPS?

But, yes, it is funny that the same company would accept a PDF via e-mail :-)

/Jørn

[Kijana Woodard]

I would make a joke about Heart Bleed, but your point is valid. Email as an alternate transport == LOLOLOL.