When you talk about 'CDA with archetypes', what do you exactly mean? 1) An example of embedding an archetyped openEHR instance in a CDA document. 2) An example of the use of creating CDA templates equivalent to openEHR archetypes (or vice-versa). 3) An example of CDA templates defined as AOM archetypes using CDA Reference Model.
The last one is how we approached the problem and has been presented in several forums, with several examples already publicly available. 2015-01-20 17:27 GMT+01:00 William Goossen <wgoossen at results4care.nl>: > 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:openehr-technical-bounces at > lists.openehr.org] > 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 <pazospablo at hotmail.com> > 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: 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 > -------------- 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 <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 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 <ralph at medvision360.com> > 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: ??? <edwin_uestc at 163.com> > 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 > ************************************************* > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
