RE: Composition commit and change types

[pablo pazos]

I agree with that, rephrasing, this "delta mode" would be just an API 
*feature*. Also both modes full and delta can be supported by the same API, 
with the same results when querying data back. This might not be part of a 
generic API spec, but more a concrete ITS.
I think especially for persistent compos, the delta mode is smarted than the 
full revision, and with a little thought/design, might be as safer as the full 
revision.
I'll put this idea in my icebox, since my user base is growing, in the near 
future I can send a survey to them to see if this might make their life easier. 
I won't write a line of code for this until I have a change request, and I'm 
sure this doesn't complicate other features.
Either way, it would be useful to have input from commercial implementers about 
if they support something like this, and  also about the original issue
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

> From: i...@freshehr.com
> Date: Mon, 4 Apr 2016 21:12:00 +0100
> Subject: Re: Composition commit and change types
> To: openehr-technical@lists.openehr.org
> 
> Hi Pablo,
> 
> I think there are lots of interesting approaches (though potentially
> challenging in complex environments) but I would definitely want to
> handle the question of 'diffs or not' behind the service layer. As a
> consumer I just want to be sure that the current composition
> accurately reflects changes made. Full revision is a bit dumb but it
> is safe!
> 
> 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 4 April 2016 at 20:18, pablo pazos <pazospa...@hotmail.com> wrote:
> > I think that can work for some implementations.
> >
> > What I was thinking is not adding parts to an existing compo, but to commit
> > a full COMPO, just with the changes. That means, the newObject would be a
> > COMPOSITION or even a VERSION. If this is for the Problem List, to add a new
> > one, the COMPO will have just one EVALUATION with the new problem. If commit
> > mode is "delta", the backend will do what it needs to reflect that addition
> > to the current Problem List. If the commit mode is "full", that means one
> > problem was added and the rest removed.
> >
> > IMO this can use the same commit(VERSION[] versions, AUDIT_DETAILS audit)
> > adding a String mode param or adding another operation
> > commit_delta(VERSION[] versions, AUDIT_DETAILS audit).
> >
> > For my implementation all commits are for completed COMPOS, the API you
> > described might allow partial updates to already committed COMPOS, and I
> > don't think delta commit should imply partial updates. Delta is just to
> > commit a completed COMPO but without the need of replicating all the
> > information that hasn't changed. The backend can create the full compo
> > internally, that would not be an issue.
> >
> > Also, that is related with the initial issue: detecting individual changes
> > to persistent COMPOS. Sending just the changes, allows to identify those
> > with the user responsible for the changes, so it is easier to create lists
> > of problems, medications, etc. per user or organization, even if internally
> > that is stored in one singleton VERSIONED_COMPO. per persistent archetype.
> >
> > Consider this is only for my implementation, I'm not looking for defining
> > this for the official openEHR API, but can help as input. I want to double
> > check my criteria with other implementers before implementing anything :)
> >
> > --
> > Kind regards,
> > Eng. Pablo Pazos Gutiérrez
> > http://cabolabs.com
> >
> > 
> > Subject: Re: Composition commit and change types
> > To: openehr-technical@lists.openehr.org
> > From: thomas.be...@openehr.org
> > Date: Mon, 4 Apr 2016 19:50:50 +0100
> >
> >
> >
> >
> > On 04/04/2016 19:14, pazospa...@hotmail.com wrote:
> >
> > Hi Thomas,
> >
> >
> > What about having the 'delta' mode just at the API level? Storage might not
> > store delta objects, just full objects, but the API allows to send only what
> > was added, modified or deleted instead of the full compo?
> >
> >
> > then you have a transactional concept, i.e. 'add', 'remove', 'modify' etc...
> > so for me the better way to think about it isn't in terms of data structures
> > but in terms

RE: Composition commit and change types

[pablo pazos]

