@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
