C-CDA was created because they do not know openEHR? :)
Great input, thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 20 Jan 2015 10:42:54 +0800 From: edwin_ue...@163.com To: openehr-technical at lists.openehr.org Subject: Re:C-CDA was created because they do not know openEHR? :) Dear sir, let me share a litttle thought of mine about this CCDA thing dating back to 2000, CDA is created and used in some places in USA and in 2005 it is evoved to Release 2, in that time ,there is not only one CDA for the clinical document representation in USA,for some continuity of care and specially for patient transfer between different facilities there is a standard named CCR, after some kinds of fighting,they all agreed to use CDA as the basic format or model to solve the continuity of care problem ,which became the most widely used across the whole world CCD(Continuity of Care Document) in 2007,in this CCD they defined different kinds of templates for vital signs and chief complaint and so on.after then IHE,HITSP and HL7 they create a bunch of other IG for different use cases, for example public health section .these all existing IGs contain a number of templates(section level and entry level ) inherit the constraints defined in the original CCD standards and inconsistency between these templates bring them a new level interoperability problem.in order to solve this mess they came to the idea to create a unified template library based on these efforts these SDO and agency have done. at last I want to say maybe CDA is not that widely used across the world,openEHR is definitely less. kind regards -- ???15901958021 At 2015-01-20 10:19:24, pablo pazos pazospablo at hotmail.com wrote: Just for the sake of discussion, See slides 22 and 23: http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertification.pdf As disparate SDOs (HL7, IHE, HITSP, etc.) developed CDA IGs, multiple approaches for documenting template requirements began to diverge threatening interoperability? IG = Implementation Guide So my wild guess is they created a new artifact with the same problems the current artifacts have, like the need for an IG, instead of doing a little research and find a better solution like using archetypes to model and consolidate CDA templates. Does anyone know more about CCDA? Do you think this is a good area of work for openEHR in the US? I mean, maybe we (as a community) can propose an openEHR-based solution or make some kind of statement, for documental consolidation than having another implementation guide + CDA templates. What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://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/20150120/738be8a0/attachment.html
C-CDA was created because they do not know openEHR? :)
There is some work going on t odo mappings between openEHR and C-CDA as part of the EU SemanticHealthNet project but I suspect C-CDA has little future, to be rapidly replaced by FHIR, I think this recent tweet is relevant - The #argonaut project, CCDA on #FHIR at #HL7WGM pic.twitter.com/NoRgffPHHk also http://www.slideshare.net/Furore_com/01-b-from-ccda-to-fhir-grahame 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 20 January 2015 at 03:05, pablo pazos pazospablo at hotmail.com wrote: Great input, thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 20 Jan 2015 10:42:54 +0800 From: edwin_uestc at 163.com To: openehr-technical at lists.openehr.org Subject: Re:C-CDA was created because they do not know openEHR? :) Dear sir, let me share a litttle thought of mine about this CCDA thing dating back to 2000, CDA is created and used in some places in USA and in 2005 it is evoved to Release 2, in that time ,there is not only one CDA for the clinical document representation in USA,for some continuity of care and specially for patient transfer between different facilities there is a standard named CCR, after some kinds of fighting,they all agreed to use CDA as the basic format or model to solve the continuity of care problem ,which became the most widely used across the whole world CCD(Continuity of Care Document) in 2007,in this CCD they defined different kinds of templates for vital signs and chief complaint and so on.after then IHE,HITSP and HL7 they create a bunch of other IG for different use cases, for example public health section .these all existing IGs contain a number of templates(section level and entry level ) inherit the constraints defined in the original CCD standards and inconsistency between these templates bring them a new level interoperability problem.in order to solve this mess they came to the idea to create a unified template library based on these efforts these SDO and agency have done. at last I want to say maybe CDA is not that widely used across the world,openEHR is definitely less. kind regards -- ??? 15901958021 At 2015-01-20 10:19:24, pablo pazos pazospablo at hotmail.com wrote: Just for the sake of discussion, See slides 22 and 23: http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertification.pdf As disparate SDOs (HL7, IHE, HITSP, etc.) developed CDA IGs, multiple approaches for documenting template requirements began to diverge threatening interoperability? IG = Implementation Guide So my wild guess is they created a new artifact with the same problems the current artifacts have, like the need for an IG, instead of doing a little research and find a better solution like using archetypes to model and consolidate CDA templates. Does anyone know more about CCDA? Do you think this is a good area of work for openEHR in the US? I mean, maybe we (as a community) can propose an openEHR-based solution or make some kind of statement, for documental consolidation than having another implementation guide + CDA templates. What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com ___ 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
CRUD Restlet
Hi Thomas, The interesting question is: what style of service should be used for e-health business entities, like active care plans, managed medication lists, and order management, which all need much more complex APIs than just 'get'? FHIR is not designed for this kind of thing, and it's questionable whether REST is either. REST is more than just using GET to fetch resources. I think most, if not all, use cases can be cleanly and comfortably implemented using a REST style architecture. We did some work on care plans and medication lists but I did not found anything which would not fit the REST style architecture. What kind of use case do you think is too complex for or does not fit a REST architecture ? The APIs in these cases need to be carefully designed, and could easily be stateful / session-oriented - But following the REST architectural style does not mean you can't have a state. All clients have state, you just can't store this state on the server, you keep the state on the client. Same goes for sessions, you can still have sessions when using REST, you just don't store them on the server but on the client. especially if they manage a shared resource that multiple agents may try to update simultaneously. HTTP has pretty good standard methods for managing simultaneous updates of the same resource. Like the HTTP PATCH method, JSON patch documents and conditional requests. They all work without having to keep state on the server. I would say these techniques makes it much easier to do concurrent requests on the same resource, even when the requests are handled by multiple servers at the same time. In any case, I don't see statefulness or not as the decider on what kind of protocol you want; structure is a bigger decider. I think it's easy to fall into the trap of thinking a single latest / fashionable protocol is good for all layers of a complex architecture. REST is not about the protocol. REST is an architectural style which is commonly implemented using the HTTP protocol. You can use any protocol you want, including SOAP and binary RPC, and still call it REST. You are correct in that if the structure of an application does not fit the REST style architecture, there are much better protocols than REST over HTTP to communicate with it. But we did not looked at our application and then thought about putting some REST API on top of that. We certainly did not choose REST because it is the 'latest/fashionable protocol' or 'hey, let's do what everyone else is doing'. We started from the other end: we looked at what is the most convenient way for (web) frontend developers to use our API. Because in the end the most important thing is how easy/quickly can someone create an user interface on top of our API. Currently that means using the HTTP protocol and JSON documents. Then we spend quite a bit of effort to determine which architectural style would fit our use cases best and we choose REST. We also made sure the REST architectural style is implemented all the way throughout our applications instead of just having a small 'REST' like API layer on top of something which does not fit REST very well. REST is more than just a small protocol layer for accessing a service. Further we are not trying to build a huge complex architecture but we try to keep things small and manageable with many small services which 'do one thing and do them well'. By doing that we did not encounter anything too complex. Everything is split into small, self sustained, easily manageable and solvable pieces. I would almost say health care is not that complex after all... :-) Ralph. MedVision360 -- This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.
C-CDA was created because they do not know openEHR? :)
anaesthetics etc, most of our data here are structured - how do we use CDA?' The speaker replied that 'CDA wasn't really designed for such use'. Now, it has been used in the UK for some structured data, but it's expensive to make it work, and I suspect it won't survive, because our main use case here isn't transmitting narrative hospital notes / summaries - we have vastly more structure in GP data for example. So I suspect CDA won't find much use in the long run here in the UK, and I think in Europe it won't be a dominant approach either. FHIR will start taking care of resource-level provision of health data to apps. The FHIR team are doing a great job on sorting out aspects of how to actually make REST work for health data - exactly the scenarios discussed on the other thread. But there remains the question of building all the FHIR resources and profiles, in a sustainable way. Apart from that, we are still in the business of building other kinds of interoperability - services for major hospital applications like medication management, care plans, and so on. doing this properly requires a different approach than just resources. - thomas ___ openEHR-implementers mailing list openEHR-implementers at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150120/3deba37b/attachment.html
openEHR-technical Digest, Vol 35, Issue 33
solution like using archetypes to model and consolidate CDA templates. Does anyone know more about CCDA? Do you think this is a good area of work for openEHR in the US? I mean, maybe we (as a community) can propose an openEHR-based solution or make some kind of statement, for documental consolidation than having another implementation guide + CDA templates. What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/atta chments/20150120/738be8a0/attachment-0001.html -- Message: 2 Date: Tue, 20 Jan 2015 07:54:25 + From: Ian McNicoll ian.mcnic...@oceaninformatics.com To: For openEHR technical discussions openehr-technical at lists.openehr.org Subject: Re: C-CDA was created because they do not know openEHR? :) Message-ID: CAG-n1KwVoy9=Vfu54jgQc2hQPRsG+5BSobf4Ve7ZQdSOFDGhZg at mail.gmail.com Content-Type: text/plain; charset=UTF-8 There is some work going on t odo mappings between openEHR and C-CDA as part of the EU SemanticHealthNet project but I suspect C-CDA has little future, to be rapidly replaced by FHIR, I think this recent tweet is relevant - The #argonaut project, CCDA on #FHIR at #HL7WGM pic.twitter.com/NoRgffPHHk also http://www.slideshare.net/Furore_com/01-b-from-ccda-to-fhir-grahame 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 20 January 2015 at 03:05, pablo pazos pazospablo at hotmail.com wrote: Great input, thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 20 Jan 2015 10:42:54 +0800 From: edwin_uestc at 163.com To: openehr-technical at lists.openehr.org Subject: Re:C-CDA was created because they do not know openEHR? :) Dear sir, let me share a litttle thought of mine about this CCDA thing dating back to 2000, CDA is created and used in some places in USA and in 2005 it is evoved to Release 2, in that time ,there is not only one CDA for the clinical document representation in USA,for some continuity of care and specially for patient transfer between different facilities there is a standard named CCR, after some kinds of fighting,they all agreed to use CDA as the basic format or model to solve the continuity of care problem ,which became the most widely used across the whole world CCD(Continuity of Care Document) in 2007,in this CCD they defined different kinds of templates for vital signs and chief complaint and so on.after then IHE,HITSP and HL7 they create a bunch of other IG for different use cases, for example public health section .these all existing IGs contain a number of templates(section level and entry level ) inherit the constraints defined in the original CCD standards and inconsistency between these templates bring them a new level interoperability problem.in order to solve this mess they came to the idea to create a unified template library based on these efforts these SDO and agency have done. at last I want to say maybe CDA is not that widely used across the world,openEHR is definitely less. kind regards -- ??? 15901958021 At 2015-01-20 10:19:24, pablo pazos pazospablo at hotmail.com wrote: Just for the sake of discussion, See slides 22 and 23: http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertifica tion.pdf As disparate SDOs (HL7, IHE, HITSP, etc.) developed CDA IGs, multiple approaches for documenting template requirements began to diverge threatening interoperability? IG = Implementation Guide So my wild guess is they created a new artifact with the same problems the current artifacts have, like the need for an IG, instead of doing a little research and find a better solution like using archetypes to model and consolidate CDA templates. Does anyone know more about CCDA? Do you think this is a good area of work for openEHR in the US? I mean, maybe we (as a community) can propose an openEHR-based solution or make some kind of statement, for documental consolidation than having another implementation guide + CDA templates. What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com ___ openEHR-technical
openEHR-technical Digest, Vol 35, Issue 33
HI William, I know for a fact that archetype-based CDAs do/did exist, because Ocean built them for Nehta (not many though, it's not that easy to do it). However, Nehta is notoriously sensitive with IP, and may well have refused them to be made public. I have also seen some other technical solutions, something like proof-of-concept level solutions with CDA containing archetyped data; none of these was operationalised (it was done in Aus and UK). I have no idea if any of these are alive today, or even relevant. So at a practical level, you may be right ;-) I suspect the only place to get any serious CDA templates at all is MDHT / VHA. I have no idea on the current status there though. By the way, in case you are interested, we will have single-file ADL 2 templates demonstrable in the next ADL Workbench, and I will post some early information / screen shots here imminently. - thomas On 20/01/2015 16:27, William Goossen wrote: Someone in the OpenEHR world created a nice CDA that uses archetypes. It was presented at several meetings in the HL7 space, in particular in the patient care workgroup. However, it was a powerpoint. The HL7 people asked for the ppt, but that was never delivered. The HL7 people asked the openEHR example of CDA with archetypes, but that was never delivered. So the solution was told to be exist (CDA filled with archetypes), but not made available. So it in fact does not exist. The world of CDA around the world talks a lot about templates. In all IGs there are specs how such a template should / would look. But after 15 years since the conceptualization of HL7 templates, these are non existent. (I mean not findable even to insiders).
openEHR-technical Digest, Vol 35, Issue 33
less. kind regards -- ???15901958021 At 2015-01-20 10:19:24, pablo pazos pazospablo at hotmail.com wrote: Just for the sake of discussion, See slides 22 and 23: http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertifica tion.pdf As disparate SDOs (HL7, IHE, HITSP, etc.) developed CDA IGs, multiple approaches for documenting template requirements began to diverge threatening interoperability? IG = Implementation Guide So my wild guess is they created a new artifact with the same problems the current artifacts have, like the need for an IG, instead of doing a little research and find a better solution like using archetypes to model and consolidate CDA templates. Does anyone know more about CCDA? Do you think this is a good area of work for openEHR in the US? I mean, maybe we (as a community) can propose an openEHR-based solution or make some kind of statement, for documental consolidation than having another implementation guide + CDA templates. What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/atta chments/20150120/738be8a0/attachment-0001.html -- Message: 2 Date: Tue, 20 Jan 2015 07:54:25 + From: Ian McNicoll ian.mcnicoll at oceaninformatics.com To: For openEHR technical discussions openehr-technical at lists.openehr.org Subject: Re: C-CDA was created because they do not know openEHR? :) Message-ID: CAG-n1KwVoy9=Vfu54jgQc2hQPRsG+5BSobf4Ve7ZQdSOFDGhZg at mail.gmail.com Content-Type: text/plain; charset=UTF-8 There is some work going on t odo mappings between openEHR and C-CDA as part of the EU SemanticHealthNet project but I suspect C-CDA has little future, to be rapidly replaced by FHIR, I think this recent tweet is relevant - The #argonaut project, CCDA on #FHIR at #HL7WGM pic.twitter.com/NoRgffPHHk also http://www.slideshare.net/Furore_com/01-b-from-ccda-to-fhir-grahame 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 20 January 2015 at 03:05, pablo pazos pazospablo at hotmail.com wrote: Great input, thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 20 Jan 2015 10:42:54 +0800 From: edwin_uestc at 163.com To: openehr-technical at lists.openehr.org Subject: Re:C-CDA was created because they do not know openEHR? :) Dear sir, let me share a litttle thought of mine about this CCDA thing dating back to 2000, CDA is created and used in some places in USA and in 2005 it is evoved to Release 2, in that time ,there is not only one CDA for the clinical document representation in USA,for some continuity of care and specially for patient transfer between different facilities there is a standard named CCR, after some kinds of fighting,they all agreed to use CDA as the basic format or model to solve the continuity of care problem ,which became the most widely used across the whole world CCD(Continuity of Care Document) in 2007,in this CCD they defined different kinds of templates for vital signs and chief complaint and so on.after then IHE,HITSP and HL7 they create a bunch of other IG for different use cases, for example public health section .these all existing IGs contain a number of templates(section level and entry level ) inherit the constraints defined in the original CCD standards and inconsistency between these templates bring them a new level interoperability problem.in order to solve this mess they came to the idea to create a unified template library based on these efforts these SDO and agency have done. at last I want to say maybe CDA is not that widely used across the world,openEHR is definitely less. kind regards -- ??? 15901958021 At 2015-01-20 10:19:24, pablo pazos pazospablo at hotmail.com wrote: Just for the sake of discussion, See slides 22 and 23: http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertifica tion.pdf As disparate SDOs (HL7, IHE, HITSP, etc.) developed CDA IGs, multiple approaches for documenting template requirements began to diverge threatening interoperability? IG = Implementation Guide So my wild guess is they created a new artifact with the same problems the current
openEHR-technical Digest, Vol 35, Issue 33
Hi Tom, In fact this was demonstrated at MIE in 2007 and again at least once if not twice at HIC as part of IHE showcase that included storing the result in the GE XDS. Chris Lindop and other HL7 members were involved in the overall showcase so they new it existed for real. This had nothing to do with NEHTA but we certainly discussed with them and they still ask questions every now and then. It is likely that we will be doing thus in a production system in the not to distant future depending in what a receiving system wants to receive. Whenever we have discussed with a customer/vendor the options to use CDA or TDD/openEHR, the later is chosen. If HL7 people asked for it then they asked the wrong people. I guess they didn't really want to know about it. Heath Original Message Subject: Re: openEHR-technical Digest, Vol 35, Issue 33 From: Thomas Beale thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org openehr-technical at lists.openehr.org CC: HI William, I know for a fact that archetype-based CDAs do/did exist, because Ocean built them for Nehta (not many though, it's not that easy to do it). However, Nehta is notoriously sensitive with IP, and may well have refused them to be made public. I have also seen some other technical solutions, something like proof-of-concept level solutions with CDA containing archetyped data; none of these was operationalised (it was done in Aus and UK). I have no idea if any of these are alive today, or even relevant. So at a practical level, you may be right ;-) I suspect the only place to get any serious CDA templates at all is MDHT / VHA. I have no idea on the current status there though. By the way, in case you are interested, we will have single-file ADL 2 templates demonstrable in the next ADL Workbench, and I will post some early information / screen shots here imminently. - thomas On 20/01/2015 16:27, William Goossen wrote: Someone in the OpenEHR world created a nice CDA that uses archetypes. It was presented at several meetings in the HL7 space, in particular in the patient care workgroup. However, it was a powerpoint. The HL7 people asked for the ppt, but that was never delivered. The HL7 people asked the openEHR example of CDA with archetypes, but that was never delivered. So the solution was told to be exist (CDA filled with archetypes), but not made available. So it in fact does not exist. The world of CDA around the world talks a lot about templates. In all IGs there are specs how such a template should / would look. But after 15 years since the conceptualization of HL7 templates, these are non existent. (I mean not findable even to insiders). ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://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/20150120/cca21d89/attachment.html
CRUD Restlet
I too have looked how the approach used by FHIR could be applied generically to openEHR, but at the entry level using TDDs. I actually went up one level and considered the principals of the HL7-OMG RLUS specification, which is the logical basis of FHIR before they hard coded the resources. RLUS also has a SOAP based interface. The spec I wrote for this is being consider for implementation by three vendors as part of a single project, they chose the SOAP binding rather than REST (REST is not for everyone). Will be interesting if it happens. Regards Heath On 19 Jan 2015, at 9:00 pm, Diego Bosc? yampeku at gmail.com wrote: 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. ___
CRUD Restlet
The approach I took with my FHIR like API was to have a named query with know parameters and result columns. This could be registered internally using AQL or hard coded. This all comes from FHIR principles as they allow registering queries and then executing them. Regards Heath On 20 Jan 2015, at 7:39 am, Thomas Beale thomas.beale at oceaninformatics.commailto:thomas.beale at oceaninformatics.com wrote: On 19/01/2015 21:01, Diego Bosc? wrote: Sad to see that go away, I liked the idea of reusing well known formats for everything. Regarding REST, I assume that nothing stops you to provide a method called query with the actual AQL query as a parameter :D sure - but that forces the app programmer to develop AQL queries. Now, serious programmers and system builders have to do this, but it's not unreasonable to minimise it, especially for common cases, and to help devs who may not be PhDs in openEHR, AQL, archetypes etc. So where can we help them? Well the FHIR approach is trying to hit that kind of sweet spot. The ideal version of FHIR or a FHIR-like approach, that we can work on in openEHR is to be able to generate directly from the archetype model-base FHIR profiles (and probably even some resources). - thomas 2015-01-19 21:58 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.commailto:thomas.beale at oceaninformatics.com: I would agree with Isabel. Not everything is a resource, or should be seen as a resource. If you just want to pull back a lump of data, that could be a 'resource', and for that a REST service based on FHIR or some other API will make sense. Resource-oriented stateless services are suited to some kinds of applications, mostly readers in my view. A service for talking directly to an EHR data store (i.e. a CDR) could be designed as a REST service in theory, but it's not that well matched to the kind of service interface of pattern of calls that will be made (especially if distributed queries and commits are to be supported). The interesting question is: what style of service should be used for e-health business entities, like active care plans, managed medication lists, and order management, which all need much more complex APIs than just 'get'? FHIR is not designed for this kind of thing, and it's questionable whether REST is either. The APIs in these cases need to be carefully designed, and could easily be stateful / session-oriented - especially if they manage a shared resource that multiple agents may try to update simultaneously. In any case, I don't see statefulness or not as the decider on what kind of protocol you want; structure is a bigger decider. I think it's easy to fall into the trap of thinking a single latest / fashionable protocol is good for all layers of a complex architecture. That's very unlikely to be true. I see no problem with an complete solution having REST, SOAP, binary RPC and other kinds of interfaces. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.orgmailto:openEHR-technical at lists.openehr.org http://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/20150120/38f42ffa/attachment-0001.html
CRUD Restlet
Hi Heath, I follow a similar approach on EHRServer with some particularities: queries are created using a UI, then stored, and then executed from clients using the UID of the query (instead of the name). There is a REST endpoint that allow clients to list all the queries available on the server, then execute one. In the near future we will add some authorization filters so the query list will return just the queries each specific client can use. Also importing/exporting queries will be in place by UI and by a REST endpoint. -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: heath.fran...@oceaninformatics.com To: openehr-technical at lists.openehr.org CC: openehr-technical at lists.openehr.org Subject: Re: CRUD Restlet Date: Tue, 20 Jan 2015 22:30:47 + The approach I took with my FHIR like API was to have a named query with know parameters and result columns. This could be registered internally using AQL or hard coded. This all comes from FHIR principles as they allow registering queries and then executing them. Regards Heath On 20 Jan 2015, at 7:39 am, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 19/01/2015 21:01, Diego Bosc? wrote: Sad to see that go away, I liked the idea of reusing well known formats for everything. Regarding REST, I assume that nothing stops you to provide a method called query with the actual AQL query as a parameter :D sure - but that forces the app programmer to develop AQL queries. Now, serious programmers and system builders have to do this, but it's not unreasonable to minimise it, especially for common cases, and to help devs who may not be PhDs in openEHR, AQL, archetypes etc. So where can we help them? Well the FHIR approach is trying to hit that kind of sweet spot. The ideal version of FHIR or a FHIR-like approach, that we can work on in openEHR is to be able to generate directly from the archetype model-base FHIR profiles (and probably even some resources). - thomas 2015-01-19 21:58 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.com: I would agree with Isabel. Not everything is a resource, or should be seen as a resource. If you just want to pull back a lump of data, that could be a 'resource', and for that a REST service based on FHIR or some other API will make sense. Resource-oriented stateless services are suited to some kinds of applications, mostly readers in my view. A service for talking directly to an EHR data store (i.e. a CDR) could be designed as a REST service in theory, but it's not that well matched to the kind of service interface of pattern of calls that will be made (especially if distributed queries and commits are to be supported). The interesting question is: what style of service should be used for e-health business entities, like active care plans, managed medication lists, and order management, which all need much more complex APIs than just 'get'? FHIR is not designed for this kind of thing, and it's questionable whether REST is either. The APIs in these cases need to be carefully designed, and could easily be stateful / session-oriented - especially if they manage a shared resource that multiple agents may try to update simultaneously. In any case, I don't see statefulness or not as the decider on what kind of protocol you want; structure is a bigger decider. I think it's easy to fall into the trap of thinking a single latest / fashionable protocol is good for all layers of a complex architecture. That's very unlikely to be true. I see no problem with an complete solution having REST, SOAP, binary RPC and other kinds of interfaces. - thomas ___ 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150120/14e410aa/attachment.html
