I thought you had more specific cases :) Having specific lists per clinician was commented by Karsten on a previous message and I commented on that. I'm not sure at which extent that is a backend issue, an API issue or an UI issue. I would say if this is just a display requirement, is more UI related and we need to find ways in the backend to provide the data to address this requirement, independently of if we have or not singleton versioned_compositions per persistent compo archetype.
OT but related: Now this got me thinking about commits. Until now, I was thinking of full composition commits, so if you want to add a medication to a medication list, you need to commit the data in the current version, plus the new entry for the new medication. But what about delta commits? If I didn't changed anything on the current medications, can't I just commit the new medication? Is this possible or somebody implemented something like this? I would think of that as a commit "mode" that applies for amendment and modification change_type, and would allow to log individually added entries, and keep track of whole "singleton" persistent lists. Does this makes any sense? Thanks! -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com From: [email protected] To: [email protected]; [email protected] Subject: RE: Composition commit and change types Date: Mon, 4 Apr 2016 05:35:13 +0000 Hi Pablo, I did include my scenarios re problem list at the bottom of the email. Having said that there had been some movement around what compositions are persistent due to no context issues so problem list may no longer be a persistent composition. There are similar scenarios for other persistent compositions also, it all comes down to context of use. As I said, I don't like advising how others implement their systems so if you think your users will benefit from this rule then go ahead, I was more concerned about Ian's response sounding definitive than your query. This has risen a interesting topic for the API SEC to address. Regards Heath On Sun, Apr 3, 2016 at 10:23 PM -0700, "pablo pazos" <[email protected]> wrote: Hi Heath, > There are way too many use cases where our service is used and many will > break this scenario like merges, distributed EHRs and cross organisational shared records. It would be helpful if you share which scenarios break the rule I stated on the previous email to improve it. IMHO I don't think anybody will take this little convo as a de facto standard, also I'm not trying to set that, never stated that. I just want to make the life of my users simpler by establishing an initial set of rules they can use until they find requirements that might need a more complex rule set, to have many cases that should be supported. I prefer that to start, instead of leaving the definition of the rules 100% to the clients of my API, considering that most of them won't have any experience with openEHR and how an openEHR backend should work. Of course this might work for my tools and my target customers, and I know this won't fit everybody, but this rule might help others to adapt it to their specific needs. And I agree if this has to be defined for an API behavior, the API SEC should be the place to define it. -- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com From: [email protected] To: [email protected]; [email protected] CC: [email protected] Subject: Re: Composition commit and change types Date: Sun, 3 Apr 2016 23:36:25 +0000 Hi Ian and Pablo, Although I don't like commenting on how others implement their systems I would hate for this discussion to become the defacto standard on how the API works in the context of persistent compositions. Although I understand Ian's position on best clinical practice of a single medication list represented as a persistent composition in a person's EHR, there is nothing stated about this in the specifications. I would be interested in other vendors implementations in this area, but as a service implementation I do not like makinging these application oriented decisions unless they are in the specification. There are way too many use cases where our service is used and many will break this scenario like merges, distributed EHRs and cross organisational shared records. I think it is the application that needs to apply these business rules. I think this needs to be addressed by the API SEC before recommendations that appear normative are made on the lists. Personally we have had big problems with persistent compositions due to lack of context, although we are working on fixing these, I still feel that perhaps we are not ready to have the category attribute constrained in the archetypes that we currently state are persistent for these same reasons. I have seen cases where there is a desire for different problem lists from different clinical perspectives, in particular a consumers view vs a GP vs a specialist. Regards Heath On Sun, Apr 3, 2016 at 11:34 AM -0700, "Ian McNicoll" <[email protected]> wrote: That looks correct to me :) Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 3 April 2016 at 19:20, pablo pazos <[email protected]> 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: [email protected] >> Date: Sun, 3 Apr 2016 11:06:53 +0100 >> Subject: Re: Composition commit and change types >> To: [email protected] >> CC: [email protected] > >> >> " 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: [email protected] >> twitter: @ianmcnicoll >> >> Co-Chair, openEHR Foundation [email protected] >> Director, freshEHR Clinical Informatics Ltd. >> Director, HANDIHealth CIC >> Hon. Senior Research Associate, CHIME, UCL >> >> >> On 3 April 2016 at 09:07, [email protected] <[email protected]> >> 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: >> > [email protected]: @ianmcnicollCo-Chair, openEHR Foundation >> > [email protected], freshEHR Clinical Informatics >> > Ltd.Director, HANDIHealth CICHon. Senior Research Associate, CHIME, >> > UCLOn 2 >> > April 2016 at 06:59, [email protected] 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> [email protected]> >> > >> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org_______________________________________________openEHR-technical >> > mailing >> > >> > [email protected]http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
