Hi all, I agree with Diego -stay close to FHIR, if only because it will reduce the burden on developers. I think there are some discussions about dropping atom for bundles though.
As well as the Medvision360 api that Birger has pointed to, the crews at Code24 and Ocean/ Lockheed Martin have partially cloned the Ehrscape API, related to the NHS Code4Health project with which I am involved. See https://github.com/handihealth/C4H_dental_challenge/blob/master/README.md#openehr-connectathon-ehrscape-api-endpoints We did not actually get around to doing a connectathon on the day (long story!) but it would be interesting to know how people felt about starting to coalesce an openEHR REST-based service layer, based on the Ehrscape API. As Erik posted earlier, the ability to show cross-platfrom working is hugely important. Ian Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 19 January 2015 at 10:31, Birger Haarbrandt <birger.haarbrandt at plri.de> wrote: > The medrecord openEHR server is also based on REST and worth looking at. > There was a lot to learn from for me as the API is pretty neat. > > Best, > > Birger > > Am 19.01.2015 11:29, schrieb Diego Bosc?: > > I will just add that if you are making a server you probably want to > take a look and how FHIR does things. They have some pretty cool ideas > for common problems that you can probably reuse (e.g. using atom for > query responses) > > 2015-01-19 11:25 GMT+01:00 Seref Arikan <serefarikan at > kurumsalteknoloji.com>: > > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > -- > Birger Haarbrandt, M.Sc. > > Peter L. Reichertz Institut f?r Medizinische Informatik > Technische Universit?t Braunschweig und > Medizinische Hochschule Hannover > M?hlenpfordtstra?e 23 > D-38106 Braunschweig > > T +49 (0)531 391-2129 > F +49 (0)531 391-9502 > birger.haarbrandt at plri.de > http://www.plri.de > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
