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

Re: Composition commit and change types

[Ian McNicoll]

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

___
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 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: CAMSS assessment of openEHR

[Thomas Beale]

I forgot, w.r.t. to versioning of archetypes, this is the specification 
that 
applies.


On 04/04/2016 15:51, Erik Sundvall wrote:

Adding some thoughts below.

On Mon, Apr 4, 2016 at 4:02 PM, Thomas Beale > wrote:



4.A.26: “Does the maintenance organisation for the technical
specification or standard have sufficient finances and resources
to be sure of freedom from short- to medium-term threats?”

·Unable to find any info about this.



What does the question mean?




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

Re: CAMSS assessment of openEHR

[Erik Sundvall]

Adding some thoughts below.

On Mon, Apr 4, 2016 at 4:02 PM, Thomas Beale 
wrote:
>
> 4.   A.26: “Does the maintenance organisation for the technical
> specification or standard have sufficient finances and resources to be sure
> of freedom from short- to medium-term threats?”
>
> ·   Unable to find any info about this.
>
>
> What does the question mean?
>
>
Most SEC members are financed by their "home" organisations where thay are
employed, for example EHR systems providers (vendors/projects) and
healthcare organizations. It is in the interest of those organizations to
stay up to date and also to keep the openEHR specifications updated. Most
work is done online and in teleconferences (cheap). Server resources etc
are financed by the openEHR foundation that has recurring membership
incomes.

So yes, there is enough resources to keep things going at current pace.


> 5.   A.27: “Does the technical specification or standard have a
> defined policy for version management?”
>
> ·   The change process has a description about version numbering, but
> we can’t find anything about handling different versions, compatibility,
> etc.
>
>
> Eveything is versioned in openEHR; the release strategy
> describes
> the rules of versions assignment to releases. Other than that, we would
> need to know the specific question to be able to answer better.
>

Additionally, most openEHR artifacts follow http://semver.org/


> 7.   A.48: “Does the technical specification or standard address
> backward compatibility with previous versions?”
>
> ·   Can’t find any info about this on the web pages.
>
>
> see the above link to release strategy.
>

Backwards compatibility for clinical content (already stored EHR data) is
one of openEHRs real strengths. Breaking changes to the RM (technical
reference model) level are uncommon (and migration strategies are usually
provided for any such changes). The more frequent hanges at the AM level
(archetypes and templates) do not break the readability of content based on
previous archetypes etc (since the RM and everything built on the RM stays
the same).

Also the maximal-dataset approach and broad clinical review used for
international archetyping also produces a lower number of surprising
changes in implemented systems due to reduction of the, in other approaches
more commonly occuring, finding of: "Ouch, I didn't consider that less
common usecase when designing my initial datamodel".

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se
) http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: CAMSS assessment of openEHR

[Thomas Beale]

On 04/04/2016 14:07, Bakke, Silje Ljosland wrote:


Hi,

The project has now done a preliminary CAMSS assessment of openEHR. 
It’s identified some issues that I would like some input on:


1.A.16: “Are the technical specification or standards reviewed using a 
formal review process with all relevant external stakeholders (e.g. 
public consultation)?”


