message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/1b88e832
was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/c5e860c3/attachment.html
message is intended exclusively for the addressee(s). Please
inform us immediately if you are not the addressee.*
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/36813aef
/openehr-technical_lists.openehr.org/attachments/20150119/552b3d55/attachment.html
with AQL directly.
Please if you know where I can find stuff to help me, any pointers
will be very welcome!
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/eae16e59
-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/83947196/attachment.html
-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/a8116c6b/attachment-0001.html
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
--
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/cde7bf6d/attachment.html
--
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/7e854be6/attachment-0001.html
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
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
Hi Alessandro
Very good question. I know that some implementers store 'basic query
demographics' in a single persistent composition with an archetype
representing dob, sex, gender etc, to get around this although it to
some extent weakens the ehr / Demographics split.
One approach I would like
things. They have some pretty cool ideas
for common problems that you can probably reuse (e.g. using atom for
query responses)
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119
://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/0335255e/attachment.html
/20150119/a65aa321/attachment-0001.html
was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/9e1acdc6/attachment.html
Hi,
On 01/19/2015 11:31 AM, Birger Haarbrandt 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.
Thanks. We do our best to make the REST API of MedRecord as simple as
possible. We try to base the
Thanks Ralph
;-)
On 19-01-15 13:10, Ralph van Etten wrote:
Hi,
On 01/19/2015 11:31 AM, Birger Haarbrandt 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.
Thanks. We do our best to make the
Ralph van Etten wrote:
This has lead to our current version of MedRecord (which is still work in
progress) and can be found here:
https://mr.dev.medvision360.org/mr/apidocs/#!/
Hi Ralph,
That link doesn?t work. It displays this:
{error:406,message:The resource identified by the request
://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/27940f9d/attachment.html
Hi Peter,
This has lead to our current version of MedRecord (which is still
work in progress) and can be found here:
https://mr.dev.medvision360.org/mr/apidocs/#!/
Hi Ralph,
That link doesn?t work. It displays this:
{error:406,message:The resource identified by the request is only
Hi Ralph,
Mac OS X 10.9.5 with Safari 7.1.2.
The first time I clicked on the link it asked me for a certificate, which
seemed pointless to give it for API docs so I clicked Cancel. Then it displayed
the error.
On subsequent attempts it goes straight to the error. I guess the browser must
be
Hi,
On 01/19/2015 02:10 PM, Isabel Rom?n Mart?nez wrote:
I do think the REST architecture style is better than most SOAP, CORBA
and ESB solutions
Sounds too categorical to me!! you must study case requirements deeply
and you could not affirm this for every case!!
Sure, but I was talking
Hi Bert,
Thank you for proposing an interesting discussion whether http
response status should be included to API result or not.
I found this similar discussion on stackoverflow.
http://stackoverflow.com/questions/942951/rest-api-error-return-good-practices
I think using response 404 code is
Hi Peter,
Mac OS X 10.9.5 with Safari 7.1.2.
Thanks, I'll look into it.
The first time I clicked on the link it asked me for a certificate,
which seemed pointless to give it for API docs so I clicked Cancel.
Then it displayed the error.
Perhaps you can try the version without SSL?
://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/3cb4117a/attachment.html
--
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/ecb075d4/attachment.html
://wolandscat.net/category/health-informatics/
View Thomas Beale's profile on LinkedIn
http://uk.linkedin.com/in/thomasbeale
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119
-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/331ecc68/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name
Ralph van Etten wrote:
Perhaps you can try the version without SSL?
http://mr.dev.medvision360.org/mr/apidocs/#!/
Yes, Ralph, that version works for me.
Also, for the record, Ralph made the server less strict so that the original
link that he gave us
Rails Multi Table Inheritance, Polymorphic association or Single Table
Inheritance?
I'm trying to implement the OpenEHR reference model in Rails
(ActiveRecord), but I'm finding some problems, since it works with a
lot of different of different classess, ...
/openehr-technical_lists.openehr.org/attachments/20150119/e5aff641/attachment.html
?
--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/2d54f561
34 matches
Mail list logo