Hi Seref, You are of course correct that FHIR or any other RESTful approaches may struggle in more complex scenarios but I think there is increasing evidence that simpler approaches can bring immense benefit and are an order of magnitude easier to implement for non-specialist developers.
In the UK, FHIR is rapidly becoming the de-facto Industry standard for GP system interfaces butt here is strong recognition that the clinical content development/ maintenance is not going to scale, which is why openEHR has now been picked up (again) by the NHS. I think the openEHR implementer community has a huge opportunity to show how it can play very effectively in this emerging space. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 19 January 2015 at 10:25, Seref Arikan <serefarikan at kurumsalteknoloji.com> wrote: > I've managed not to respond for some time but this discussion got to a point > where I can't help commenting :) > > REST is a fact of the industry, due to whatever mysterious dynamics that > pushes various solutions down our throat as we get old in front of our > computers. So we live with it. > > This does not change the fact that trying to push complex shaped objects > through a few holes shaped as a rectangle, circle and a triangle will leave > some parts of those objects broken. Then we have people discussing for ages > what the right verb mapping would be for an operation. If you try to express > an infinite number of API calls and their semantics with a bunch of HTTP > operations and status codes, this is what you get. > > REST may make things easy for some use cases, but do complex use cases in > healthcare fall into that category? I should probably look at Erik's > research at one point but my dislike for being forced to express semantics > with a very limited number of some text transfer protocol based concepts > will not go away. > > Best regards > Seref > > > On Mon, Jan 19, 2015 at 5:59 AM, Bert Verhees <bert.verhees at rosa.nl> wrote: >> >> I checked on how the large companies like Google, Amazon, PayPal, github >> do it. >> >> They all have a hybrid solution. They all use an own error schema was >> verbal terms, sometimes hierarchical, and they all map their errors to the >> http numerical status schema. >> >> This means that a query with no result is qualified as a 404 error. >> However this seems unlogical to me, is that how the big guys it do. It is >> the same error which is fired when you try to call a non existing method. >> But the accompanying message is different. >> >> It is difficult for me to qualify a query which has no result as an error. >> Have you ever been sick? No? That is a 404 error. >> >> But on the other hand, that is how the big guys do it. >> >> Bert >> >> Op maandag 19 januari 2015 heeft Bert Verhees <bert.verhees at rosa.nl> het >> volgende geschreven: >> >>> Ok, you are right, but http is a very generic application layer, not to >>> designed to serve specific application needs, but designed to serve web >>> servers which only serve documents. >>> As you know, a web server is a very generic application, which, from the >>> time Http was designed, was only recource driven. >>> >>> Maybe the error is that Rest uses a generic application layer which is >>> defined as a resource driven application layer, but in fact Rest is used as >>> a service oriented application protocol. I think that an OpenEhr kernel, or >>> PayPal-service, or many other Rest using applications are also service >>> oriented, not only resource oriented, and that therefor, a resource oriented >>> error handling is unable to serve the needs of a service oriented >>> application. >>> >>> You could call that misusing http, because it was not designed for that, >>> but on the other hand, with some new thinking, Http can be used to serve a >>> service oriented architecture. Or do you not agree with this statement? >>> >>> By the way, nowhere is written that Rest must use the Http status >>> mechanism for communicating application needs. It is written that Rest must >>> used http statuses for http-needs, and Restlet does do that. >>> >>> best regards >>> Bert >>> >>> Op maandag 19 januari 2015 heeft Peter Gummer >>> <peter.gummer at oceaninformatics.com> het volgende geschreven: >>>> >>>> Bert Verhees wrote: >>>> >>>>> The point for me is separation of transport layer and application >>>>> layer, and each domain has its own errorhandling. >>>> >>>> >>>> >>>> Hi Bert, >>>> >>>> HTTP is not a transport layer protocol: >>>> >>>> http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol >>>> >>>> ?The Hypertext Transfer Protocol (HTTP) is an application protocol ?" >>>> >>>> Thanks for the discussion, though. I?ve learned a lot from it. >>>> >>>> Peter >>> >>> >>> >>> -- >>> This e-mail message is intended exclusively for the addressee(s). >>> Please inform us immediately if you are not the addressee. >>> >> >> >> -- >> This e-mail message is intended exclusively for the addressee(s). >> Please inform us immediately if you are not the addressee. >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