I think that can work for some implementations.
What I was thinking is not adding parts to an existing compo, but to commit a 
full COMPO, just with the changes. That means, the newObject would be a 
COMPOSITION or even a VERSION. If this is for the Problem List, to add a new 
one, the COMPO will have just one EVALUATION with the new problem. If commit 
mode is "delta", the backend will do what it needs to reflect that addition to 
the current Problem List. If the commit mode is "full", that means one problem 
was added and the rest removed.
IMO this can use the same commit(VERSION[] versions, AUDIT_DETAILS audit) 
adding a String mode param or adding another operation commit_delta(VERSION[] 
versions, AUDIT_DETAILS audit).
For my implementation all commits are for completed COMPOS, the API you 
described might allow partial updates to already committed COMPOS, and I don't 
think delta commit should imply partial updates. Delta is just to commit a 
completed COMPO but without the need of replicating all the information that 
hasn't changed. The backend can create the full compo internally, that would 
not be an issue.
Also, that is related with the initial issue: detecting individual changes to 
persistent COMPOS. Sending just the changes, allows to identify those with the 
user responsible for the changes, so it is easier to create lists of problems, 
medications, etc. per user or organization, even if internally that is stored 
in one singleton VERSIONED_COMPO. per persistent archetype. 
Consider this is only for my implementation, I'm not looking for defining this 
for the official openEHR API, but can help as input. I want to double check my 
criteria with other implementers before implementing anything :)
-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: Composition commit and change types
To: openehr-technical@lists.openehr.org
From: thomas.be...@openehr.org
Date: Mon, 4 Apr 2016 19:50:50 +0100


  

  
  




On 04/04/2016 19:14,
  pazospa...@hotmail.com wrote:



  
  
Hi Thomas,



What about
  having the 'delta' mode just at the API level? Storage might
  not store delta objects, just full objects, but the API allows
  to send only what was added, modified or deleted instead of
  the full compo?
  



then you have a transactional concept, i.e. 'add', 'remove',
'modify' etc... so for me the better way to think about it isn't in
terms of data structures but in terms of logical changes to the
existing state of some Composition. 



But the logical thing is just a function of the form



add (atPath: String; newObject: Locatable)



so then it's just a case of what level of domain semantics you want.
For example, you could have a function:



addEntryToComposition (atPath: String; newEntry: Entry)



so it's not far to get to:



addMedicationOrder (newMed: Instruction)



Now - we don't need a path, since the API knows we are dealing with
a MedicationList Composition (that should follow an archetype of
that name) and new medication orders  (Instructions) only go in a
certain place.



So you can take your pick - the great thing about APIs is you can
have as many as you like - as long as they all obey the same rules
of data structuring and validity.



If it makes sense in your environment to create an API of the
flavour of the first one above I say go for it. 



- thomas



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://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

Re: Composition commit and change types

[Thomas Beale]

On 04/04/2016 19:14, pazospa...@hotmail.com wrote:


Hi Thomas,


What about having the 'delta' mode just at the API level? Storage 
might not store delta objects, just full objects, but the API allows 
to send only what was added, modified or deleted instead of the full 
compo?




then you have a transactional concept, i.e. 'add', 'remove', 'modify' 
etc... so for me the better way to think about it isn't in terms of data 
structures but in terms of logical changes to the existing state of some 
Composition.


But the logical thing is just a function of the form

add (atPath: String; newObject: Locatable)

so then it's just a case of what level of domain semantics you want. For 
example, you could have a function:


addEntryToComposition (atPath: String; newEntry: Entry)

so it's not far to get to:

addMedicationOrder (newMed: Instruction)

Now - we don't need a path, since the API knows we are dealing with a 
MedicationList Composition (that should follow an archetype of that 
name) and new medication orders  (Instructions) only go in a certain place.


So you can take your pick - the great thing about APIs is you can have 
as many as you like - as long as they all obey the same rules of data 
structuring and validity.


If it makes sense in your environment to create an API of the flavour of 
the first one above I say go for it.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Composition commit and change types

[pazospablo]

  

Hi Thomas,
What about having the 'delta' mode just at the API level? Storage might not 
store delta objects, just full objects, but the API allows to send only what 
was added, modified or deleted instead of the full compo?
Sent from my LG Mobile


-- Original message--From: Thomas BealeDate: Mon, Apr 4, 2016 10:31To: 
openehr-technical@lists.openehr.org;Subject:Re: Composition commit and change 
types

