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). Met vriendelijke groet / With kind regards, dr. William T.F. Goossen directeur Results 4 Care B.V. De Stinse 15 3823 VM Amersfoort the Netherlands telefoon +31654614458 e-mail: wgoossen at results4care.nl DCMHelpdesk at results4care.eu skype: williamgoossenmobiel kamer van koophandel 32133713 http://www.results4care.nl http://www.results4care.eu http://results4care.wikispaces.com/ http://www.linkedin.com/company/711047 http://results4care.wikispaces.com/3.+Cursussen+Nederlands -----Original Message----- From: openEHR-technical [mailto:[email protected]] On Behalf Of openehr-technical-request at lists.openehr.org Sent: Tuesday, January 20, 2015 09:57 To: openehr-technical at lists.openehr.org Subject: openEHR-technical Digest, Vol 35, Issue 33 Send openEHR-technical mailing list submissions to openehr-technical at lists.openehr.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g or, via email, send a message with subject or body 'help' to openehr-technical-request at lists.openehr.org You can reach the person managing the list at openehr-technical-owner at lists.openehr.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openEHR-technical digest..." Today's Topics: 1. RE: C-CDA was created because they do not know openEHR? :) (pablo pazos) 2. Re: C-CDA was created because they do not know openEHR? :) (Ian McNicoll) 3. Re: CRUD Restlet (Ralph van Etten) 4. Re:Re: CRUD Restlet (???) ---------------------------------------------------------------------- Message: 1 Date: Tue, 20 Jan 2015 00:05:00 -0300 From: pablo pazos <[email protected]> To: openeh technical <openehr-technical at lists.openehr.org> Subject: RE: C-CDA was created because they do not know openEHR? :) Message-ID: <SNT151-W25CFFA0E8D0F2B1F8C372AC84B0 at phx.gbl> Content-Type: text/plain; charset="gb2312" Great input, thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 20 Jan 2015 10:42:54 +0800 From: [email protected] 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 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 +0000 From: Ian McNicoll <[email protected]> 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 mailing > list openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g ------------------------------ Message: 3 Date: Tue, 20 Jan 2015 09:24:17 +0100 From: Ralph van Etten <[email protected]> To: openehr-technical at lists.openehr.org Subject: Re: CRUD Restlet Message-ID: <54BE10B1.9020209 at medvision360.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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. ------------------------------ Message: 4 Date: Tue, 20 Jan 2015 16:56:20 +0800 (CST) From: ??? <[email protected]> To: "For openEHR technical discussions" <openehr-technical at lists.openehr.org> Subject: Re:Re: CRUD Restlet Message-ID: <79e19cbd.23163.14b068e8bd3.Coremail.edwin_uestc at 163.com> Content-Type: text/plain; charset="gbk" Restful webservice is widely used in all kinds of companies in China. especially when the mobile health or mobile internet technology flood all over the wolrd .but there is a thing we should notice these use cases are all in the information exchange or work flow creation inside one company or ecosystem around a company.in my opinion this micro service architecture is quite suitable for building pc applications and mobile applications at the same time based on the cloud computing and container development during these years.our company,one of the leading health information exchange and health information systems vendor are trying to switch to micro service architecture (not alone,also some other paradigm) using Restful webservice to promote the development of mobile application and integration between different products definitely you can still solve everything with old hammer and nails. perhaps more timely and cost-effective. kind regards. -- ??? 15901958021 At 2015-01-20 16:24:17, "Ralph van Etten" <ralph at medvision360.com> wrote: >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. > >_______________________________________________ >openEHR-technical mailing list >openEHR-technical at lists.openehr.org >http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.o rg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/atta chments/20150120/f6b4e89b/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g ------------------------------ End of openEHR-technical Digest, Vol 35, Issue 33 *************************************************
