One thing I always felt that openEHR needed was something like a connectathon. I think we have currently a sufficient number of companies and developers involved to start this.
2015-01-19 11:44 GMT+01:00 Ian McNicoll <ian.mcnicoll at oceaninformatics.com>: > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