On 04/04/2016 07:23, pablo pazos wrote:
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.  
I think it is not just a display requirement, at least in some
countries. There are separate care plans for example in the UK forsome 
patients for relatively unrelated conditions. Whether separatemedication 
lists really exist at the clinical level is a question (abad idea for 
obvious reasons, same for allergies), but I suspect itcould exist at a 
practical level in some places, if a GP or otherMeds list is imported into 
a hospital environment that has its ownmedications list; in this case, the 
two taken together would be seenas the total logical list,  but each part 
being owned by a differentprovider. We need more concrete evidence on this, 
but I don't seeanything to prevent this sort of thing happening.

  

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?  
openEHR doesn't say how to store the Versions, only that the logical
view needs to be that each Version appears to have the full content.If you 
want to engineer a delta-based storage mechanism, you can,the specs don't 
prevent that. Note that implementing differentialrepresentations for object 
structures is non-trivial, but doable(AOM2 does it for example); if you are 
storing some serial format,then you can potentially use text-based diffing, 
although you haveto be careful of ordering within Hashes and Lists, which 
tends tobreak purely logical versioning e.g. on XML.

  
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.
  
Well, all it really means is that a function might be added to theEHR 
API that enables you to 'add' just a medication to a medicationlist, and 
the API will actually figure out how to create the wholecomposition, do any 
diffing, and store the proper Composition withina Contribution. Personally 
I think a better way that I haveadvocated for some years is a business 
level service + API called'medication list' that provides functions like:
  getAll: List  getAllIds: List
addMedicationOrder (newMed: Instruction)  removeMedicationOrder 
(id: String)  getMedicationOrdersInState (aState: StateEnum) // e.g.
'active', etc  putAction (anAction: Action; orderId: String)  etc   
 that's just one idea of the service. Obviously it can be done  
differently. The point is that it would provide all the needed  conversions 
between a functional/transactional interface, and the  appropriate openEHR 
structures. It would do all the building of  Compositions and so on, and 
make the correct calls to the EHR  service.
I would foresee the same kind of service for:
  allergies & interactions  vaccinations  procedures list   
   care plan  patient diary  doctor's diary  etc- thomas
  

  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Composition commit and change types

[Thomas Beale]

On 04/04/2016 07:23, pablo pazos wrote:

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.


I think it is not just a display requirement, at least in some 
countries. There are separate care plans for example in the UK for some 
patients for relatively unrelated conditions. Whether separate 
medication lists really exist at the clinical level is a question (a bad 
idea for obvious reasons, same for allergies), but I suspect it could 
exist at a practical level in some places, if a GP or other Meds list is 
imported into a hospital environment that has its own medications list; 
in this case, the two taken together would be seen as the total logical 
list,  but each part being owned by a different provider. We need more 
concrete evidence on this, but I don't see anything to prevent this sort 
of thing happening.





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?


openEHR doesn't say how to store the Versions, only that the logical 
view needs to be that each Version appears to have the full content. If 
you want to engineer a delta-based storage mechanism, you can, the specs 
don't prevent that. Note that implementing differential representations 
for object structures is non-trivial, but doable (AOM2 does it for 
example); if you are storing some serial format, then you can 
potentially use text-based diffing, although you have to be careful of 
ordering within Hashes and Lists, which tends to break purely logical 
versioning e.g. on XML.




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.




Well, all it really means is that a function might be added to the EHR 
API that enables you to 'add' just a medication to a medication list, 
and the API will actually figure out how to create the whole 
composition, do any diffing, and store the proper Composition within a 
Contribution. Personally I think a better way that I have advocated for 
some years is a business level service + API called 'medication list' 
that provides functions like:


 * getAll: List
 * getAllIds: List
 * addMedicationOrder (newMed: Instruction)
 * removeMedicationOrder (id: String)
 * getMedicationOrdersInState (aState: StateEnum) // e.g. 'active', etc
 * putAction (anAction: Action; orderId: String)
 * etc

