date:20160403

RE: Composition commit and change types

2016-04-03 Thread 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" 
> 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 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" 
> 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  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
>

RE: Composition commit and change types

2016-04-03 Thread 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" 
 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  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

Re: Composition commit and change types

2016-04-03 Thread 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" 
> 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  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 
>> 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;
>> >

Re: Composition commit and change types

2016-04-03 Thread 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  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 
>> 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
>> >

RE: Composition commit and change types

2016-04-03 Thread 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  
> 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:
> >

Re: Adressing of i.e. discharge summaries

2016-04-03 Thread Thomas Beale



so are we really talking about 'ADT' patterns?

On 16/03/2016 07:51, Heath Frankel wrote:


Hi Bjorn,

Yes we have used these archetypes for representing the service request 
at both the instruction and composition level. Our instruction starts 
in a care plan so we have to represent the referred to provide in the 
instruction participations. Then when we send the referral we copy it 
to the receiving provider participation in the eReferral composition.


Since a discharge summary is a kind of transfer of care then I would 
expect it to have a similar participation when it is being directed to 
a primary care provider although this doesn’t need to be populated 
when it is being uploaded to a national repository for example.


Regards



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

Re: Usage of Compositoin.Category

2016-04-03 Thread Thomas Beale



these examples from Ian illustrate exactly why we never figured this out 
before - because of the possible mixture of original content, referenced 
content, and sometimes copied content e.g. in a discharge summary. The 
problem is that 'derived' content can occur at a lower granularity than 
Composition.


Unless... we impose a discipline that says otherwise. For example, if 
there is /only/ original content and references (links, DvEhrUris) then 
everything is easy. As far as I can see, the problem is if content is 
/copied inline /from e.g. a lab result or Dx list into the discharge 
summary. For a physician, this is pretty natural, and it's easy to see 
how a nice UI can enable it.


But if we want to avoid double results in querying, we need some sort of 
'is_derived' or 'is_copy' marker (and a link to original content) on the 
copy. At least that's where I got to the last time I thought about it.


- thomas

On 12/03/2016 07:40, Ian McNicoll wrote:

Hi Ivar,

I'm not sure the situation is quite as clear-cut, in that I donlt
think there is necessarilly a simple distinction between primary data
which should normally be query-accessible and in-line vs. secondary
data which is normally query-inaccessible and referenced.

A few scenarios

1. Vital signs event - easy!! Primary, in-line and accessible

2. Diagnosis event. Primary, in-line but depending on whether a
secondary problem list is maintained, you may not want to use these
original diagnoses events for decision support.

3. Problem summary. Secondary and definitely need to be
query-accessible, but may be in-line or referenced depending on
implementation.

4. Discharge summary. Mostly secondary but may introduce new primary
content and again, whether the content is in-lie or referenced is to
some extent an implementation decision. DIPS have decided to use
referencing, others do not.