·The review process is not described. There is a documented a"change 
process" 
(http://www.openehr.org/programs/specification/changeprocess), but it 
seems to be for change. Here, however, neither “review” isn’t 
described any more than that input from members of the "community" is 
sought for major changes.




there are a number of pages describing governance; see e.g. this one 
. Goals 
described here . The 
left hand menu shows the others.


The general process is:

 * new specifications are added to the current working baseline of a
   Component (list shown on the governance page - AM, RM, CDS etc) and
   are announced publicly. They have status = development. The various
   statuses are shown here
   .
   This makes them publicly visible.
 * for some period of time, development will continue, and users of the
   draft spec will report problems on the main Problem Report tracker
   
,
   or in other ways. These will be addressed by the specification owner.
 * At some point, it will be determined by the SEC
   ,
   in consultation with the community, that the specification is stable
   enough to be classified as 'trial', and it will be included in a
   named Release of the relevant component.
 * It will now be subject to formal change control, and every change
   made to it will require a Change Request on the relevant component
   CR tracker
   .

 * At some later point, it will be determined by the SEC, in
   consultation with the community that the specification can be
   classified as 'stable', and it will be marked as such.
 * A specification may be subsequently retired if it no longer serves a
   purpose.

All of this lifecycle is managed by the SEC 
, in 
consultation with the community. All documents are openly available on 
the web, and the sources are in publicly visible Git repositories 
. All of the PR 
and CR trackers are publicly visible and writeable (requires login, to 
prevent spam).


The wiki is used 
extensively as a discussion and planning resource in these processes.


It is the default situation that input from the community is always 
sought - announcements are made of all major changes in the above 
process, and community members can become involved in a number of ways.



2.A.18: “Is relevant documentation of the development and approval 
process of the specification archived and identified?”


·Issue and problem tracker available but it’s hard to find/access. 
 Approval process archive not found.




See the CR trackers 
, i.e. 
SPECxx. There is a link on the home page (top right corner) going 
straight to these; also from the specifications governance pages.


3.A.23: “Is relevant documentation of the development and approval 
process of technical specification or standards publicly available 
(e.g. preliminary results, committee meeting notes)?”


·We’ve been unable to find any minutes from meetings or preliminary 
results anywhere.




SEC face to face meeting documentation is published here 
. 
Community f2f meetings are reported as well, e.g. this one in 2014 
. Admittedly, 
these resources should be more clearly linked - we'll fix that.


The Management Board publishes a monthly update on the foundation news 
list on the web . I 
think this may also go via email directly to subscribed members, but I 
would have to check on that one.


4.A.26: “Does the maintenance organisation for the technical 
specification or standard have sufficient finances and resources to be 
sure of freedom from short- to medium-term threats?”


·Unable to find any info about this.



What does the question mean?

5.A.27: “Does the technical specification or standard have a defined 
policy for version management?”


·The change process has a description about version numbering, but we 
can’t find anything about hand

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: CAMSS assessment of openEHR

[Bakke, Silje Ljosland]

Hi,

The project has now done a preliminary CAMSS assessment of openEHR. It’s 
identified some issues that I would like some input on:

1.   A.16: “Are the technical specification or standards reviewed using a 
formal review process with all relevant external stakeholders (e.g. public 
consultation)?”

·   The review process is not described. There is a documented a"change 
process" (http://www.openehr.org/programs/specification/changeprocess ), but it 
seems to be for change. Here, however, neither “review” isn’t described any 
more than that input from members of the "community" is sought for major 
changes.

2.   A.18: “Is relevant documentation of the development and approval 
process of the specification archived and identified?”

·   Issue and problem tracker available but it’s hard to find/access.  
Approval process archive not found.

3.   A.23: “Is relevant documentation of the development and approval 
process of technical specification or standards publicly available (e.g. 
preliminary results, committee meeting notes)?”

·   We’ve been unable to find any minutes from meetings or preliminary 
results anywhere.

4.   A.26: “Does the maintenance organisation for the technical 
specification or standard have sufficient finances and resources to be sure of 
freedom from short- to medium-term threats?”

·   Unable to find any info about this.

5.   A.27: “Does the technical specification or standard have a defined 
policy for version management?”

·   The change process has a description about version numbering, but we 
can’t find anything about handling different versions, compatibility, etc.

6.   A.45: “Are there existing or planned mechanisms to assess conformity 
of the implementations of the technical specification or standard (e.g. 
conformity tests, certifications)?”

·   Can’t find anything about this on the web pages.

7.   A.48: “Does the technical specification or standard address backward 
compatibility with previous versions?”

·   Can’t find any info about this on the web pages.

Anyone? ☺

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Wednesday, January 13, 2016 3:52 PM
To: For openEHR technical discussions 
Subject: RE: CAMSS assessment of openEHR

Thanks again Ian! ☺

Could anyone from Slovenia provide links to documents mandating or recommending 
openEHR, and procurement documents referring to it? It doesn’t matter if 
they’re in Slovenian, the main point is that they can be proven to exist.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Monday, January 11, 2016 10:41 AM
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: Re: CAMSS assessment of openEHR

I have added some links. many of the questions seem inappropriate, not 
applicable, or virtually impossible to answer within the health domain.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 6 January 2016 at 08:00, Bakke, Silje Ljosland 
mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:
Thanks Ian!

It’s good to see there are so many “yes”-es! However, we’ll need some more 
info, for instance links to where the “relevant documentation of the 
development and approval process of the specification is archived and 
identified”.

We’ll handle the spreadsheet bit. ☺

Regards,
Silje

From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org]
 On Behalf Of Ian McNicoll
Sent: Tuesday, January 05, 2016 11:37 AM
To: For openEHR technical discussions

Subject: Re: CAMSS assessment of openEHR

My first go now at CAMSS wiki 
page,

There appears to be a major snafu with the CAMMS spreadsheet that auto-sets 
'not applicable' to most of the rows if 'open specification' is set as the 
standard type. This makes some sense for a proprietary specification but none 
whatsoever for an open specification. @Silje - you may want to seek 
clarification from the CAMMS authors.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Dir