that's just one idea of the service. Obviously it can be done 
differently. The point is that it would provide all the needed 
conversions between a functional/transactional interface, and the 
appropriate openEHR structures. It would do all the building of 
Compositions and so on, and make the correct calls to the EHR service.


I would foresee the same kind of service for:

 * allergies & interactions
 * vaccinations
 * procedures list
 * care plan
 * patient diary
 * doctor's diary
 * etc

- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Composition commit and change types

[pablo pazos]

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: heath.fran...@oceaninformatics.com
To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org
Subject: RE: Composition commit and change types
Date: Mon, 4 Apr 2016 05:35:13 +








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" 
<pazospa...@hotmail.com> 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: heath.fran...@oceaninformatics.com

To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org

CC: openehr-technical@lists.openehr.org

Subject: Re: Composition commit and change types

Date: Sun, 3 Apr 2016 23:36:25 +





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

RE: Composition commit and change types

[Heath Frankel]

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" 
<pazospa...@hotmail.com<mailto:pazospa...@hotmail.com>> 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<http://cabolabs.com/es/home><http://twitter.com/ppazos>


From: heath.fran...@oceaninformatics.com
To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org
CC: openehr-technical@lists.openehr.org
Subject: Re: Composition commit and change types
Date: Sun, 3 Apr 2016 23:36:25 +

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" 
<i...@freshehr.com<mailto:i...@freshehr.com>> wrote:

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 wil

RE: Composition commit and change types

[pablo pazos]

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: heath.fran...@oceaninformatics.com
To: pazospa...@hotmail.com; openehr-technical@lists.openehr.org
CC: openehr-technical@lists.openehr.org
Subject: Re: Composition commit and change types
Date: Sun, 3 Apr 2016 23:36:25 +









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" 
<i...@freshehr.com> wrote:






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

>

>>

>>

Re: Composition commit and change types

[Heath Frankel]

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" 
<i...@freshehr.com<mailto:i...@freshehr.com>> wrote:

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 intr

Re: Composition commit and change types

[Ian McNicoll]

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 p

RE: Composition commit and change types

[pablo pazos]

@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 newIf change_type == 
creation // only allows to create one persistent compo, all other commits 
should be modifications  create versioned_compo with version v1  return 
200 OKElse  return 400 Bad Request  ElseIf change_type in 
[amendment, modification]  create new version in existing versioned_compo 
// this will create v2, v3, ...  return 200 OKElse // 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 pro

Re: Composition commit and change types

[Ian McNicoll]

" 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  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>
> 

Re: Composition commit and change types

[Ian McNicoll]

"All is already versioned, my question is about how to commit compos
and if it makes sense to have two different versioned compositions for
the same persistent compo archetype"

For a persistent composition you should generally only maintain a
single instance that is continually updated i.,e same instance, same
compositionId, new version.

As I said before things are a bit more hazy for compositions whose
persistence only lasts as long as a care episode, where a new instance
might be created for each care episode but then that same instance
updated through the episode.

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 08:59, pazospa...@hotmail.com  wrote:
> All is already versioned, my question is about how to commit compos and if
> it makes sense to have two different versioned compositions for the same
> persistent compo archetype.
>
>
> Sent from my LG Mobile
>
> -- Original message--
>
> From: Bert Verhees
>
> Date: Sat, Apr 2, 2016 15:01
>
> To: openehr-technical@lists.openehr.org;
>
> Subject:Re: Composition commit and change types
>
> I guess you need to version it, if you want it to be according the specs.
> That means, when you use it for a medication-list, you will get many
> versions of the same compositions for a patient.
>
> But if you do not version it, that means that the concept of replaying the
> Past in case of legal investigation will not be possible.
>
> Bert
>
>
> On 02-04-16 07: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
> 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

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Composition commit and change types

[Ian McNicoll]

Hi Pablo,