5. End of Life Summary. The critical aspects of this document are
primary e.g Resuscitation wishes but other aspects are secondary
(though and may be in-line or referenced.

I think the points raised are valid but we may need to tease out
several axes here.

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 11 March 2016 at 09:39, Ivar Yrke  wrote:

Hi
An interesting discussion that touches the very concept of structured 
information, in my opinion. I wonder if the suggested solution looks at the 
problem from the best angle. So here is my angle:

As a person with some SQL experience I would expect an AQL to return ONLY primary content 
unless told otherwise. Any content that lives in a Composition as a link I would not 
expect to see in that Composition as an entry. Resolving links is a task for the level 
"above" (rendering on a screen etc.). I can see that there possibly are needs 
for an AQL that resolves links, but I would rather see this as the special case, much 
like joining in foreign keys in SQL is an explicit decision (the SQL analogy have some 
obvious flaws!)

Why is this important? Because showing linked information in compositions where 
they were not originally recorded creates doubt about the origin of the 
information (source of truth). The duplication that Bjørn wants to solve is a 
symptom of un unhealthy structure that undermines an essential aspect of 
structured information. If a summary composition, like a discharge letter, only 
links information from other composition, there should be no duplication. So 
there should not be any need for later  special handling. There should be no 
problem to solve (well, there would be the need for the optional resolving, but 
this would be a feature rather than a problem).

AQL should relate only to the data and how they are recorded, not to how they 
are used.

With regards,
Ivar Yrke
Senior systemutvikler
DIPS ASA
Telephone +47 75 59 24 06
Mobil +47 90 78 89 33
-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bjørn Næss
Sent: 10. mars 2016 20:33
To: For openEHR technical discussions 
Subject: SV: Usage of Compositoin.Category

Hi Ian
Great response.

The most important thing for me is to precisely define the semantic meaning of 
the content in a composition. In this specific use-case the content of the 
composition is always a copy of the primary source.
This means that the Discharge letter only bring one new thing into the EHR - 
that is the fact that there is an approved discharge letter. But the entries in 
the composition is link and copies of entries in other primary sources.

The requirements to the system is quite small:

* Content of "report" documents MUST not be in the resultset when doing normal 
AQL queries.
* It

Re: SV: SV: Usage of Compositoin.Category

2016-04-03 Thread Thomas Beale




On 16/03/2016 05:19, Bjørn Næss wrote:

The problem is not to filter in data. The most important feature to support is 
to filter out data.
The proposed solution is to add a new category code to add a new group of 
Compositions which by default is sorted out.
This could be done by archetypes. But that creates the need for the implementations to 
add new filters as new archetypes are developed. If we agree that there is a large group 
of "report" compositions with only referred data from their primary sources - 
then we should make this a first class citizen of the openEHR domain model.


we have thought in the past that we should do something directly in the 
RM to mark 'reports' and other 'derivative' content in some way, but 
never agreed properly on what to do. Probably your experience reports of 
trying to convert what I imagine are well understood DIPS data 
structures and querying capabilities will help us focus on some concrete 
changes we can make to the RM. Maybe it is as simple as another 
Composition category.


Another alternative is to define a marked in EHR_STATUS e.g. is_derived: 
Boolean that would enable report-like content to be detected, and 
ignored in normal querying. We already have some other markers there 
that affect querying, e.g. is_queryable (see here 
).


- thomas

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

Re: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

2016-04-03 Thread Thomas Beale



Hi Daniel,

I read most of your thesis, it is fascinating (it's one of those things 
that requires contemplation, so I have not read it straight through). I 
recommend others to have a look 
.


One thing that I think we can say about efforts like openEHR, and indeed 
any large-ish ecosystem project (including SDOs like HL7 etc): there is 
the intended / understood sociological analysis on the part of the 
builders (we who make something in openEHR) and then there is reality. 
How we think it should work in the real world can easily be wrong-footed 
by sociopolitical realities, and these latter are ill-defined. Thus, if 
we are naive (we almost certainly have been in some ways), we get some 
things wrong and then are surprised when the world doesn't work in what 
we consider the most rational way (it rarely does). This is what happens 
around 'adoption' - things get twisted by shifting government policies, 
changing funding programmes, enterprise amnesia and many other 
phenomena. The world is always more complicated than we think it should 
be, and than our abstractions would imply...


Regarding ABD, I won't report too much just yet because I need to be 
sure of what the group leads want to do in terms of presenting their 
thinking over time, i.e. not jump the gun. When I am able, I'll post 
something.


- thomas

On 01/04/2016 12:38, Daniel Curto-Millet wrote:


Hi all,

I’ve been a long-time lurker in the lists while doing my PhD and I 
still try to keep tabs with what openEHR is doing. I wanted to react 
and take part in this discussion particularly because their paper 
resonated with me in some points (and not in others). I think the 
paper has merit and I’m interested (and quite jealous of too) that 
they did what I had wanted to do eventually with openEHR had time been 
kinder: to look and compare the global openEHR and the local openEHR(s).


The paper’s finding that you cannot separate social issues from 
technology is not new; and there is an inherent tension between a 
computer system that is based on simplification and closure 
(determinate states), from desires of freedom and flexibility usually 
associated with the social (yet, has anyone not felt the 
functional-driven approach set by bureaucracy without the need of any 
technology). So, although their point on the illusion of separation 
between the social and technical is correct; it is also true for every 
information system there is, past, present, and no doubt, future. This 
includes the accounting books from the middle-ages which tried to 
settle down some concepts (money in; money out), while giving 
flexibility to other concepts (varying prices of cereals; intangible 
assets, etc.).


When I researched the global openEHR (in contrast to implementing 
ones), I found that the project had harnessed open source in ways 
which made the modelling of ambiguous requirements possible precisely 
because there was no concept of determinacy. I remember a long series 
of discussion (Nov 2010?) between Thomas and Ed regarding openEHR’s 
way of thinking about requirements, contrasting it with the notion of 
design by committee behind (relatively) closed doors. The public space 
that open source affords openEHR is not just a trendy word, but it can 
create what Chris Kelty refers as ‘recursive commons’, a sort of space 
that respects certain values and logics (in his study, Free software) 
that can function with relative independence from competing logics 
that threaten its own existence (in his study, closed software).


As an open source project, openEHR is quite special in what it does. 
Whereas open source usually puts the ability for local populations 
(schools, architects, etc.) to collaboratively ‘own’ methods of 
productions (otherwise in the hands of those who have the key to 
closed software). openEHR creates this ownership ability at a 
conceptual level, necessarily /removed/ (but never quite so) from 
local contexts. I remember a discussion between Heather and Ian (in 
2010?) on an allergen-related archetype with a doctor who was 
particularly concerned for personal reasons and what constituted a 
‘good’ archetype relative to templates and local concerns (thus taking 
local concerns into account at this global level).


What ‘good’ means is extremely ambiguous in all cases, but that’s the 
point and openEHR’s greatest contribution and greatest challenge: the 
global project has purposefully put the definition of ‘good’ in that 
very public space of the open source world, and I don’t think it would 
be inaccurate to say that openEHR has thought this through already 
(e.g. governance change) and will continue to do so (e.g. local 
ambassadors). In this sense, I don’t see at all that openEHR is 
technologically deterministic, on the contrary. Yet the implementation 
side requires some forms of simplifications and closures (Luhmann’s 
concepts, not

Re: Composition commit and change types

2016-04-03 Thread 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

2016-04-03 Thread 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

2016-04-03 Thread 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

2016-04-03 Thread 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

2016-04-03 Thread 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

RE: Composition commit and change types

Re: Composition commit and change types

Re: Composition commit and change types

RE: Composition commit and change types

Re: Adressing of i.e. discharge summaries

Re: Usage of Compositoin.Category

Re: SV: SV: Usage of Compositoin.Category

Re: Socio-technical challenges when the openEHR approach is put to use in Norwegian hospitals

Re: Composition commit and change types

Re: Composition commit and change types

Re: Composition commit and change types

Re: Composition commit and change types

Re: Composition commit and change types

14 matches

Site Navigation

Mail list logo

Footer information