That looks correct to me :) Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com twitter: @ianmcnicoll
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 3 April 2016 at 19:20, pablo pazos <pazospa...@hotmail.com> wrote: > @Bert, no worries :) > > @Ian, for now, I'll add a rule like this: > > If committed compo is persistent > If there is no versioned_compo for the root archetype of the committed > compo // this check is new > If change_type == creation // only allows to create one persistent > compo, all other commits should be modifications > create versioned_compo with version v1 > return 200 OK > Else > return 400 Bad Request > Else > If change_type in [amendment, modification] > create new version in existing versioned_compo // this will create v2, > v3, ... > return 200 OK > Else // not considering delete for now, this do not allows to create > another instace v1 for the same persistent compo archetype > return 400 Bad Request > > > For event compos, it just follows the common versioning flow, allowing to > create any number of v1 instances with change_type creation, and version > them using amendment or modification. > > Does this makes sense? If yes, maybe this can help other implementations :) > > -- > Kind regards, > Eng. Pablo Pazos Gutiérrez > http://cabolabs.com > >> From: i...@freshehr.com >> Date: Sun, 3 Apr 2016 11:06:53 +0100 >> Subject: Re: Composition commit and change types >> To: pazospa...@hotmail.com >> CC: openehr-technical@lists.openehr.org > >> >> " I would focus on intra hospital longitudinal lists since it is very >> difficult to reach agreement in the enterprise." >> >> I agree. These decisions are partly technical but largely down to the >> level of commitment/ consensus you can get in your clinical community >> to jointly curate these lists over time. The value of longitudinal >> persistence only accrues if everyone has commitment to the on-going >> curation process and is prepared to work within a common governance >> framework, rights and responsibilities. >> >> http://www.bcs.org/content/conWebDoc/17923 >> >> Ian >> Dr Ian McNicoll >> mobile +44 (0)775 209 7859 >> office +44 (0)1536 414994 >> skype: ianmcnicoll >> email: i...@freshehr.com >> twitter: @ianmcnicoll >> >> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org >> Director, freshEHR Clinical Informatics Ltd. >> Director, HANDIHealth CIC >> Hon. Senior Research Associate, CHIME, UCL >> >> >> On 3 April 2016 at 09:07, pazospa...@hotmail.com <pazospa...@hotmail.com> >> wrote: >> > Good info and the criteria makes sense. >> > >> > >> > I would use episodic for things like hospitalization and treatments that >> > are >> > not a knee time thing (event), maybe with help of folders. Also I would >> > focus on intra hospital longitudinal lists since it is very difficult to >> > reach agreement in the enterprise. And when that time comes, I would >> > just >> > implement a new set of rules for the enterprise :) >> > >> > >> > Thanks! >> > >> > >> > Sent from my LG Mobile >> > >> > ------ Original message------ >> > >> > From: Ian McNicoll >> > >> > Date: Sat, Apr 2, 2016 15:50 >> > >> > To: For openEHR technical discussions; >> > >> > Subject:Re: Composition commit and change types >> > >> > Hi Pablo,When I am advising implementers on this, I use the following >> > categories ...## Composition Commit StylesDepending on the clinical >> > requirement, 3 styles of commit strategy aresuggested.1. **’Event’**e.g >> > Nursing observations, clinical encounters, reports.Each time the >> > composition >> > is committed, create a new instance via a POST.Generally only do a PUT >> > if an >> > error needs to be corrected2. **’Episodic’**Create a new composition via >> > POST for each Period of Care i.e anadmission. If it needs to updated, >> > use a >> > PUT to modify i.e Eachpatient has a single instance per Period of >> > Care.3. >> > **’Longitudinal’**Create a new composition via POST for each patient. If >> > it >> > needs toupdated use a PUT to modify i.e. each patient has only a >> > singleinstance over their lifetime. This will be unusual in a >> > hospitalrecord >> > where there is generally limited ability to curate the patientrecord in >> > this >> > way.So your persistence uses cases are either 2/3. Currently to >> > manageEpisodic persistence, you need ot set the composition category >> > toevent, as the RM currently forces a 'persistent' composition to >> > becontextless i.e. the context attribute is 0...0. This will change inan >> > upcoming RM revision.The decision about when/where to maintain >> > persistent/curated lists isone which will vary between implementations. >> > I >> > would generally expectMedication lists, Allergies and some documents >> > such as >> > Resuscitationpreferences to be maintained as single, persistent >> > instances. >> > AlthoughProblems and Procedures should also probably be maintained that >> > way,there are valid situations where departmental problem lists e.g >> > Renalmedicine have validity.There are strong arguments, at least in UK >> > practice, for maintaining asingle cross-organisation >> > outpatient/community >> > medication record buteach inpatient medication list should be separately >> > maintianed foreach instiution/episode of care.IanDr Ian McNicollmobile >> > +44 >> > (0)775 209 7859office +44 (0)1536 414994skype: ianmcnicollemail: >> > ian@freshehr.comtwitter: @ianmcnicollCo-Chair, openEHR Foundation >> > ian.mcnicoll@openehr.orgDirector, freshEHR Clinical Informatics >> > Ltd.Director, HANDIHealth CICHon. Senior Research Associate, CHIME, >> > UCLOn 2 >> > April 2016 at 06:59, pazospa...@hotmail.com wrote:> Hi all, I'm testing >> > some cases in the EHRServer and I want to confirn some> grey areas.>>> >> > If >> > the EHR receives a commit of a persistent composition and the change >> > type> >> > is creation, should the EHR create a new composition?>>> i.e. I don't >> > see an >> > EHR having two different medication lists, is that> possible?>>> I guess >> > persistent compos can only be created one time per archetype (one> >> > medication list, one problem list, one vaccination list, etc. per >> > patient),> >> > and after the creation, all commits should be modification. Does this >> > make> >> > any sense?>>> If this is OK, to avoid errors from client applications, I >> > would return an> error when a creation is committed for a persistent >> > compo >> > archetype that> already has a conpo instance.>>> And about the first >> > commit. >> > Should, lets say, the medication list be created> when the first >> > medication >> > is recorded or can it be created empty? What do> other implementations >> > out >> > there do?>>> Thanks a lot!>>> >> > _______________________________________________> openEHR-technical >> > mailing >> > list> openEHR-technical@lists.openehr.org> >> > >> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org_______________________________________________openEHR-technical >> > mailing >> > >> > listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