I disagree for safety reasons. Knowing all of the medications that the
patient is taking/should be taking is a critical part of prescribing.
Of course it is legitimate to apply filters but I would be very
unhappy with an institution that wanted to maintain multiple
medication lists.

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 08:56, pazospa...@hotmail.com  wrote:
> I think that has more to do with the user interface than how compositions
> are committed, since I can filter meds by who prescribe them with ease.
>
>
> Sent from my LG Mobile
>
> -- Original message--
>
> From: Karsten Hilbert
>
> Date: Sat, Apr 2, 2016 04:25
>
> To: openehr-technical@lists.openehr.org;
>
> Subject:Re: Composition commit and change types
>
> On Sat, Apr 02, 2016 at 05:59:33AM +, pazospa...@hotmail.com wrote:>
> i.e. I don't see an EHR having two different medication lists, is that
> possible?Regardless of whether it makes sense conceptually, you will,at any
> rate, encounter clinicians of differing specialitiesworking against the same
> OpenEHR intance wanting to have"their own" medication list each.Whether the
> backend actually does "their own" is another matter.Karsten-- GPG key ID
> E4071346 @ eu.pool.sks-keyservers.netE167 67FD A291 2BEA 73BD  4537 78B9
> A9F9 E407
> 1346___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

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Composition commit and change types

[pazospablo]

  

All is already versioned, my question is about how to commit compos and if 
it makes sense to have two different versioned compositions for the same 
persistent compo archetype.
Sent from my LG Mobile


-- Original message--From: Bert VerheesDate: Sat, Apr 2, 2016 15:01To: 
openehr-technical@lists.openehr.org;Subject:Re: Composition commit and change 
typesI guess you need to version it, if you  want it to be according 
the specs.
  That means, when you use it for a medication-list, you will get  many 
versions of the same compositions for a patient.
  
  But if you do not version it, that means that the concept of  
replaying the Past in case of legal investigation will not be  possible.
  
  Bert
  
  
  On 02-04-16 07: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 
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

Re: Composition commit and change types

[pazospablo]

I think that has more to do with the user interface than how compositions 
are committed, since I can filter meds by who prescribe them with ease.
Sent from my LG Mobile


-- Original message--From: Karsten HilbertDate: Sat, Apr 2, 2016 
04:25To: openehr-technical@lists.openehr.org;Subject:Re: Composition commit and 
change typesOn Sat, Apr 02, 2016 at 05:59:33AM +, pazospa...@hotmail.com 
wrote:> i.e. I don't see an EHR having two different medication lists, is that 
possible?Regardless of whether it makes sense conceptually, you will,at any 
rate, encounter clinicians of differing specialitiesworking against the same 
OpenEHR intance wanting to have"their own" medication list each.Whether the 
backend actually does "their own" is another matter.Karsten-- GPG key ID 
E4071346 @ eu.pool.sks-keyservers.netE167 67FD A291 2BEA 73BD  4537 78B9 A9F9 
E407 1346___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

Re: Composition commit and change types

[Ian McNicoll]

Hi Pablo,

When I am advising implementers on this, I use the following categories ...

## Composition Commit Styles

Depending on the clinical requirement, 3 styles of commit strategy are
suggested.

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 corrected

2. **’Episodic’**

Create a new composition via POST for each Period of Care i.e an
admission. If it needs to updated, use a PUT to modify i.e Each
patient has a single instance per Period of Care.

3. **’Longitudinal’**

Create a new composition via POST for each patient. If it needs to
updated use a PUT to modify i.e. each patient has only a single
instance over their lifetime. This will be unusual in a hospital
record where there is generally limited ability to curate the patient
record in this way.

So your persistence uses cases are either 2/3. Currently to manage
Episodic persistence, you need ot set the composition category to
event, as the RM currently forces a 'persistent' composition to be
contextless i.e. the context attribute is 0...0. This will change in
an upcoming RM revision.

The decision about when/where to maintain persistent/curated lists is
one which will vary between implementations. I would generally expect
Medication lists, Allergies and some documents such as Resuscitation
preferences to be maintained as single, persistent instances. Although
Problems and Procedures should also probably be maintained that way,
there are valid situations where departmental problem lists e.g Renal
medicine have validity.

There are strong arguments, at least in UK practice, for maintaining a
single cross-organisation outpatient/community medication record but
each inpatient medication list should be separately maintianed for
each instiution/episode of care.

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 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 list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org