RE: Christmas cleaning of the openEHR wiki...

[Bakke, Silje Ljosland via openEHR-technical]

I could definitely live with that, but only if the scope of each space is made 
clear in the space description and with a clear delineation to related spaces 
on the front page. To me, “Ontology” or “Terminology” isn’t clear at all, and 
especially with regard to where they intersect with “Specifications” and 
“Clinical”. There also seems to me there’s an overlap in use between 
“Education”, “Community” and “Resources” that needs to be delineated.

I also noticed that we have the Calendar app enabled. Does anyone use it? If 
not, could we disable it?

Kind regards, Silje

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Wednesday, August 7, 2019 11:19 AM
To: openehr-technical@lists.openehr.org
Subject: Re: Christmas cleaning of the openEHR wiki...


My personal view is that it is better to have slightly more spaces each with 
clear scope, even if some have not much content, rather than trying to push all 
content into a few spaces with larger amounts of content. To me it seems 
obvious what kinds of things I might find in 'ontology' and 'education', 
whereas if I know there are some articles on these areas, but they are buried 
in e..g the 'specifications' space, it's going to be a matter of trying to 
search for them with various keys.

I fixed the Resources space a little bit, but it seems to me there is a fair 
bit of content like FAQs that people may well access.

these are just my views, and others may have better ideas...!

- thomas
On 07/08/2019 08:26, Bakke, Silje Ljosland via openEHR-technical wrote:
I think we may need a more thorough discussion about how to best use the wiki. 
How do we maximise information findability, how do we enable new people (and 
not-so-new people!) to find their way around? Do we make new empty spaces when 
we start something new, or do we branch them out when the existing spaces 
become crowded? How do we decide what goes in which space?

For now:

  *   I’ve reactivated the Education space, since I saw it was used for the 
Spanish openEHR Day. (Is this really education though, and not community?)
  *   The Ontologies space has a single page with a few attachments, of which 
nothing has been changed since 2012. Does this really warrant a separate space? 
Could this page be moved to a different space?
  *   Could the Community space be merged with Resources? If I understand 
correctly, their uses are at least partly overlapping.

Kind regards, Silje


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

RE: Christmas cleaning of the openEHR wiki...

[Bakke, Silje Ljosland via openEHR-technical]

I think we may need a more thorough discussion about how to best use the wiki. 
How do we maximise information findability, how do we enable new people (and 
not-so-new people!) to find their way around? Do we make new empty spaces when 
we start something new, or do we branch them out when the existing spaces 
become crowded? How do we decide what goes in which space?

For now:

  *   I’ve reactivated the Education space, since I saw it was used for the 
Spanish openEHR Day. (Is this really education though, and not community?)
  *   The Ontologies space has a single page with a few attachments, of which 
nothing has been changed since 2012. Does this really warrant a separate space? 
Could this page be moved to a different space?
  *   Could the Community space be merged with Resources? If I understand 
correctly, their uses are at least partly overlapping.

Kind regards, Silje

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Tuesday, August 6, 2019 3:51 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Christmas cleaning of the openEHR wiki...



On 06/08/2019 13:43, Bakke, Silje Ljosland via openEHR-technical wrote:
Picking this up again half a year later…

I’ve archived the following spaces, since there seemed to be a consensus that 
they weren’t used. This is easily reversible:

  *   Healthcare
  *   Demonstration Space
  *   Education
  *   Ontologies
  *   Website

Thomas, have you had a chance to look at and/or move the stuff in the following 
spaces?

although the CIMI and Terminology spaces are not added to in recent times, they 
are both regularly viewed for content, including by outside agencies (including 
US VA and HL7).

I'd rather keep the Ontologies space alive as well, it is read quite often.

I also suspect Education is going to start being used soon (including by me ;)

  *   CIMI
  *   Terminology

For the rest of you, does anyone care if the following spaces are archived?

  *   Projects (https://openehr.atlassian.net/wiki/spaces/projects)

this is historical info, and I think can be archived.



  *
  *   Zz openEHR Community (https://openehr.atlassian.net/wiki/spaces/oecom)

I guess this can be archived, but what happens the next time people want to 
discuss and record ideas about openEHR Community functioning ;)



  *

Regarding the CQ space: Nobody has asked a question in two years in any of the 
spaces. Do we need to keep the Questions functionality at all?


I don't really know how to interpret the lack of use - I think people with 
questions do not think to go to the openEHR website and find the Questions 
link, which used to be on the home page. Maybe we should put it back?

- thomas




Kind regards, Silje

From: openEHR-technical 
<mailto:openehr-technical-boun...@lists.openehr.org>
 On Behalf Of Thomas Beale
Sent: Wednesday, December 19, 2018 7:29 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: Christmas cleaning of the openEHR wiki...



On 19/12/2018 11:19, Ian McNicoll wrote:

Effectively empty:

  *   https://openehr.atlassian.net/wiki/spaces/healthcare (mostly empty pages, 
last edit in 2011)

there is some content here, but no idea who cares about it.



  *   https://openehr.atlassian.net/wiki/spaces/ds (Demo default Confluence 
space?)

seems to be Confluence help material - not sure if we should delete or not.



  *   https://openehr.atlassian.net/wiki/spaces/CQ

I think Confluence creates this when we started using Questions - and it says 
not to delete...



  *   https://openehr.atlassian.net/wiki/spaces/WEB

we can probably remove this, since we use Jira to manage web work now, but I 
need to check.



  *

Apparently abandoned:

  *   
https://openehr.atlassian.net/wiki/spaces/ADL<https://openehr.atlassian.net/wiki/spaces/ADL/>
 (last three edits 338, 965 and 1631 days ago)

this one is not abandoned - contains pages that are linked to from the 
Archetype specs release 
page<https://specifications.openehr.org/releases/AM/latest/index>

  *   https://openehr.atlassian.net/wiki/spaces/CIMI (last activity in 2015)

contains material that should be retained somewhere - I'll have a look

  *   https://openehr.atlassian.net/wiki/spaces/edu (two pages, the most recent 
edited in 2012)

looks dead



  *   https://openehr.atlassian.net/wiki/spaces/ontol (only one page, edited in 
2012)

not used AFAIK



  *   https://openehr.atlassian.net/wiki/spaces/projects (last real 
contribution 720 days ago)

the community should have a look at this one and decide if it is useful I think



  *   https://openehr.atlassian.net/wiki/spaces/stds (last real contribution 
950 days ago)



we do actually use this, just not that frequently. I'll move the CIMI material 
here



  *   https://openehr.atlassian.net/wiki/spaces/SYS (last activity 2015)

 we use this for sysadmin; last update: 2018-06-11

  *   https://openehr.atlassian.net/wiki/spaces/term (last activity 2014)



not used 

RE: Christmas cleaning of the openEHR wiki...

[Bakke, Silje Ljosland via openEHR-technical]

Picking this up again half a year later…

I’ve archived the following spaces, since there seemed to be a consensus that 
they weren’t used. This is easily reversible:

  *   Healthcare
  *   Demonstration Space
  *   Education
  *   Ontologies
  *   Website

Thomas, have you had a chance to look at and/or move the stuff in the following 
spaces?

  *   CIMI
  *   Terminology

For the rest of you, does anyone care if the following spaces are archived?

  *   Projects (https://openehr.atlassian.net/wiki/spaces/projects)
  *   Zz openEHR Community (https://openehr.atlassian.net/wiki/spaces/oecom)

Regarding the CQ space: Nobody has asked a question in two years in any of the 
spaces. Do we need to keep the Questions functionality at all?

Kind regards, Silje

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Wednesday, December 19, 2018 7:29 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Christmas cleaning of the openEHR wiki...



On 19/12/2018 11:19, Ian McNicoll wrote:

Effectively empty:

  *   https://openehr.atlassian.net/wiki/spaces/healthcare (mostly empty pages, 
last edit in 2011)

there is some content here, but no idea who cares about it.



  *   https://openehr.atlassian.net/wiki/spaces/ds (Demo default Confluence 
space?)

seems to be Confluence help material - not sure if we should delete or not.



  *   https://openehr.atlassian.net/wiki/spaces/CQ

I think Confluence creates this when we started using Questions - and it says 
not to delete...



  *   https://openehr.atlassian.net/wiki/spaces/WEB

we can probably remove this, since we use Jira to manage web work now, but I 
need to check.



  *

Apparently abandoned:

  *   
https://openehr.atlassian.net/wiki/spaces/ADL
 (last three edits 338, 965 and 1631 days ago)

this one is not abandoned - contains pages that are linked to from the 
Archetype specs release 
page

  *   https://openehr.atlassian.net/wiki/spaces/CIMI (last activity in 2015)

contains material that should be retained somewhere - I'll have a look

  *   https://openehr.atlassian.net/wiki/spaces/edu (two pages, the most recent 
edited in 2012)

looks dead



  *   https://openehr.atlassian.net/wiki/spaces/ontol (only one page, edited in 
2012)

not used AFAIK



  *   https://openehr.atlassian.net/wiki/spaces/projects (last real 
contribution 720 days ago)

the community should have a look at this one and decide if it is useful I think



  *   https://openehr.atlassian.net/wiki/spaces/stds (last real contribution 
950 days ago)



we do actually use this, just not that frequently. I'll move the CIMI material 
here



  *   https://openehr.atlassian.net/wiki/spaces/SYS (last activity 2015)

 we use this for sysadmin; last update: 2018-06-11

  *   https://openehr.atlassian.net/wiki/spaces/term (last activity 2014)



not used for a long time. I would move the SNOMED stuff under the STD space.



  *   https://openehr.atlassian.net/wiki/spaces/oecom (last real contribution 
805 days ago)

this is a special space that we use for community stuff; don't know how much is 
needed of what is there, though...


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

RE: DV_PROPORTION vs DV_QUANTITY for %

[Bakke, Silje Ljosland]

Anyone…? 

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Bakke, Silje Ljosland
Sent: Tuesday, January 8, 2019 2:53 PM
To: For openEHR technical discussions 
Subject: RE: DV_PROPORTION vs DV_QUANTITY for %

I still don’t understand if we have a conclusion. And I don’t understand why 
proportion is the correct data type for O2 levels but not for alcohol levels.

Regards,
Silje

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Ian McNicoll
Sent: Monday, January 7, 2019 7:13 PM
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: Re: DV_PROPORTION vs DV_QUANTITY for %

Simple answer - loads of real data - pulse_oximetry and Oxygen levels will have 
been recorded hundreds of thousands if not millions of times in patient data - 
and Proportion *is* the correct datatype for O2 levels.

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

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


On Mon, 7 Jan 2019 at 17:56, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:
one thing to note: DV_PROPORTION is a more complex data structure. I
would be tempted to try to determine what use has been made of this
archetype so far - i.e. in creating real data. If no real data has been
created, then it could in theory be changed.

- thomas

On 07/01/2019 12:11, Ian McNicoll wrote:
> Hi Silje,
>
> As you say, I think this a case of emerging clarity (or less fog of
> confusion!!) as the various use-cases emerge. As the primary author of
> both these archetypes, in retrospect I would probably keep
> inspired_oxygen as DV_PROPORTION and change pulse_oximetry to
> DV_QUANTITY but!!! I do not see any good argument for changing these
> now. We have to expect some degree of inconsistency, and live with it,
> to avoid unnecessary breaking changes.
>


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto: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: DV_PROPORTION vs DV_QUANTITY for %

[Bakke, Silje Ljosland]

I still don’t understand if we have a conclusion. And I don’t understand why 
proportion is the correct data type for O2 levels but not for alcohol levels.

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Ian McNicoll
Sent: Monday, January 7, 2019 7:13 PM
To: For openEHR technical discussions 
Subject: Re: DV_PROPORTION vs DV_QUANTITY for %

Simple answer - loads of real data - pulse_oximetry and Oxygen levels will have 
been recorded hundreds of thousands if not millions of times in patient data - 
and Proportion *is* the correct datatype for O2 levels.

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?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Mon, 7 Jan 2019 at 17:56, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:
one thing to note: DV_PROPORTION is a more complex data structure. I
would be tempted to try to determine what use has been made of this
archetype so far - i.e. in creating real data. If no real data has been
created, then it could in theory be changed.

- thomas

On 07/01/2019 12:11, Ian McNicoll wrote:
> Hi Silje,
>
> As you say, I think this a case of emerging clarity (or less fog of
> confusion!!) as the various use-cases emerge. As the primary author of
> both these archetypes, in retrospect I would probably keep
> inspired_oxygen as DV_PROPORTION and change pulse_oximetry to
> DV_QUANTITY but!!! I do not see any good argument for changing these
> now. We have to expect some degree of inconsistency, and live with it,
> to avoid unnecessary breaking changes.
>


___
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: Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

Amen.

So, do we have a conclusion that toolmakers can reference? Can we document this 
somewhere in the specs or elsewhere?

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Heather Leslie
Sent: Wednesday, December 19, 2018 7:22 AM
To: For openEHR technical discussions 
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Hi everyone,

In our modelling, it is safe to assume that the latest version of an archetype 
is the best candidate on offer for anyone using an archetype and filling a SLOT 
for the first time. Options for use of previous versions may be useful for 
implementers who have older versions in their current systems and don’t want 
two different versions or to update all their systems to the latest version.

I totally agree that from a governance point of view SLOT inclusions won’t need 
to specify a version in 99% of cases. However in some situations it 
theoretically may be appropriate to fix a version in place in a specific SLOT. 
In fact I can’t think of a use case YET where we need to specify a certain 
version, but no doubt this will occur at some time in the near future.

In all our modelling it seems that as soon as we limit our options one way or 
another we discover a use case that breaks our most recently made rule! 
Murphy’s law?

So we want to have our cake and eat it too – default to any or all versions of 
an archetype, with the option to specify one (or maybe even multiple) if needs 
be. Same theory applies to exclusions in a SLOT as well.

The governance overheads of currently specifying v0 and/or v1 and/or v2  will 
only increase as time goes on and at present as CKAs we have people upset that 
v0 is specifically included but that archetype has subsequently been published 
as v1. They want to see v1 specifically included. They don’t understand the 
theory behind it, not unreasonably, that as long as no archetypes (and 
versions) are excluded in a specific way, even if the SLOT suggests a v0 as an 
inclusion, it technically doesn’t stop a v1 being inserted in there. So the 
inclusion of all versions also has an important design guidance function as 
well. Newbies may not understand that if an archetype of the appropriate class 
is no actively excluded, then any or all of the archetypes of that class are 
technically valid for adding into a template.

Regards

Heather

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Bakke, Silje Ljosland
Sent: Wednesday, 19 December 2018 1:15 AM
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image001.jpg@01D4A69F.B91D67F0]

Regards,
Silje

From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
spe

RE: DV_PROPORTION vs DV_QUANTITY for %

[Bakke, Silje Ljosland]

I think maybe actual modelling practice should be taken into account here. 
Since these guidelines haven't been available, several important percentages in 
published archetypes have been modelled as DV_PROPORTION:
openEHR-EHR-CLUSTER.inspired_oxygen.v1 
https://ckm.openehr.org/ckm/#showArchetype_1013.1.393 
openEHR-EHR-OBSERVATION.pulse_oximetry.v1 
https://ckm.openehr.org/ckm/#showArchetype_1013.1.3084 

The way I understand the arguments here, there isn't a good one for changing 
these data types and going to v2 for these archetypes?

Regards,
Silje

-Original Message-
From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Saturday, January 5, 2019 3:36 PM
To: openehr-technical@lists.openehr.org
Subject: Re: DV_PROPORTION vs DV_QUANTITY for %


On 05/01/2019 12:56, Ian McNicoll wrote:
> There is a very clear use-case for having it there - O2 levels 
> variably and equivalently described a FiO2 which is a unitary 
> proportion or percent.
>
> I think we need to keep it for that reason if no other.

So in that case we need to upgrade the documentation for when to choose a 
DV_QUANTITY percent, and when a DV_PROPORTION %.

- 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: DV_PROPORTION vs DV_QUANTITY for %

[Bakke, Silje Ljosland]

In that case, I don't understand the use case for the 'percent' and 'unitary' 
variants of the DV_PROPORTION data type. What are they for?

Regards,
Silje

-Original Message-
From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Friday, January 4, 2019 8:38 PM
To: openehr-technical@lists.openehr.org
Subject: Re: DV_PROPORTION vs DV_QUANTITY for %


On 03/01/2019 08:37, David Moner wrote:
> I think DV_QUANTITY is the option here. Someone could argue that % is 
> not a proper unit, but it is, both in UCUM and SNOMED CT.
>
> DV_PROPORTION should be only used when you want to maintain the 
> numerator and denominator explicitly separated, as a fraction, which 
> should not be the case with percentages. But it is true that the 
> definition of the type attribute in the specification is a bit
> misleading: "Indicates semantic type of proportion, including percent, 
> unitary etc."

David is right on all counts - use DV_QUANTITY, but we should fix that line in 
the specification. Can someone raise a PR on that please.

- 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: DV_PROPORTION vs DV_QUANTITY for %

[Bakke, Silje Ljosland]

I would have guessed it would be the other way around. If you know at design 
time that this value will be a percentage, use the DV_PROPORTION data type with 
the ‘type’ attribute set to 2 (percent, denominator fixed to 100). On the other 
hand if you don’t know for sure (such as for some lab results or medication 
strengths which could be for example mg/ml or % interchangeably), you would use 
DV_QUANTITY.

Regards,
Silje

From: openEHR-clinical  On Behalf 
Of David Moner
Sent: Thursday, January 3, 2019 9:37 AM
To: For openEHR technical discussions 
Cc: For openEHR clinical discussions (openehr-clini...@lists.openehr.org) 

Subject: Re: DV_PROPORTION vs DV_QUANTITY for %

I think DV_QUANTITY is the option here. Someone could argue that % is not a 
proper unit, but it is, both in UCUM and SNOMED CT.

DV_PROPORTION should be only used when you want to maintain the numerator and 
denominator explicitly separated, as a fraction, which should not be the case 
with percentages. But it is true that the definition of the type attribute in 
the specification is a bit misleading: "Indicates semantic type of proportion, 
including percent, unitary etc."

El jue., 3 ene. 2019 a las 7:59, Bakke, Silje Ljosland 
(mailto:silje.ljosland.ba...@nasjonalikt.no>>)
 escribió:
Hi everyone, happy new year!

We’ve just hit a question about modelling choices, how to represent 
percentages. We have a data type DV_PROPORTION, which can be used to represent 
any proportion such as a fraction or a percentage, and we have the DV_QUANTITY 
data type which can have % as the unit. In most existing archetypes such as the 
OBSERVATION.pulse_oximetry archetype, we’ve used the DV_PROPORTION data type 
for the percent elements, while for some reason in the draft 
EVALUATION.alcohol_consumption_summary archetype we’ve chosen DV_QUANTITY with 
the unit ‘%’ for the “Strength” element.

We’ve had a look at the data types documentation 
(https://specifications.openehr.org/releases/RM/latest/data_types.html), and we 
can’t really find any guidance in the examples there. Is there any guidance 
about this anywhere else? Does anyone have any opinions about when to use each 
data type for percentages?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>

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


--
David Moner Cano
Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

DV_PROPORTION vs DV_QUANTITY for %

[Bakke, Silje Ljosland]

Hi everyone, happy new year!

We've just hit a question about modelling choices, how to represent 
percentages. We have a data type DV_PROPORTION, which can be used to represent 
any proportion such as a fraction or a percentage, and we have the DV_QUANTITY 
data type which can have % as the unit. In most existing archetypes such as the 
OBSERVATION.pulse_oximetry archetype, we've used the DV_PROPORTION data type 
for the percent elements, while for some reason in the draft 
EVALUATION.alcohol_consumption_summary archetype we've chosen DV_QUANTITY with 
the unit '%' for the "Strength" element.

We've had a look at the data types documentation 
(https://specifications.openehr.org/releases/RM/latest/data_types.html), and we 
can't really find any guidance in the examples there. Is there any guidance 
about this anywhere else? Does anyone have any opinions about when to use each 
data type for percentages?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

Coding the DV_IDENTIFIER 'type'

[Bakke, Silje Ljosland]

Hi,

In the documentation for the DV_IDENTIFIER data type 
(https://specifications.openehr.org/releases/RM/Release-1.0.3/data_types.html#_dv_identifier_class),
 the attribute 'type' is described as "Optional identifier type, such as 
prescription , or Social Security Number . One day a controlled vocabulary 
might be possible for this." (my emphasis). Is it possible to code this at the 
moment, given that the data type for 'type' is String and not for example 
DV_TEXT?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

Christmas cleaning of the openEHR wiki...

[Bakke, Silje Ljosland]

Hi everyone,

Sorry for the crossposting, but I thought this would concern everyone.

I believe the openEHR wiki is an important documentation tool that has probably 
been a bit neglected(?). The default Confluence theme isn't super pretty, and 
the site is difficult to navigate, in my opinion because of the large number of 
spaces and the lack of a proper front page for the site as a whole.

I'd like to suggest reducing the number of spaces by removing/merging/archiving 
the spaces that are empty and/or abandoned. Those are:

Effectively empty:

  *   https://openehr.atlassian.net/wiki/spaces/healthcare (mostly empty pages, 
last edit in 2011)
  *   https://openehr.atlassian.net/wiki/spaces/ds (Demo default Confluence 
space?)
  *   https://openehr.atlassian.net/wiki/spaces/CQ
  *   https://openehr.atlassian.net/wiki/spaces/WEB

Apparently abandoned:

  *   
https://openehr.atlassian.net/wiki/spaces/ADL
 (last three edits 338, 965 and 1631 days ago)
  *   https://openehr.atlassian.net/wiki/spaces/CIMI (last activity in 2015)
  *   https://openehr.atlassian.net/wiki/spaces/edu (two pages, the most recent 
edited in 2012)
  *   https://openehr.atlassian.net/wiki/spaces/ontol (only one page, edited in 
2012)
  *   https://openehr.atlassian.net/wiki/spaces/projects (last real 
contribution 720 days ago)
  *   https://openehr.atlassian.net/wiki/spaces/stds (last real contribution 
950 days ago)
  *   https://openehr.atlassian.net/wiki/spaces/SYS (last activity 2015)
  *   https://openehr.atlassian.net/wiki/spaces/term (last activity 2014)
  *   https://openehr.atlassian.net/wiki/spaces/oecom (last real contribution 
805 days ago)

I suggest the empty spaces are deleted, and the abandoned ones are archived.

This will leave us with:

  *   https://openehr.atlassian.net/wiki/spaces/dev
  *   https://openehr.atlassian.net/wiki/spaces/healthmod
  *   https://openehr.atlassian.net/wiki/spaces/resources
  *   https://openehr.atlassian.net/wiki/spaces/spec

...which in my opinion is a much more manageable selection of spaces.

I'm not sure what to do about the look of the page though. Maybe making a 
simple front page for the entire wiki with links and short descriptions about 
each space would solve a lot for now?

Thoughts?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

RE: Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

Thanks Thomas,

The idea here is that we (likely in 99% of the cases) do want to include any 
version of the archetype, so the .v[0-2] variant isn’t relevant. The reason for 
this is that even though an archetype will have breaking changes from one major 
version to the next, the clinical concept will stay the same (or it should have 
a completely new ID). We don’t generally include archetypes based on their 
specific content at the time of inclusion, but on the clinical concept they 
represent.

If leaving the version part out completely is the correct way to leave 
versioning open when including archetypes, the CKM will need to change 
behaviours regarding this, since it currently rejects any archetype that does 
this:
[cid:image001.jpg@01D496E4.7F780930]

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Tuesday, December 18, 2018 1:30 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Syntax for including archetypes in SLOTs, regardless of version


Silje,

just as a technical note, the proper regex for including

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2.

is
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v(0|1|2)

or

openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v[0-2]

to allow any version, just leave the version id part off entirely.

Note that different major versions of an archetype are technically different 
archetypes - i.e. they contain some breaking change. So whether allowing any 
major version of an archetype in a slot is a good default probably needs to be 
thought about carefully.

- thomas
On 18/12/2018 11:56, Bakke, Silje Ljosland wrote:
Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Project, Intermountain 
Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR 
Foundation<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer 
Society<http://www.bcs.org/category/6044>
Health IT blog<http://wolandscat.net/> | Culture 
blog<http://wolandsothercat.net/> | The Objective 
Stance<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

v[0-9][0-9] would also include v00-v09, which we don’t want.

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Anastasiou A.
Sent: Tuesday, December 18, 2018 1:04 PM
To: For openEHR technical discussions 
Subject: RE: Syntax for including archetypes in SLOTs, regardless of version

Hi Silje

I may not have got this right, but why not “v[0-9][0-9]?” (or, not care about 
what follows “body_mass_index”) ?

In other words, add a pattern to catch “any single (possibly double) digit 
version number” (?).

This looks like a straightforward case of “constrain to 
openEHR-EHR-OBSERVATION\.body_mass_index”.

All the best
Athanasios Anastasiou




From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 On Behalf Of Bakke, Silje Ljosland
Sent: 18 December 2018 11:57
To: For openEHR technical discussions 
mailto:openehr-technical@lists.openehr.org>>
Subject: Syntax for including archetypes in SLOTs, regardless of version

Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>

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

Syntax for including archetypes in SLOTs, regardless of version

[Bakke, Silje Ljosland]

Hi,

Sebastian Garde and I had a brainstorm a while ago about how to handle 
inclusion of archetypes in SLOTs (either CLUSTERs within ENTRY archetypes, or 
ENTRY archetypes within COMPOSITIONs or SECTIONs). At the moment this has to be 
noted explicitly (whether because of tooling or the specifications, I don’t 
know), so that in order to include for example all historical versions and 
specialisations of the Body Mass Index archetype in a COMPOSITION or SECTION, I 
have to include both 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v0, 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v1 and 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v2. If we ever make 
a v3 BMI archetype, this will then need to be added. This is a hassle when 
modelling archetypes in the first place, and it’s an even worse problem for 
governing them over time.

Based on the discussion I had with Sebastian, and with the kind help of some 
regex geeks on Twitter (you know who you are ), I propose one of the following 
as the default syntax for including any version of a given archetype in a SLOT:

  1.  An explicit regex for the version number, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*\.v([0]|[1-9][0-9]*)
  2.  Leaving out entirely the version part of the expression, for example 
openEHR-EHR-OBSERVATION\.body_mass_index(-[a-zA-Z0-9_]+)*

I think it should still be possible to include a specific version of the 
archetype, but that this should not be the default behaviour of the tools.

I don’t particularly care if one of these two suggestions, or an entirely 
different solution, is adopted, but this issue has to be decided and 
implemented soon.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

RE: Two-level modelling diagram

[Bakke, Silje Ljosland]

I also like this diagram a lot, big improvement on the old one! 

Would it be relevant to add a cylinder for terminologies in the knowledge 
development environment part (with arrows to archetypes and templates), to show 
explicitly that they’re thought of and highly relevant?

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Gunnar Klein
Sent: Wednesday, November 28, 2018 2:22 PM
To: For openEHR technical discussions 
Subject: Re: Two-level modelling diagram

I liked much of the figure but why do you have to cylinders for value sets. 
Should be better with one like for templates.
kind regards
gunnar

Den ons 28 nov. 2018 13:23 skrev Thomas Beale 
mailto:thomas.be...@openehr.org>>:



This diagram 

 (SVG) is a replacement for an old one used in a lot of papers. People who want 
a better diagram might like this one, from a more recent version of the 
Architecture Overview.

[cid:part2.295C89A2.4740AC48@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

Postcoordinated terminology expressions in openEHR

[Bakke, Silje Ljosland]

Hi everyone,

We've recently started an informal and practically oriented regular contact 
with the Norwegian SNOMED CT NRC. One of the things they were interested in 
discussing was how to use postcoordinated SNOMED CT (expression constraint 
language) expressions with openEHR, which I know nothing about. Does anyone 
have any knowledge about or experience with this?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

RE: AW: Unique paths for slots problem if slots are filled with same archetype

[Bakke, Silje Ljosland]

Hi all! I hope the SEC will discuss and hopefully solve this issue in the 
upcoming meeting in Oslo. This is fairly serious from a modelling POV, as there 
are some archetypes that are based on the (in my opinion fair) assumption that 
it’s possible to tell two instances of the same CLUSTER in two parallel SLOTs 
apart. An example is “Communication capability” 
https://ckm.openehr.org/ckm/#showArchetype_1013.1.3155. We’d prefer not having 
to change the modelling to circumvent the technical issue, if possible. 

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: Tuesday, October 23, 2018 11:21 AM
To: openehr-technical@lists.openehr.org
Subject: Re: AW: Unique paths for slots problem if slots are filled with same 
archetype




On 23/10/2018 10:09, Sebastian Garde wrote:
So that we don’t forget, I have created 
https://openehr.atlassian.net/browse/SPECPR-279 for this.
I am not fussed whether it is prepended or appended, I can see tiny advantages 
for both.
The more interesting question to me is whether this is optional and only added 
when really needed or required.
There is this edge case, but I also wonder if a reasonable query on data would 
be to ask for anything inside a specific slot, no matter what it is filled with 
(as e.g. mandated by Template A vs Template B). This does not really seem to be 
(generally) possible - even if there are not two identical archetypes in 
different slots?


that would also require adding the slot node id, but I wonder how useful this 
particular query really could be... we never thought of it in 10 years of using 
AQL AFAIK...

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

RE: SHRINE for openEHR ?

[Bakke, Silje Ljosland]

IIRC the LHS toolbox project at the Norwegian Centre for E-health Research is 
doing federated AQL queries? I don’t know the details, but I suspect someone 
else on this list do.

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Ian McNicoll
Sent: Friday, October 5, 2018 12:46 AM
To: For openEHR technical discussions 
Subject: Re: SHRINE for openEHR ?

Hi,

I know that some work is intended to do federated AQL for the UK GEL 10,000 
Genomes project where there are 12 London hospitals each with their own CDR but 
common openEHR archetypes and templates I'm not sure how far along that is.

I am working with some comp sci students to do a very simple version but this 
will be no more sophisticated than send ing an equivalent AQL to several CDRs 
and 'munging' the returning resultSets. That should be visible as an OSS 
project within a few weeks.

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?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Thu, 4 Oct 2018 at 22:19, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:

There is not at the moment, although various people have been thnking about 
distributed AQL querying for some years now. THe interesting version is where 
server-side computation is used, which is more compliant with legislation that 
prohibits health data to flow out of systems to users with no care relationship.

We don't have a technical work-up of the solution for doing distributed queries 
yet (at least not a public one), so if you have technical proposals, we would 
be interested to see them.

- thomas

On 01/10/2018 08:54, Georg Fette wrote:
Hello,
Is there an equivalent to i2b2's SHRINE in the openEHR world ? SHRINE is a 
system that distributed an i2b2 query to a network of i2b2 installations and 
aggregates the returned results.
Greetings
Georg

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Project, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog | The Objective 
Stance
___
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: DV_DURATION and magnitude_status?

[Bakke, Silje Ljosland]

Thanks for all your replies! 

Attempt at summarising:

  *   DV_DURATION doesn’t support <>=~ at the moment, but there’s some SEC work 
underway to fix this.
  *   For now, using DV_QUANTITY with a property of time could do the trick.

Is this a good summary?

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Diego Boscá
Sent: Tuesday, September 25, 2018 9:32 AM
To: For openEHR technical discussions 
Subject: Re: DV_DURATION and magnitude_status?

After rereading what Silje needed, I think the mentioned attribute would do the 
trick for her

However seems like we at SEC have work to do :)

El lun., 24 sept. 2018 a las 23:36, Pablo Pazos 
(mailto:pablo.pa...@cabolabs.com>>) escribió:

On Mon, Sep 24, 2018 at 4:26 PM Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:


On 24/09/2018 16:19, Pablo Pazos wrote:
> I think there was a conversation about being able to constraint the
> magnitude of a DV_DURATION instead of the String expression. The issue
> was the magnitude is a function, not an attribute of DV_DURATION.

that is also my understanding...

I'm not sure if that was just a conversation or if we have a proposal from the 
SEC to make changes on that area, do you recall?


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


--
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter

[https://drive.google.com/uc?id=0B27lX-sxkymfM1pnTU44YXlFbHc=download]
http://www.cabolabs.com
https://cloudehrserver.com

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


--

[VeraTech for Health SL]

[Twitter]   [LinkedIn]  
  [Maps]  

[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada 
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está destinada a 
ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le recordamos que 
sus datos han sido incorporados en el sistema de tratamiento de VERATECH FOR 
HEALTH, SL y que siempre y cuando se cumplan los requisitos exigidos por la 
normativa, usted podrá ejercer sus derechos de acceso, rectificación, 
limitación de tratamiento, supresión, portabilidad y oposición/revocación, en 
los términos que establece la normativa vigente en materia de protección de 
datos, dirigiendo su petición a Avda Puerto 237, 1º, pta 1 - 46011 Valencia o 
bien a través de correo electrónico d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o el 
agente responsable de entregar el mensaje al destinatario, o ha recibido esta 
comunicación por error, le informamos que está totalmente prohibida, y puede 
ser ilegal, cualquier divulgación, distribución o reproducción de esta 
comunicación, y le rogamos que nos lo notifique inmediatamente y nos devuelva 
el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

DV_DURATION and magnitude_status?

[Bakke, Silje Ljosland]

Hi,

I've got a use case where we need to represent a time duration (of a symptom), 
which can be for example <24H or >3M. Is it possible to represent this using 
the DV_DURATION data type, like you can do with DV_QUANTITY and 
magnitude_status? If not, what should we do?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

RE: Drug dispense entry class question

[Bakke, Silje Ljosland]

That’s probably a jurisdiction thing too. I’m not sure if it’s a legal 
requirement or just considered good clinical practice, but generally a dose 
change is a cessation/new order here. 

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Sam Heard
Sent: Monday, August 13, 2018 2:46 PM
To: For openEHR technical discussions 
Subject: RE: Drug dispense entry class question


Hi All



There is the interesting situation as to what constitutes a stop/start and an 
amend for medication. Generally, if it is the same generic substance people 
will want to see it as an amend. This means they do not have to go through all 
the warnings and search again in the database. This is probably of no 
consequence from a data point of view, apart from the fact that you do not want 
to be warned that a patient has previously been on this medication (happens in 
our system).



Cheers, Sam



Sent from Mail for Windows 10




From: openEHR-technical 
mailto:openehr-technical-boun...@lists.openehr.org>>
 on behalf of Thomas Beale 
mailto:thomas.be...@openehr.org>>
Sent: Monday, August 13, 2018 9:07:18 PM
To: 
openehr-technical@lists.openehr.org
Subject: Re: Drug dispense entry class question



On 11/08/2018 20:50, Karsten Hilbert wrote:
> On Sat, Aug 11, 2018 at 04:24:47PM -0300, Pablo Pazos wrote:
>
> I meant to say that some treatments will not end until the
> patient dies meaning that the COMPLETED state will never be
> reached if we take into account

certainly true in theory, and maybe in reality. But drug treatments
change and different variants may be tried over time - true even for
basics like insulin - so at least for some chronic medication
situations, it probably will be the case that one treatment finishes and
another starts, based on a (?slightly) different order, with this
repeating over time.

- 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

Is description = <"*"> mandatory?

[Bakke, Silje Ljosland]

Hi everyone,

In modelling cases, particularly where we're modelling scores and scales, the 
description element of text or ordinal values are unnecessary, because the 
value defined in the score only contain a single string of text. A good example 
of this is the ECOG Performance Status archetype, where editors (both Ocean's 
AE and Marand's AD) add a '*' in the empty description element, like this:

["at0005"] = <
text = <"Fully active, able to carry on all pre-disease 
performance without restriction.">
description = <"*">
>

Is the description element mandatory, since the editors both do this? Could we, 
in cases where we don't need it, leave out the description altogether?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

RE: Unique paths for nodes in multiple instances of one archetype in the same OPT

[Bakke, Silje Ljosland]

As a side note, the “Service request” archetype has just (yesterday, in fact) 
been published as INSTRUCTION.service_request.v1.
Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Friday, July 06, 2018 11:16 AM
To: For openEHR technical discussions 
Subject: Re: Unique paths for nodes in multiple instances of one archetype in 
the same OPT

Hi Dileep,

The usual approach I take here is to rename the clustered archetype to reflect 
local use, which works out as

[openEHR-EHR-COMPOSITION.request.v1]
[openEHR-EHR-INSTRUCTION.request.v0]
[openEHR-EHR-CLUSTER.organisation.v0, 'Requesting organisation']
[openEHR-EHR-CLUSTER.person_name.v1]
[openEHR-EHR-CLUSTER.organisation.v0, ' Receiving organisation']
[openEHR-EHR-CLUSTER.person_name.v1]

and is queryable on AQL.

see 
https://github.com/RippleOSI/Ripple-openEHR/tree/master/docs/bindings/Current%20Ripple%20Headings/Referrals

Note that the AQL described was not working correctly on Ethercis in the past 
but that issue may have been fixed.

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?export=download=0BzLo3mNUvbAjUmNWaFZYZlZ5djg=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Fri, 6 Jul 2018 at 10:07, Dileep V S 
mailto:dil...@healthelife.in>> wrote:
Hi,

We are trying to create a service request template using the following structure

[openEHR-EHR-COMPOSITION.request.v1]
[openEHR-EHR-INSTRUCTION.request.v0]
[openEHR-EHR-CLUSTER.organisation.v0]
[openEHR-EHR-CLUSTER.person_name.v1]
[openEHR-EHR-CLUSTER.organisation.v0]
[openEHR-EHR-CLUSTER.person_name.v1]

The first set of organization & person name archetypes are for the requester 
and the second set for the receiver.

However in the template editor, the paths for the nodes of both these instances 
are the same(Eg. Orgaization name, Identifier, unstructured name etc). This, we 
feel, will create problems in the AQL as we cannot uniquely identify the nodes. 
How do we solve this problem. Is there any better way to model the template

I m attaching the template file set for reference

Regards

[https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8]

Dileep V S

Founder

HealtheLife Ventures LLP

m:

+91 9632888113

a:

103, Innovation Centre, IIIT, Electronics City, Bangalore 560100

w:

healthelife.in  e: 
dil...@healthelife.in

___
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: SV: [Troll] Terminology bindings ... again

[Bakke, Silje Ljosland]

I read Thomas' reply with great interest, and I generally agree that with a 
well thought out information model, the very detailed precoordinated 
expressions are redundant. At the same time I understand Mikael's point of view 
too. BUT, what I'm often met with is that because these precoordinated 
expressions exist (like for example "lying blood pressure" and "sitting blood 
pressure"), we should use them INSTEAD OF using our clever information models 
(that we do have) for recording new data.

In my opinion this is wrong because it doesn't take into account that 
healthcare is unpredictable, and this makes recording more difficult for the 
clinician. How many different variations would you have to select from? Take 
the made up example "sitting systolic blood pressure with a medium cuff on the 
left upper arm"; this will be a lot of possible permutations, especially if you 
take into account all the different permutations where one or more variable 
isn't relevant.

So while I don't think the existence of these precoordinated terms in itself is 
a problem, it's a potential problem that people get a bit overzealous with them.

Regards,
Silje

From: openEHR-technical  On Behalf 
Of Mikael Nyström
Sent: Friday, March 23, 2018 10:06 AM
To: For openEHR technical discussions 
Subject: SV: SV: [Troll] Terminology bindings ... again

Hi tom,

I can agree with you that if SNOMED CT was created when all patients in the 
world already had all information in their health record recorded using 
cleverly built and structured information models (like archetypes, templates 
and similar), but that is not the case. Instead SNOMED CT also tries to help 
healthcare organizations to do something better also with their already 
recorded health record information, because that information to a large extent 
still belongs to living patients.

It would be interesting to have your opinion about why it is a real problem 
with the "extra" pre-coordinated concepts in SNOMED CT in general and not only 
for the use case of creating archetypes or what would be nicest in theory.

 Regards
 Mikael


Från: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] 
För Thomas Beale
Skickat: den 23 mars 2018 01:06
Till: 
openehr-technical@lists.openehr.org
Ämne: Re: SV: [Troll] Terminology bindings ... again


I have made some attempts to study the problem in the past, not recently, so I 
don't know how much the content has changed in the last 5 years. Two points 
come to mind:


1. the problem of a profusion of pre-coordinated and post-coordinatable 
concepts during a lexically-based choosing process (which is often just on a 
subset).
 this can be simulated by the lexical search in any of the Snomed search 
engines, as shown in the screen shots below. Now, the returned list is just a 
bag of lexical matches, not a hierarchy. But - it is clear from just the size 
of the list that it would take time to even find the right one - usually there 
are several matches, e.g. 'blood pressure (obs entity)', 'systemic blood 
pressure', 'systolic blood pressure', 'sitting blood pressure', 'stable blood 
pressure' and many more.

I would contend (and have for years) that things like 'sitting blood pressure', 
'stable blood pressure', and 'blood pressure unrecordable' are just wrong as 
atomic concepts, each with a separate argument as to why. I won't go into any 
of them now. Let's assume instead that the lexical search was done on a subset, 
and that only observables and findings (why are there two?) show up, and that 
the user clicks through 'blood pressure (observable entity)', ignoring the 30 
or more other concepts. Then the result is a part of the hierarchy, see the 
final screenshot. I would have a hard time building any ontology-based argument 
for even just this one sub-tree, which breaks basic terminology rules such as 
mutual exclusivity, collective exhaustiveness and so on. How would the user 
choose from this? If they are recording systolic systemic arterial BP, lying, 
do they choose 'systemic blood pressure', 'arterial blood pressure', 'systolic 
blood pressure', 'lying blood pressure', or something else.

Most of these terms are pre-coordinated, and the problem would be solved by 
treating the various factors such as patient position, timing, mathematical 
function (instant, mean, etc), measurement datum type (systolic, pulse, MAP 
etc), subsystem (systemic, central venous etc) and so on as post-coordinatable 
elements that can be attached in specific ways according to the ontological 
description of measuring blood pressure on a body. This is what the blood 
pressure archetype does, and we might argue that since that is the model of 
capturing BP measurements (not an ontological description of course), it is the 
starting point, and in fact 

RE: Setting thresholds

[Bakke, Silje Ljosland]

We’re getting into territory that maybe doesn’t belong in the technical list 
anymore, but anyway.

I suspect this may be a disagreement in choice of words. I’m talking about the 
difference between observational and evaluative statements. The lab result is 
observational and what I called “diagnosis” is evaluative. The point I was 
trying to make is that these are different in nature, whether we choose to call 
the evaluative statement “problem” or “diagnosis”. The S-sodium lab result by 
itself doesn’t necessarily mean that the patient actually had a real 
hyponatremia, though I see that my previous statement could be interpreted as 
such. Maybe the patient had simultaneous hyperlipidemia or hyperproteinemia? 
The assessment of the larger picture is of course what leads to the evaluative 
statement.

The overall point I was trying to make was that you can’t expect to be able to 
computationally draw conclusions about the health of a patient based only on 
reference ranges for single observational statements; you also need a human (or 
perhaps in the future a machine?) to assess a larger picture.

I wish you all a nice weekend! ☺

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of GF
Sent: Friday, March 2, 2018 4:19 PM
To: Thomas Beale <openehr-technical@lists.openehr.org>
Subject: Re: Setting thresholds

I agree with Karsten.

Diagnosis (in my terms) is a statement as the result of an Evaluation process 
about the Patient System.
Measurement is the result of an Observation process about the Patient System 
using materials of the Patient System as source.
Evaluation is the result of an Evaluation process that indicates that the 
result is ‘normal’, ‘elevated’, ‘low’, ‘abnormal’, ‘risk of’, etc.

Gerard   Freriks
+31 620347088
  gf...@luna.nl<mailto:gf...@luna.nl>

Kattensingel  20
2801 CA Gouda
the Netherlands


On 2 Mar 2018, at 15:22, Karsten Hilbert 
<karsten.hilb...@gmx.net<mailto:karsten.hilb...@gmx.net>> wrote:

On Fri, Mar 02, 2018 at 01:48:40PM +0000, Bakke, Silje Ljosland wrote:


A doctor making and recording a conclusion that a
measurement of some kind is too high or too low, IS a
diagnosis.

Uhm, no.


their conclusion would be recorded as a diagnosis of hyponatremia.

While most doctors will do that it is wrong.

Hyponatremia is not a diagnosis. It is just a
supposedly-clever way of saying what the lab already said. It
is intended to make non-doctors think we doctors are in
control of the situation.

At best, it is an unresolved problem. All in all it is a
_finding_, or observation, notably out-of-range :-)

Karsten
--
GPG key ID E4071346 @ 
eu.pool.sks-keyservers.net<http://eu.pool.sks-keyservers.net>
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto: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: Setting thresholds

[Bakke, Silje Ljosland]

You're right, I missed the "have HAD". The correct query would of course be 
"all patients with an EVALUATION.problem_diagnosis with one of a defined set of 
codes for ‘hypertension’".

A doctor making and recording a conclusion that a measurement of some kind is 
too high or too low, IS a diagnosis. A similar example using lab results would 
be a measured serum sodium level of 105 mmol/L, with the attached (from the 
lab) reference range of 115-160 mmol/L. The fact that the measurement is 
outside the reference range is an indication to the doctor that something is 
wrong, but their conclusion would be recorded as a diagnosis of hyponatremia. 
When the patient at a later point is better and a subsequent sodium result is 
back within the reference range, the hyponatremia diagnosis would be set as 
resolved.

Regards,
Silje


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Karsten Hilbert
Sent: Friday, March 2, 2018 2:29 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Setting thresholds

On Fri, Mar 02, 2018 at 01:18:03PM +, Bakke, Silje Ljosland wrote:

> A query for “all patients that have had high BP according to the 
> doctor” would the way I see this be a query for “all patients with an 
> EVALUATION.problem_diagnosis with one of a defined set of codes for 
> ‘hypertension’ and no resolution date”.

It would not be.

Because the two assertions are not equivalent.

Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
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: Setting thresholds

[Bakke, Silje Ljosland]

This sounds like a sensible and pragmatic solution. ☺

A query for “all patients that have had high BP according to the doctor” would 
the way I see this be a query for “all patients with an 
EVALUATION.problem_diagnosis with one of a defined set of codes for 
‘hypertension’ and no resolution date”.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Jan-Marc Verlinden
Sent: Friday, March 2, 2018 2:09 PM
To: For openEHR technical discussions 
Subject: Re: Setting thresholds

This ended up being quite some discussion.. :-)

We choose for the option to show the thresholds in the Graph, and do it 
handcrafted/hardcoded. So we will not be able to query on the semantics of the 
data, in this sense: give me all patients that has had high BP according to the 
doctor. We will only be able to query on defined thresholds (by Snomed or 
whatever..).

It is what it is.. :-)

For this usecase there is absolutely no need to make it more difficult than 
just this. Maybe for other usecases there would be another optimum, but for now 
I would like to keep it KISS.
--

Regards, Jan-Marc
Mobile: +31 6 53785650
www.medrecord.io
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Setting thresholds

[Bakke, Silje Ljosland]

Jean-Marc specified that thresholds would need to be able to be "changed 
afterwards" (I assume after the data was committed to the EHR), which to me 
implies that their problem was closer to my item 1) below.

Regards,
Silje

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Karsten Hilbert
Sent: Friday, March 2, 2018 12:13 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Setting thresholds

On Fri, Mar 02, 2018 at 10:55:47AM +0000, Bakke, Silje Ljosland wrote:

> I've hesitated to participate in this discussion, but I think I have a couple 
> of points to add now, as I think there are two different problems being 
> discussed here:
> 
> 1.   The original problem, which in my opinion is how and where to store 
> reference ranges for clinical observations such as for instance blood 
> pressure. These reference ranges are often based on clinical research, and 
> may change with time as new research emerges. In my opinion these shouldn't 
> be stored with the original observation data, but can (when needed) be stored 
> with any interpretation where the data is used to reach a conclusion, for 
> example a symptom, diagnosis or even just an instruction. The reference 
> ranges that are current at any point in time however, should be stored and 
> accessed from a knowledge base outside the EHR, as they don't relate to the 
> data of a specific patient. However, that knowledge base may well be linked 
> to specific archetypes and archetype elements to facilitate its usage, for 
> example to the systolic, diastolic and position elements of the blood 
> pressure archetype, if the reference ranges vary based on the position of the 
> patient at the time of measurement.
> 
> 2.   The problem of reference ranges that are intricately bound to 
> specific observations and their methods, such as lab results. These should 
> be, and are commonly, stored with the observations in the EHR because the 
> details of analytic method and other factors that affect them are far too 
> complex to include in the EHR data. The RM attributes "normal_range" and 
> "other_reference_ranges" (and "normal_status") of the Quantity data type are 
> well suited for these reference ranges.

That about wraps it up.

Except that I was of the impression that the original question was more about 
2) rather than 1).

Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

___
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: Setting thresholds

[Bakke, Silje Ljosland]

I've hesitated to participate in this discussion, but I think I have a couple 
of points to add now, as I think there are two different problems being 
discussed here:

1.   The original problem, which in my opinion is how and where to store 
reference ranges for clinical observations such as for instance blood pressure. 
These reference ranges are often based on clinical research, and may change 
with time as new research emerges. In my opinion these shouldn't be stored with 
the original observation data, but can (when needed) be stored with any 
interpretation where the data is used to reach a conclusion, for example a 
symptom, diagnosis or even just an instruction. The reference ranges that are 
current at any point in time however, should be stored and accessed from a 
knowledge base outside the EHR, as they don't relate to the data of a specific 
patient. However, that knowledge base may well be linked to specific archetypes 
and archetype elements to facilitate its usage, for example to the systolic, 
diastolic and position elements of the blood pressure archetype, if the 
reference ranges vary based on the position of the patient at the time of 
measurement.

2.   The problem of reference ranges that are intricately bound to specific 
observations and their methods, such as lab results. These should be, and are 
commonly, stored with the observations in the EHR because the details of 
analytic method and other factors that affect them are far too complex to 
include in the EHR data. The RM attributes "normal_range" and 
"other_reference_ranges" (and "normal_status") of the Quantity data type are 
well suited for these reference ranges.


Regards,
Silje


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Karsten Hilbert
Sent: Friday, March 2, 2018 11:28 AM
To: openehr-technical@lists.openehr.org
Subject: Re: Setting thresholds



On Fri, Mar 02, 2018 at 10:07:24AM +0100, David Moner wrote:



> You are talking about a future reuse or validation of the data. But

> what it was discused here is how to define the reference ranges for

> any data to take an action at the moment of data registry. And, as

> Gerard said, those references must be stored for future interpretation

> of the data. Thus, I'm of the opinion that ideally this should be

> stored together with the archetype/templates as it is part of the domain 
> knowledge at that moment.



The ranges will be different across labs and across types of measurement due to 
"precision available", "reagants used", "technology applied", and a variety of 
other ugly real-world factors. Even for the very same LOINC from the very same 
lab.



I don't think this knowledge should (or can) live in the archetype but rather 
be stored with the data and/or the interpretation of the data.



Karsten

--

GPG key ID E4071346 @ eu.pool.sks-keyservers.net

E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



___

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: Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

Hi,

«Any units» isn’t the same as “arbitrary units”. As I wrote below, “arbitrary 
units” in the context of biomedicine are units which are defined by biological 
activity, such as level of allergic reaction or enzymatic activity. This is 
done to be able to compare the concentration of different substances which have 
the same effects in different mass or volume amounts – birch pollen extract vs 
grass pollen extract (measured in SQ-U; standardized quality units), retinol vs 
betacarotene (measured in RE, retinol equivalents), human insulin vs insulin 
analogues (measured in IU, international units).

To be able to specify medication strength in a meaningful way, I need a 
numerator (amount active substance) and a denominator (amount helper 
substance). The numerator can be a mass (such as mg), a volume (such as ml) or 
an arbitrary unit (such as IU). The denominator can be a volume, a mass or an 
administration unit (such as tablet or puff). Since there can be approximately 
a million different variations on mass, volume and arbitrary units, I don’t 
want to specify them all in the archetype, but leave it up to the application, 
while still specifying the property (mass, volume or arbitrary). At the moment, 
I can’t do this for the arbitrary units element, since there’s no property in 
the openEHR units properties terminology set for arbitrary units.

However, I’m starting to wonder if “” really is a misnamed “arbitrary units” property. Anyone know 
the origin of this? IU isn’t a mass unit, so it’s misnamed in any case (see 
https://en.wikipedia.org/wiki/International_unit).

Also, what would be really really neat, is a Quantity data type which could be 
any of a couple of a set of preselected properties (such as for instance mass, 
volume and arbitrary), and not just one fixed property. :o)

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pablo Pazos
Sent: Monday, January 29, 2018 12:37 AM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: RE: Quantities of arbitrary units in openEHR

Hi Silje,

When specifying the property but not the units, any units are allowed. This is 
saying "any units" which is similar to "arbitrary units". We can relax the spec 
to allow non-ucum as units (my interpretation of "any units" is any in ucum and 
compliant with the specified property, while "arbitrary" might be in or not in 
ucum, and compliant with the property).

What do you think?

On Jan 26, 2018 6:01 AM, "Bakke, Silje Ljosland" 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:
Deriving the properties from the codes makes sense when you actually specify 
the codes, but what do you do when you want to specify “this is a 
concentration, but I don’t care about the exact units”?

“Arbitrary unit” has a quite specific meaning, it’s not just a catch-all for 
“new units for which we haven’t got the property defined in the terminology 
yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
I see that IUPAC and IFCC has decided to use the term “procedure defined unit” 
instead of “arbitrary unit”.

Also, does leaving the “property” field out mean that we can have one Quantity 
element with the units Cel, m, kg, ml and [arb'U]?

Regards,
Silje

Fra: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 På vegne av Diego Boscá
Sendt: fredag 26. januar 2018 09:42
Til: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Emne: Re: Quantities of arbitrary units in openEHR

I think there are several potential problems with this, and IMHO we are 
stepping too much on what should be done in a terminology service (We are 
literally talking about a 'public available UCUM service'). You can also ask 
the terminology service what kind of unit code you have. Your implementation 
could answer "arbitrary" for these new units.

In my opinion, saying "here comes a mass unit code" is not much different from 
"here comes a diagnosis code", and we say these in a completely different way 
(a better way, if you ask me).

Also, I'm not a big fan of "arbitrary" property, as feels like a "other" kind 
of terminology code that is potentially dangerous as knowledge or terminology 
advances, thus coexisting 'arbitrary' and 'new shiny type of measurements' all 
mixed up. That's why I also expect these properties to be as derived from the 
codes and not the other way around.

2018-01-26 9:21 GMT+01:00 Sebastian Garde 
<sebastian.ga...@oceaninformatics.com<mailto:sebastian.ga...@oceaninformatics.com>>:
While I agree with the SPEC-95 rationale (once you have a unit, you should be 
able to know what its property is), it is still convenient to

RE: Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

This sounds good in theory, but I don’t think it’ll help me with my modelling 
in the next couple of weeks? ☺

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Diego Boscá
Sent: Friday, January 26, 2018 10:18 AM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: Quantities of arbitrary units in openEHR

In my mind, this should be done not by fixing a property but by defining a 
constraint reference pointing to the service/set of codes that can provide you 
with all mass units

2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>:
Deriving the properties from the codes makes sense when you actually specify 
the codes, but what do you do when you want to specify “this is a 
concentration, but I don’t care about the exact units”?

“Arbitrary unit” has a quite specific meaning, it’s not just a catch-all for 
“new units for which we haven’t got the property defined in the terminology 
yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
I see that IUPAC and IFCC has decided to use the term “procedure defined unit” 
instead of “arbitrary unit”.

Also, does leaving the “property” field out mean that we can have one Quantity 
element with the units Cel, m, kg, ml and [arb'U]?

Regards,
Silje

Fra: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 På vegne av Diego Boscá
Sendt: fredag 26. januar 2018 09:42
Til: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Emne: Re: Quantities of arbitrary units in openEHR

I think there are several potential problems with this, and IMHO we are 
stepping too much on what should be done in a terminology service (We are 
literally talking about a 'public available UCUM service'). You can also ask 
the terminology service what kind of unit code you have. Your implementation 
could answer "arbitrary" for these new units.

In my opinion, saying "here comes a mass unit code" is not much different from 
"here comes a diagnosis code", and we say these in a completely different way 
(a better way, if you ask me).

Also, I'm not a big fan of "arbitrary" property, as feels like a "other" kind 
of terminology code that is potentially dangerous as knowledge or terminology 
advances, thus coexisting 'arbitrary' and 'new shiny type of measurements' all 
mixed up. That's why I also expect these properties to be as derived from the 
codes and not the other way around.

2018-01-26 9:21 GMT+01:00 Sebastian Garde 
<sebastian.ga...@oceaninformatics.com<mailto:sebastian.ga...@oceaninformatics.com>>:
While I agree with the SPEC-95 rationale (once you have a unit, you should be 
able to know what its property is), it is still convenient to have the property 
for constraining.
Otherwise you don't have a way to say in an archetype: I don't care about the 
exact unit here, but please let it be a "Mass".

-Ursprüngliche Nachricht-
Von: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 Im Auftrag von Thomas Beale
Gesendet: Freitag, 26. Januar 2018 09:13
An: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Betreff: Re: Quantities of arbitrary units in openEHR
Right - at the moment, it is a 'fake' field in archetypes, enabled by being in 
the BMM or other expression of the RM. It's convenient to do this occasionally, 
since we don't think 'property' needs to be a field of DV_QUANTITY - but maybe 
it should be, since for some of the more esoteric units, it's not that clear 
what is being measured.

This trick is also not mentioned in the ADL/AOM specs, and it either should be, 
or we just don't allow it. I don't have a strong opinion either way.

- thomas


On 26/01/2018 07:51, Pieter Bos wrote:
> A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification,
> there is no property attribute or function present in dv_quantity,
> even though the text says it can be conveniently constrained. There is
> a reference to the spec-95 jira issue, which says it has been removed.
> So there’s no way to constrain it - unless the specification contains
> a mistake :)
>
> It is present in the BMM variants of the RM though, as a mandatory field.
>
> Regards,
>
> Pieter Bos
>


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

RE: Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

Deriving the properties from the codes makes sense when you actually specify 
the codes, but what do you do when you want to specify “this is a 
concentration, but I don’t care about the exact units”?

“Arbitrary unit” has a quite specific meaning, it’s not just a catch-all for 
“new units for which we haven’t got the property defined in the terminology 
yet”: https://en.wikipedia.org/wiki/Arbitrary_unit
I see that IUPAC and IFCC has decided to use the term “procedure defined unit” 
instead of “arbitrary unit”.

Also, does leaving the “property” field out mean that we can have one Quantity 
element with the units Cel, m, kg, ml and [arb'U]?

Regards,
Silje

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Diego Boscá
Sendt: fredag 26. januar 2018 09:42
Til: For openEHR technical discussions 
Emne: Re: Quantities of arbitrary units in openEHR

I think there are several potential problems with this, and IMHO we are 
stepping too much on what should be done in a terminology service (We are 
literally talking about a 'public available UCUM service'). You can also ask 
the terminology service what kind of unit code you have. Your implementation 
could answer "arbitrary" for these new units.

In my opinion, saying "here comes a mass unit code" is not much different from 
"here comes a diagnosis code", and we say these in a completely different way 
(a better way, if you ask me).

Also, I'm not a big fan of "arbitrary" property, as feels like a "other" kind 
of terminology code that is potentially dangerous as knowledge or terminology 
advances, thus coexisting 'arbitrary' and 'new shiny type of measurements' all 
mixed up. That's why I also expect these properties to be as derived from the 
codes and not the other way around.

2018-01-26 9:21 GMT+01:00 Sebastian Garde 
>:
While I agree with the SPEC-95 rationale (once you have a unit, you should be 
able to know what its property is), it is still convenient to have the property 
for constraining.
Otherwise you don't have a way to say in an archetype: I don't care about the 
exact unit here, but please let it be a "Mass".

-Ursprüngliche Nachricht-
Von: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org]
 Im Auftrag von Thomas Beale
Gesendet: Freitag, 26. Januar 2018 09:13
An: 
openehr-technical@lists.openehr.org
Betreff: Re: Quantities of arbitrary units in openEHR
Right - at the moment, it is a 'fake' field in archetypes, enabled by being in 
the BMM or other expression of the RM. It's convenient to do this occasionally, 
since we don't think 'property' needs to be a field of DV_QUANTITY - but maybe 
it should be, since for some of the more esoteric units, it's not that clear 
what is being measured.

This trick is also not mentioned in the ADL/AOM specs, and it either should be, 
or we just don't allow it. I don't have a strong opinion either way.

- thomas


On 26/01/2018 07:51, Pieter Bos wrote:
> A bit unrelated perhaps, but in the 1.0.3 and 1.0.4 RM specification,
> there is no property attribute or function present in dv_quantity,
> even though the text says it can be conveniently constrained. There is
> a reference to the spec-95 jira issue, which says it has been removed.
> So there’s no way to constrain it - unless the specification contains
> a mistake :)
>
> It is present in the BMM variants of the RM though, as a mandatory field.
>
> Regards,
>
> Pieter Bos
>


___
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



--

[VeraTech for Health SL]

[Twitter]   [LinkedIn]  
  [Maps]  

[https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 961071863 / +34 
627015023
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman parte de 
un fichero titularidad de VeraTech for Health SL (CIF B98309511) cuya finalidad 
es la de mantener el contacto con usted. Conforme a La Ley Orgánica 15/1999, 
usted puede ejercitar sus derechos de acceso, rectificación, 

RE: Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

Hi all, thanks for your replies!

I'm sure the CKM would accept the unit string, but which property would the 
Quantity have? Eg property = <[openehr::124]> for weight or property = 
<[openehr::127]> for temperature? I don't think we have one of those codes for 
"Arbitrary"?

I'm sure you're correct about the syntax, btw. :)

Regards,
Silje

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Sebastian Garde
Sendt: torsdag 25. januar 2018 11:03
Til: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Emne: AW: Quantities of arbitrary units in openEHR

Hi Silje,

I think this may 'just' be a modelling tooling issue, openEHR itself supports 
this ok.

Speaking for CKM, if you upload an archetype with this to CKM, it should 
validate the UCUM unit correctly for [arb'U]{whatever}.
However, [arb'u]{whatever} or similar is (very slightly) incorrect in my 
understanding:


  1.  Use the completely vertical ' not ' or similar (at least that is my 
understanding).
  2.  openEHR uses (implicitly I think, but it may be hidden somewhere in the 
spec), the case-sensitive version of UCUM - therefore the U needs to be upper 
case, see e.g. http://unitsofmeasure.org/ucum.html#para-45

Regards
Sebastian

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Thomas Beale
Gesendet: Donnerstag, 25. Januar 2018 10:25
An: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Betreff: Re: Quantities of arbitrary units in openEHR


Hi Silje,

I don't understand how adding an 'Arbitrary' term to the openEHR terminology 
helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange units 
just turn up in the String form you quoted for UCUM arbitrary units in that 
field?

(BTW, to ask for a new terminology term, just create a new issue on the PR 
tracker with component=New Term Request - choose this from the dropdown).

Setting property and not units makes sense - and if we had a proper, 
standardised units service, a runtime archetype evaluator would use it to limit 
the actual units for property = pressure (say) to only pressure units. I think 
we need to define such a service properly....

- thomas

On 24/01/2018 09:52, Bakke, Silje Ljosland wrote:
Hi all,

I'm working on representing medication strengths in archetypes at the moment. 
Most medications are thankfully measured in SI units such as mg/ml or mg/{dose 
unit}, but others use arbitrary units that are not derived from any other 
physical dimensional units. Examples of these are standardized quality units 
(SQ-U), focus forming units (FFU), European and American pharmacopoeia units, 
anti factor Xa units, or international units (IU). There are seemingly an 
unlimited number of these units, and they apparently make up new ones as they 
go along (ref: SQ-T and SQ-HDM). See 
http://unitsofmeasure.org/ucum.html#para-45 for more.

UCUM has a generic way of representing these, as "[arb'u]{whatever}" (arbitrary 
unit, name of the unit), but openEHR doesn't seem to have a property in its 
Quantity data type for them. Could it be a possibility to add an "Arbitrary" 
property to the openEHR support terminology for unit properties?

Also, is it ok to model Quantity elements with a property set but the units 
left unconstrained? I've just started trying to add these units to an archetype 
(as a concentration, so got around the property issue), and it's just a never 
ending task.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org>

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Team, Intermountain 
Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR 
Foundation<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer 
Society<http://www.bcs.org/category/6044>
Health IT blog<http://wolandscat.net/> | Culture 
blog<http://wolandsothercat.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Quantities of arbitrary units in openEHR

[Bakke, Silje Ljosland]

Hi all,

I'm working on representing medication strengths in archetypes at the moment. 
Most medications are thankfully measured in SI units such as mg/ml or mg/{dose 
unit}, but others use arbitrary units that are not derived from any other 
physical dimensional units. Examples of these are standardized quality units 
(SQ-U), focus forming units (FFU), European and American pharmacopoeia units, 
anti factor Xa units, or international units (IU). There are seemingly an 
unlimited number of these units, and they apparently make up new ones as they 
go along (ref: SQ-T and SQ-HDM). See 
http://unitsofmeasure.org/ucum.html#para-45 for more.

UCUM has a generic way of representing these, as "[arb'u]{whatever}" (arbitrary 
unit, name of the unit), but openEHR doesn't seem to have a property in its 
Quantity data type for them. Could it be a possibility to add an "Arbitrary" 
property to the openEHR support terminology for unit properties?

Also, is it ok to model Quantity elements with a property set but the units 
left unconstrained? I've just started trying to add these units to an archetype 
(as a concentration, so got around the property issue), and it's just a never 
ending task.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

RE: Problem with creating medication order with Template designer

[Bakke, Silje Ljosland]

Some earlier revisions of these archetypes in the CKM contained this 
unnecessary constraint:
http://openehr.org/ckm/#showArchetype_1013.1.2246_9 (CLUSTER.timing_repetition)
http://openehr.org/ckm/#showArchetype_1013.1.2245_13 (CLUSTER.timing_daily)

This originated from editing the archetypes using the Marand ADL Designer to be 
able to add the DV_INTERVAL data type, which the Ocean Archetype 
Editor doesn’t support. Apparently, the Marand tool adds these valid but 
unnecessary “existence” contstraint statements. We’ve since removed them from 
the archetypes, so Template Designer shouldn’t have trouble with the latest 
published revision of the archetypes from the CKM.

Regarding the interval of duration data type, it turned out Ocean Template 
Designer didn’t support it either, leading to those data types being removed 
again until either the Template Designer is patched to support it, or the ADL 
Designer is released publicly.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Sebastian Garde
Sent: Tuesday, December 19, 2017 8:56 AM
To: For openEHR technical discussions 
Subject: AW: Problem with creating medication order with Template designer

Hi,

There are unnecessary existence constraints in the archetype, e.g.

value existence matches {0..1}

While I don’t think that this is technically wrong, this constraint is 
superfluous as it doesn’t constrain anything.
This may be what Template Designer is having problems with…just try to remove 
any occurrence of “existence matches {0..1}” in the archetype.
Or, if you can, use the archetypes from CKM, they don’t have this “constraint”.

Regards
Sebastian

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Dileep V S
Gesendet: Dienstag, 19. Dezember 2017 08:39
An: For openEHR technical discussions 
>
Betreff: Re: Problem with creating medication order with Template designer

Thanks Peter,

I am getting the same problem with both timing_daily and timing_repetition. So 
far my efforts to trace the issue has not been successful. I am attaching the 
updated zip file with the offending Archetypes also.

regards

[https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8]

Dileep V S

Founder

HealtheLife Ventures LLP

m:

+91 9632888113

a:

103, Innovation Centre, IIIT, Electronics City, Bangalore 560100

w:

healthelife.in  e: 
dil...@healthelife.in


On Tue, Dec 19, 2017 at 11:59 AM, Peter Gummer 
> wrote:
Hi Dileep,

According to the error message, the problem is with the timing_repetition 
archetype. The error says that it has an unexpected attribute: existence.

Your zip file doesn’t contain this archetype so I can’t take a look at it 
myself, but it should be easy to find the existence attribute.

Regards,
Peter


On 19 Dec 2017, at 16:53, Dileep V S 
> wrote:

Hi,

I am trying to create a medication order template using Template designer and 
am getting  an error while trying to add openEHR-EHR-CLUSTER.timing_daily.v0 
and openEHR-EHR-CLUSTER.timing_repetition.v0. More details along with the 
screenshot of the error in the attached file. I am also attaching the template 
file set for reference.

I looked at the offending Archetypes, but could not find any problem. If any of 
you have faced similar problems before, pls point me in the right direction to 
find a solution.

Thanks in advance for your help


___
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: Using aql for data set in DV_CODED_TEXT

[Bakke, Silje Ljosland]

Hi Dileep!

Functionality like you describe should be part of the application 
implementation, not the archetype.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Dileep V S
Sent: Wednesday, July 5, 2017 2:23 PM
To: For openEHR technical discussions 
Subject: Using aql for data set in DV_CODED_TEXT

HI,
I am just wondering if it is possible to embed an AQL into the archetype so 
that the data set for a DV_CODED_TEXT is formed out of existing compositions.
For example, a hospital registration form that asks for a person's allergies. 
Instead of an empty field, it can be populated from existing data through a 
query so that the front desk can just validate the data. Can this be modeled 
into the archetype? Or should it be an implementation detail?
regards
[https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8]

Dileep V S

Founder

HealtheLife Ventures LLP

m:

+91 9632888113

a:

103, Innovation Centre, IIIT, Electronics City, Bangalore 560100

w:

healthelife.in  e: 
dil...@healthelife.in


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

Re: openEHR UML website updated to latest

[Bakke, Silje Ljosland]

Does this have anything to do with this tweet?

https://twitter.com/er453r/status/873089634602962944


Sendt fra min Samsung Galaxy-smarttelefon.


 Opprinnelig melding 
Fra: Thomas Beale 
Dato: 08.06.2017 20:10 (GMT+01:00)
Til: Openehr-Technical 
Emne: openEHR UML website updated to latest


The 'UML' link on the home page was pointing to an out of date copy of the 
openEHR UML web portal. This has 
now been updated to the latest, and includes AM, RM, BMM and BASE components.

Click on the Diagrams link and you will see this.

[cid:part2.E79BE9A5.3B7D225F@openehr.org]

The diagrams are all from MagicDraw, and are the same as those in the 
specifications. MagicDraw files (which contain orthodox XMI 2.x files) are all 
findable from the pages under the 'Specifications' heading, on the main specs 
jump page.

- thomas

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Team, Intermountain 
Healthcare
Management Board, Specifications Program Lead, openEHR 
Foundation
Chartered IT Professional Fellow, BCS, British Computer 
Society
Health IT blog | Culture 
blog
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: openEHR-technical Digest, Vol 64, Issue 6

[Bakke, Silje Ljosland]

I agree and disagree. ☺

An EHR needs to be able to cope with all kinds of data, “questionnaire” or not. 
However I’m not so sure a modelling pattern that works for everything that 
could be labelled a “questionnaire” is achievable, or even useful.

Modelling patterns are sometimes extremely useful, for instance for 
facilitating modelling by non-clinicians or newbies, but sometimes they aren’t 
very practical. One of the problems is that clinical information in itself is 
messy, because healthcare information doesn’t follow nice semantic rules. 
Clinical modelling must above all be faithful to the way clinicians need to 
record and use data, not to a notion of semantically “pure” models.

Finding “sweet spots” by identifying patterns that are sensible, logical, and 
above else *work* for recording actual clinical information is often an 
excruciatingly slow process of trial and error, exemplified by the substance 
use summary EVALUATION and the physical examination CLUSTER patterns of 
modelling, which both had taken years of trial and error long before I got 
involved in them.

If we can find patterns across some kinds of “questionnaires”, like clinical 
scores, great! However, since there isn’t a standardised pattern for paper 
questionnaires, it’s not likely that it’s possible to make one for electronic 
questionnaires. Outside the RM/AOM, a generic pattern archetype for every 
questionnaire with variable levels of nesting, variable data points, etc isn’t 
possible, nor would it in my opinion be useful. It would put all the modelling 
load on the template modellers, which arguably would be more work than 
modelling the same structures as made-for-purpose archetypes.

Some rules of thumb have developed over time though:

1.   Model the score/assessment/questionnaire in the way that best 
represents the data

2.   Use the most commonly used name for identifying it

3.   Model them as OBSERVATION archetypes, unless they’re *clearly* 
attributes of f.ex. diagnoses, in which case they should be CLUSTERs (example: 
AO classification of fractures)

4.   Make sure to get references that support the chosen structure and 
wording into the archetypes

In my opinion this pragmatic approach is likely to capture the data correctly, 
while at the same time minimising overall modelling workload.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of GF
Sent: Tuesday, June 6, 2017 3:58 PM
To: For openEHR clinical discussions 
Cc: Thomas Beale 
Subject: Re: openEHR-technical Digest, Vol 64, Issue 6

I agree.
‘questionnaire’ is many things, but not at the same time.

In any case any EHR needs to be able to cope with all kinds.
From ones with one or more qualitative results: such as the checklist
To the validated Score where individual results are aggregated in one total 
score.

It must be possible to create one pattern that can deal with all kinds.


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

On 6 Jun 2017, at 14:46, Vebjørn Arntzen 
> wrote:

Hi all

To me a "questionnaire" is a vague notion. There can be a lot of different 
"questionnaires" in health. From the GP's in Thomas's example to a Apgar score, 
to a clinical guideline and even a checklist. Those are all a set of "questions 
and answers", but the scope and use is totally different. In paper 
questionnaires we will find a mix of many, maybe all, of those, crammed into 
what the local practice have found to be useful (= "Frankenforms"). To try to 
put all of them into a generic questionnaire-archetype is of no use.

Examples:
The GP questionnaire referred to by Thomas is in the quoted question about 
"ever had heart trouble" merely a help for the GP, and of little use for 
computation. But if it is supplemented by more specific questions, based on 
answers by the individual, then the final result can be "occasional arrhythmia 
with ventricular ectopics", which is a relevant information for later use and 
should be put into a relevant archetype. So is it a "questionnaire" or a 
guideline for the consultation? Not relevant IMO, it's the content, that's 
relevant.

Patients with haemophilia in Oslo university hospital are offered a 
questionnaire online to register whether they've had incidents of bleeding, 
what caused it, if they needed medications and if so, the batchnumber of the 
medication. This is followed up by the staff both for reporting of used 
medication, and for the patients next follow-up out-patient control or 
admission. Questionnaire or not? Not relevant – it's what the information is 
and what it is for, that is important. Find relevant archetypes for them, 
OBSERVATIONS or ADMIN-ENTRY for this, I guess.

Even checklists are a set of questions and answers. "Have you remembered to 
fill 

RE: Use of RM:provider

[Bakke, Silje Ljosland]

Hi Bjørn and Ian!

The original use case for this code set was adverse reactions, but with the 
development of the national summary records, it’s been expanded for use with 
other kinds of critical information as specified below. This means that it 
needs to be used across the adverse reaction risk, problem/diagnosis and 
precaution archetypes, and I think therefore making a new cluster for use in 
the Extension slots is the best way to go forward.

@Ian: Yes, this information is mandatory for each entry. They’re generally few 
and seldom changed, so I don’t think there’s too much overhead from this:
[cid:image001.png@01D271A4.637D58A0]
Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Wednesday, January 18, 2017 12:33 PM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: Use of RM:provider

Hi Bjorn,

Thanks - it makes much more sense in the context of Adverse reaction but TBH I 
still doubt very much if this 'provenance' source metadata is captured or known 
reliably. I asked a couple of UK GP colleagues and they agreed. I would argue 
that this data a) often not available b) unreliable c) a pain in the neck to 
manage and d) not something you ever want to do decision support on.

If an allergy has been asserted, it needs to be regarded as positive and kick 
decision support into life, no matter how vague the provenance or potentially 
unreliable the witness.

But hey, that's what the extension slot in the archetype is for :)

Ian

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

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

On 18 January 2017 at 10:24, Bjørn Næss <b...@dips.no<mailto:b...@dips.no>> 
wrote:
Hi
The specified terminology ( OID 2.16.578.1.12.4.1.7498 (Source of information) 
) is defined as  “options to specify the source of data for an allergic 
reaction” (my translation).

Which means this is specific for adverse reaction – and I think it should be 
archetyped to model this requirement. If it is only national then there should 
be some extension slots in the Archetypes – or we need some specialization of 
the Archetype to handle this.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>

Fra: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 På vegne av Ian McNicoll
Sendt: tirsdag 17. januar 2017 13.43
Til: For openEHR technical discussions 
<openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>>
Emne: Re: Use of RM:provider

Hi Thomas,

I'm not convinced as yet that this is a universally useful requirement, 
particularly as we carry much of this source/ provenance metadata already.

@Silje - are the GPs expected to add this extra information to every Entry in 
the summary? That seems like a significant burden, and actually in many cases 
unknowable.

Ian



Dr Ian McNicoll
mobile +44 (0)775 209 7859<tel:07752%20097859>
office +44 (0)1536 414994<tel:01536%20414994>
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

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

On 17 January 2017 at 12:34, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:



Ideally there would be one or more classifiers at the ENTRY level, something 
that does not exist today. There are some others that we will include, e.g. 
relating to epistemic_status.

I would follow Ian's suggestion on the extension slot; it may be that the 
coding recorded there may need to be adjusted to a new place in relevant 
archetypes later on. Not ideal, but not a big problem either, assuming they are 
not used to create data before that is done.

Ian - do we have a related PR mooted for RM Release-1.0.4?

- thomas

On 17/01/2017 11:22, Bakke, Silje Ljosland wrote:
Thank you Thomas and Ian!

This is indeed a national requirement, and one where we do need to represent 
the chosen value in a coded text element. The background here is an entry in 
the critical information part of the national summary record, ie an adverse 
reaction, complication from

RE: Runtime name suggestions?

[Bakke, Silje Ljosland]

Thanks! If I knew the syntax I could hack the ADL and test how TD handles it. ☺

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Tuesday, January 17, 2017 12:17 PM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: Runtime name suggestions?

Hi Silje

As Thomas has noted, it is possible in adl but is not supported in archetype 
editor. That is probably fixable but I'm not sure currently how template 
designer would handle it.

Ian
On Tue, 17 Jan 2017 at 11:03, Bakke, Silje Ljosland 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:
Thank you Thomas, to the extent I understand the ADL, this looks like what 
we’re looking for. How would the corresponding syntax look in ADL 1.4?

Regards,
Silje

From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 On Behalf Of Thomas Beale
Sent: Tuesday, January 17, 2017 11:50 AM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: Runtime name suggestions?


Hi Silje,

I'm not sure enough of the requirement, but this ADL 
logic<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_reference_model_type_refinement>
 may be what you are looking for. See the DV_TEXT/DV_CODED_TEXT just before the 
following heading after that section.
The basic logic of this is described 
here<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_narrowed_subtype_constraints>.

Although these are references from ADL2, they should apply in ADL 1.4 as well.

- thomas
On 17/01/2017 07:49, Bakke, Silje Ljosland wrote:
Hi,

We’re trying to finalise the pattern for exclusion archetypes, and would like 
to use the element names to carry some flavor differences such as “no known 
history of …” and “no evidence of …”. We’ve considered adding a runtime name 
constraint to make some level of standardization of these statements, but at 
the same time we recognize that there will be considerable variation in what 
will be required as statements in different use cases. So what we’d like to do 
is to use a kind of “optional runtime name constraint”, or “runtime name 
suggestion”. We know this isn’t supported by tooling atm, but is it allowed by 
the specs? If so, how can it be done?


Kind regards,
Silje Ljosland Bakke


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto: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: Use of RM:provider

[Bakke, Silje Ljosland]

Thank you Thomas and Ian!

This is indeed a national requirement, and one where we do need to represent 
the chosen value in a coded text element. The background here is an entry in 
the critical information part of the national summary record, ie an adverse 
reaction, complication from anaesthesia, critical condition, ongoing treatment, 
implant, change of treatment routine, or infection. Each of these will be 
either an EVALUATION.adverse_reaction_risk, EVALUATION.problem_diagnosis, or 
EVALUATION.precaution. The patient’s GP normally records the information, and 
this code set is supposed to be used to specify where the GP got the 
information about each of the entries from.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Tuesday, January 17, 2017 11:36 AM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: Use of RM:provider

Hi Silje,

I would agree with your and Thomas's assessment. This codeset does not really 
fit with provider, or indeed with any other RM attributes, although many but 
not all of these items could be calculated/ derived from existing attributes.

I guess this is part of a national requirement, and is a similar issue to the 
one we faced in Sweden, where the V-TIM standard was largely aligned with 
openEHR but had some extra specific metadata around Contsys-2 that needed to be 
captured.

This was exactly the purpose for the Extension slot that we are adding to new 
archetypes, so that would be my suggestion. Having said that, I do wonder about 
the purpose of this data -where is the value, over and above what is already 
captured by native openEHR RM. This feels like largely a derived set of data 
for reporting purposes

e,g,



1. Result of test/analysis

We know that from the archetype name

2.   Observed by treating physician

Captured potentially by provider

3.   Patient’s own information
Party = Self

4.   Information from next of kin
Party = carer

5.   Obtained from other records

Can use Feed_audit but practically very difficult to manage.

6.   Other

7.   Reported by responsible clinician

Captured by composer

Can you tell us more about the background?



Ian

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

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

On 17 January 2017 at 10:14, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:

Hi Silje,

there is no immediate equivalent of these codes, which have indirect 
equivalents, i.e.

  1.  Result = OBSERVATION; provider = lab; limited to certain archetypes; also 
comes under SOAP 'O' Heading
  2.  Observed by physician = OBSERVATION, provider = PARTY_IDENTIFIED 
(physician); limited to certain archetypes; also comes under SOAP 'O' Heading
  3.  Patient information = OBSERVATION, with provider = PARTY_SELF, possibly 
limited to specific archetypes ; also comes under SOAP 'S' heading
  4.  Info from next of kin = OBSERVATION, with provider = PARTY_IDENTIFIED 
(next of kin)
  5.  Info from other records = any ENTRY, with FEEDER_AUDIT set appropriately
  6.  ??
  7.  Reported by responsible clinician could be 1, 2, most EVALUATIONs, 
most/all INSTRUCTIONs some or many ACTIONs; provider = PARTY_IDENTIFIED 
(clinician)

I'd say it can be mostly set by using ENTRY.provider. 5 is a different thing - 
it's about provenance of data obtained from elsewhere. Presumably 6 means 'not 
any of 1-5 or 7'.

I'd also say it isn't a very well designed code-set, and I don't know what use 
it would be in real life...

- thomas

On 16/01/2017 13:14, Bakke, Silje Ljosland wrote:
Hi everyone,

I’ve got a problem about where to put non-identifying information about the 
source of information for an ENTRY. The value set we need to store is the code 
set identified by the OID 2.16.578.1.12.4.1.7498 (Source of information), as 
following:


1.   Result of test/analysis

2.   Observed by treating physician

3.   Patient’s own information

4.   Information from next of kin

5.   Obtained from other records

6.   Other

7.   Reported by responsible clinician

Our first hypothesis was that the reference model element “provider” should be 
used for this, but then someone pointed out that the “provider” should be an 
identifiable person or entity, and not just a generalised coded text like this. 
So, where should this information go, if not in RM:provider?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National 

RE: Runtime name suggestions?

[Bakke, Silje Ljosland]

Thank you Thomas, to the extent I understand the ADL, this looks like what 
we're looking for. How would the corresponding syntax look in ADL 1.4?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Tuesday, January 17, 2017 11:50 AM
To: openehr-technical@lists.openehr.org
Subject: Re: Runtime name suggestions?


Hi Silje,

I'm not sure enough of the requirement, but this ADL 
logic<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_reference_model_type_refinement>
 may be what you are looking for. See the DV_TEXT/DV_CODED_TEXT just before the 
following heading after that section.
The basic logic of this is described 
here<http://www.openehr.org/releases/AM/latest/docs/ADL2/ADL2.html#_narrowed_subtype_constraints>.

Although these are references from ADL2, they should apply in ADL 1.4 as well.

- thomas
On 17/01/2017 07:49, Bakke, Silje Ljosland wrote:
Hi,

We're trying to finalise the pattern for exclusion archetypes, and would like 
to use the element names to carry some flavor differences such as "no known 
history of ..." and "no evidence of ...". We've considered adding a runtime 
name constraint to make some level of standardization of these statements, but 
at the same time we recognize that there will be considerable variation in what 
will be required as statements in different use cases. So what we'd like to do 
is to use a kind of "optional runtime name constraint", or "runtime name 
suggestion". We know this isn't supported by tooling atm, but is it allowed by 
the specs? If so, how can it be done?


Kind regards,
Silje Ljosland Bakke


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

Runtime name suggestions?

[Bakke, Silje Ljosland]

Hi,

We're trying to finalise the pattern for exclusion archetypes, and would like 
to use the element names to carry some flavor differences such as "no known 
history of ..." and "no evidence of ...". We've considered adding a runtime 
name constraint to make some level of standardization of these statements, but 
at the same time we recognize that there will be considerable variation in what 
will be required as statements in different use cases. So what we'd like to do 
is to use a kind of "optional runtime name constraint", or "runtime name 
suggestion". We know this isn't supported by tooling atm, but is it allowed by 
the specs? If so, how can it be done?


Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

Use of RM:provider

[Bakke, Silje Ljosland]

Hi everyone,

I've got a problem about where to put non-identifying information about the 
source of information for an ENTRY. The value set we need to store is the code 
set identified by the OID 2.16.578.1.12.4.1.7498 (Source of information), as 
following:


1.   Result of test/analysis

2.   Observed by treating physician

3.   Patient's own information

4.   Information from next of kin

5.   Obtained from other records

6.   Other

7.   Reported by responsible clinician

Our first hypothesis was that the reference model element "provider" should be 
used for this, but then someone pointed out that the "provider" should be an 
identifiable person or entity, and not just a generalised coded text like this. 
So, where should this information go, if not in RM:provider?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

RE: RM Participations name/role?

[Bakke, Silje Ljosland]

Hi, thanks for your replies everyone! I think the function attribute is 
sufficient for our use case, as the focus is on what the person did. Their 
profession/credentials can be provided by an external knowledge base.

BTW, I tried looking this up using the UML link from the CKM, which led me 
here: 
http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_0_76d0249_1109066119163_537311_2210Report.html.
 I then tried to follow the List link to 
http://www.openehr.org/releases/1.0.1/reference-models/openEHR/UML/HTML/Browsable/_9_5_76d0249_1118914287896_171737_4134Report.html,
 which gave me a 404.

Mvh.
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Thursday, November 24, 2016 9:49 AM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: RM Participations name/role?

Hi David,

I think your approach is perfectly valid but I suspect would impose an overhead 
of complexity that is not always justified or necessary.

In the original lab system the kind of individual entry tracking you suggest is 
probably required to facilitate workflow but by the time it hits the ehr, that 
level of granularity is not needed IMO.

Another good example of the way the health data is summarised and compressed as 
it passes through the system.

Both approaches are valid IMO.

Ian
On Thu, 24 Nov 2016 at 08:18, David Moner 
<dam...@gmail.com<mailto:dam...@gmail.com>> wrote:
Hi,

I'm not sure if this is a correct approach. What in the example you call a 
function can be in fact a full Action that is being done. That is, if the 
function is so relevant that you can even assign a dedicated participant to it, 
it should be also enough important to be represented and documented as an 
individual entry of the EHR: coded, with start and end times, etc. If the case 
is that a complex procedure is composed by other simpler procedures, then we 
should document and link all of them.

I see the case of Silje from a different perspective. What she is asking is if 
we can document the participants of each Element inside the Entry. So far this 
is not possible, as Entries have been always seen as a whole clinical 
statement, with all participants assigned to that level.

2016-11-23 20:47 GMT+01:00 Ian McNicoll 
<i...@freshehr.com<mailto:i...@freshehr.com>>:
Hi both

Agreed.

Role = pathologist
Function = macroscopic histopath examination.

Ian.
On Wed, 23 Nov 2016 at 17:32, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:

Hi Silje,

The PARTICIPATION 
class<http://www.openehr.org/releases/RM/latest/docs/common/common.html#_overview_3>
 has a codable attribute 'function' for this purpose (calling it 'function' 
rather than 'role' came from 13606). It may be that you want to state a 'role' 
as well, i.e. to say that a certain kind of person is required, and then use 
function to state the actual function that person is supposed to do in the 
particular activity in question.
I would have expected 'function' to be sufficient for your example - just use 2 
x other_participations on the OBSERVATION.

An example of needing both could be something like:

  *   role = nurse
  *   function = foley catheterisation

Currently 'role' is only known in the demographic model, i.e. on the other side 
of the PARTY_PROXY.external_ref link. It may make sense to add a role attribute 
to PARTICIPATION at some point if we need to distinguish the type of person 
(qualification) from what they do in the activity.

- thomas

On 23/11/2016 06:29, Bakke, Silje Ljosland wrote:
Hi,

We’re wondering if it’s possible to specify what the role was of each instance 
of Participation in an OBSERVATION archetype? For instance in a histopathology 
result the macroscopic description will often be performed by a different 
person from the microscopic description. We’re thinking both will be listed 
using participation, but we need to be able to document which person did what.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298<tel:%2B47%2040203298>
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>



___

openEHR-technical mailing list

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

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.or

RM Participations name/role?

[Bakke, Silje Ljosland]

Hi,

We're wondering if it's possible to specify what the role was of each instance 
of Participation in an OBSERVATION archetype? For instance in a histopathology 
result the macroscopic description will often be performed by a different 
person from the microscopic description. We're thinking both will be listed 
using participation, but we need to be able to document which person did what.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

RE: UCUM code in body temperature archetype

[Bakke, Silje Ljosland]

Ah yes, that's definitely not right. There are actually two blood glucose 
archetypes, and the other one has 'IU' (which should be [iU]).

Probably all of the current OBSERVATION.lab_test* and 
OBSERVATION.pathology_test* archetypes should be deprecated and (some of them) 
redone as either cluster extensions or specialisations of the newer 
OBSERVATION.laboratory_test archetype.

I think it would be very useful if you would be willing to proof read my 
Archetype Editor units file if we can ever get it into a form that the AE will 
accept. :)

Regards,
Silje


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Eric Browne
Sent: Wednesday, May 18, 2016 4:30 PM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Re: UCUM code in body temperature archetype

Hi Silje,

'U' is used in the lab_test-blood_glucose archetype.

I also think that 10*12/l, 10*6/l, 10*6/mm3, 10*9/l are all valid UCUM codes. 
In fact UCUM's table 26 Example Unit Terms by Term lists 10*6/mm3 as legal with 
a preferred alternative of /pL . It also lists the following alternatives:-

10*3/L  =  /mL
10*6/L  =  /uL
10*9/L  =  /nL

with all 6 codes being valid.

regards,
eric

> On 18 May 2016, at 11:43 pm, Bakke, Silje Ljosland 
> <silje.ljosland.ba...@nasjonalikt.no> wrote:
> 
> Hah, thanks for that correction, I completely missed the '0' instead 
> of 'O' and the 'mho'. J
>  
> 'U' is certainly wrong if used for international units, as you say, but for 
> the liver tests ALP, ALT, AST, GGT and LD the test is actually measuring 
> catalytic activity, so U/L should be correct. Not sure where 'U' by itself is 
> used.
>  
> Regards,
> Silje
>  
> -Original Message-
> From: openEHR-technical 
> [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Eric 
> Browne
> Sent: Wednesday, May 18, 2016 3:49 PM
> To: For openEHR technical discussions 
> <openehr-technical@lists.openehr.org>
> Subject: Re: UCUM code in body temperature archetype
>  
> Unfortunately Silje, not quite correct. The eye deceiveth.
>  
> The construct [H20]  is not valid UCUM. In none of the CKM archetypes did I 
> find the correct UCUM code [H2O]. A zero has been substituted for the letter 
> 'O'.
> An easy mistake for a human to make. H20 even mistakenly appears 4 times in 
> Appendix D Example Unit Terms at http://unitsofmeasure.org/ucum.html.
>  
> The same is likely to occur in the case of Litre, with 'l' (lowercase 
> L) vs '1' (numeral one) vs 'I' (capital letter eye), depending on 
> typefaces used. That's why many health safety organisations favour 'L'  
> for Litre over the lowercase variant. UCUM unfortunately allows either 
> as case sensitive variants ( which strictly means that this particular 
> unit is not case sensitive in the case sensitive case)  :-(
>  
> Also, despite 'U'  being a valid UCUM unit, it is probably incorrectly used 
> in the CKM archetypes. The correct UCUM unit code for international unit 
> should be "[iU]" or "[IU]" - another case of case variants for supposedly 
> case-sensitive units. 'U' is the UCUM code for catalytic activity. Same 
> applies for 'U/l', which may be valid UCUM syntactically, but unlikely to be 
> correct semantically in the liver function test archetype.
>  
> Also mmho is correct UCUM. A mho is a unit of electrical conductance ( 
> It comes from Ohm, the unit for resistance, spelt backwards. Ohm 
> starts with a capital letter since named after a human, whereas mho 
> does not). mho as been deprecated as an SI unit and renamed to 
> siemens, but is retained and valid in UCUM. mmho was found in 
> openEHR-EHR-OBSERVATION.tympanogram_hf.v1.adl
>  
>  
>  
>  
> regards,
> eric
>  
>  
>  
> > On 18 May 2016, at 10:05 pm, Bakke, Silje Ljosland 
> > <silje.ljosland.ba...@nasjonalikt.no> wrote:
> > 
> > Awesome! These can be classified into UCUM, non-UCUM and just plain wrong:
> > 
> > UCUM:
> > 1/min, Hz, Hz/s, U, U/l, cm2, cm[H20], d, daPa, daPa/s, deg, h, kHz, 
> > kPa, kg, kg/m2, l, l/min, l/s, m, m2, mV, mg, mg/dl, mg/l, min, ml, 
> > ml/d, ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], 
> > mmol/l, pg, pmol/l, s,
> > 
> > Non-UCUM:
> > /d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3, 
> > 10*9/l, , IU, cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l, 
> > millisec, oz(avdp), °, °C, °F, µmol/
> > 
> > Just plain wrong:
> > gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram") mmho 
> > (supposed to be mm/h or mm.h? Does anyone know which archetype this 
> > comes from?)
> > 
> > Not 100% s

RE: UCUM code in body temperature archetype

[Bakke, Silje Ljosland]

They usually are, though the units file in the Archetype Editor has had (still 
has?) a lot of errors in it, which means the correct units had to be edited 
into the ADL by hand. I made a better version of the units file for the AE a 
while ago, but there were some issues with it that I'm not sure if have been 
solved or if it's made its way into a release.

Regards,
Silje


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Sebastian Garde
Sent: Wednesday, May 18, 2016 2:26 PM
To: For openEHR technical discussions 
Subject: AW: UCUM code in body temperature archetype

Yes, unfortunately. I have even implemented a Validation Check named VUI for 
this in CKM after these discussion, so that this is not forgotten, because I 
too think it is important to get this right... 
This check is available for each archetype (or for all archetypes from 
Reports/Validation Report when logged in).
I think the validation errors are usually fixed when the archetype is updated 
the next time.

Regards
Sebastian


-Ursprüngliche Nachricht-
Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im 
Auftrag von Eric Browne
Gesendet: Mittwoch, 18. Mai 2016 14:00
An: For openEHR technical discussions 
Betreff: Re: UCUM code in body temperature archetype

Dear All,

There are many, many, many archetypes in the various openEHR CKMs that DO NOT, 
I repeat DO NOT, I repeat DO NOT use valid UCUM codes for units in various 
DV_QUANTITY elements. I would guess up to 30% of Observation archetypes have 
some ‘invalid' UCUM unit.

___
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: UCUM code in body temperature archetype

[Bakke, Silje Ljosland]

Awesome! These can be classified into UCUM, non-UCUM and just plain wrong:

UCUM:
1/min, Hz, Hz/s, U, U/l, cm2, cm[H20], d, daPa, daPa/s, deg, h, kHz, kPa, kg, 
kg/m2, l, l/min, l/s, m, m2, mV, mg, mg/dl, mg/l, min, ml, ml/d, ml/ml, ml/s, 
ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmol/l, pg, pmol/l, s, 

Non-UCUM:
/d, /h, /min, /mo, /wk, Ashman units, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, , IU, 
cc, dB, fl, , fl oz, ft, in, in2, lb, lb/in2, mIU/l, millisec, oz(avdp), °, °C, 
°F, µmol/

Just plain wrong:
gm, gm/d, gm/l, gm/wk (gm == "gram meter", not "gram")
mmho (supposed to be mm/h or mm.h? Does anyone know which archetype this comes 
from?)

Not 100% sure:
{Volume/Volume}

So quite a few units in archetypes are actually UCUM-compatible, but there are 
plenty which aren't, and some which are wrong and can be badly misinterpreted.

Oh, and UCUM does allow non-units to be represented using curly braces, like 
{puff} or {tablet} as symbols for the default unit '1'.

Regards,
Silje


-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Eric Browne
Sent: Wednesday, May 18, 2016 2:03 PM
To: For openEHR technical discussions 
Subject: Re: UCUM code in body temperature archetype

I just did a bulk download of 133 Observation archetypes from ckm.openehr.org 
and extracted the following list of units:-

/d, /h, /min, /mo, /wk, 1/min, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, Ashman units, 
Hz, Hz/s, IU, U, U/l, [pH], cc, cm, cm2, cm[H20], d, dB, daPa, daPa/s, deg, fl, 
fl oz, ft, gm, gm/d, gm/l, gm/wk, h, in, in2, kHz, kPa, kg, kg/m2, l, l/min, 
l/s, lb, lb/in2, m, m2, mIU/l, mV, mg, mg/dl, mg/l, millisec, min, ml, ml/d, 
ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmho, mmol/l, 
oz(avdp), pg, pmol/l, s, {Volume/Volume}, °, °C, °F, µmol/ 

I did this with a script and have not manually validated this list visually in 
the ADL.

regards,
eric

Eric Browne
eric.bro...@montagesystems.com.au
ph 0414 925 845
skype: eric_browne


> On 18 May 2016, at 8:35 pm, Thomas Beale  wrote:
> 
> Hi Daniel,
> the reason it is a String is because we have always treated UCUM units as 
> parseable strings. E.g. 
> kg.m^-2
> 
> and
> 
> kg/m^2
> are parseable according to UCUM's grammar into an expression that has a 
> single meaning, and can also be equated to e.g. 'kPa' (which is itself 
> parseable and so on).
> - thomas
> On 18/05/2016 10:05, Daniel Karlsson wrote:
>> So, right now the DV_QUANTITY.units is a String, perhaps it should be 
>> DV_CODED_TEXT?
>> 
>> /Daniel
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.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: UCUM code in body temperature archetype

[Bakke, Silje Ljosland]

Hi Daniel,

You’re 100% correct. This error is corrected in the branch I uploaded after the 
Norwegian body temp archetype was published, but this hasn’t been taken into 
the trunk yet as it contains some other major changes.

As a general observation, an issue with using UCUM units in archetype (which is 
to my mind the only way to go), is that there’s as far as I know no way to 
include both the code and the print symbol in the archetype. This imposes a 
larger implementation burden on the systems who will have to be able to read 
UCUM codes and show the corresponding symbol instead of the code, which in many 
cases is not readable to clinicians.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Daniel Karlsson
Sent: Wednesday, May 18, 2016 10:09 AM
To: openehr-technical@lists.openehr.org
Subject: UCUM code in body temperature archetype

Dear All,

it seems the UCUM code for the temperature units in the Body temperature 
archetype is wrong. It uses the UCUM print symbol, e.g. "°C", rather than the 
UCUM code "Cel".

http://www.openehr.org/ckm/#showArchetype_1013.1.49

Regards,
Daniel


--

Daniel Karlsson, PhD, sr lecturer

Department of Biomedical Engineering/Health informatics

Linköping university

SE-58185 Linköping

Sweden

Ph. +46 708350109, Skype: imt_danka, Hangout: 
daniel.e.karls...@gmail.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Ordinal values without descriptions

[Bakke, Silje Ljosland]

Thanks for your replies everyone! As the scale does have descriptions for 
scores of 0,2, 4 and 6, I don’t think representing this as only a count would 
work. Perhaps Pablo’s suggestion is the best, even though it does mean changing 
the wording of the scale (arguably for the better).

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pazospa...@hotmail.com
Sent: Wednesday, April 27, 2016 2:20 AM
To: Thomas Beale <thomas.be...@openehr.org>; openehr-technical@lists.openehr.org
Subject: Re: Ordinal values without descriptions


Following Thomas, I think for the missing descriptions you might need to put 
"between x and y" if x and y are available descriptions.



Sent from my LG Mobile

-- Original message--

From: Thomas Beale

Date: Tue, Apr 26, 2016 12:42

To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>;

Subject:Re: Ordinal values without descriptions

If you give someone a '3' on the Apparent Sadness scale, what does it mean? 
Apparently it's between 'Looks dispirited but does brighten up without 
difficulty' and 'Appears sad and unhappy most of the time'

So now imagine that this '3' appears for me in my record - just that value. The 
scale doesn't tell you what it means. It probably should have a value like 
'Appears sad quite often' or similar. Instead, I would see nothing at all, and 
maybe I would know to go online and try to understand what 3 means by looking 
at the values for 2 and 4. Even in a paper record, the problem is the same.

At a technical level, the RM will does require a DV_CODED_TEXT. So one question 
is: considering that the set of texts for an ordinal is actually a set of 
terms, what does the term set look like? It must be value set with only 4 
members instead of 7.

Personally I think that scale is not ready for use in paper or electronic 
health record...

- thomas
On 26/04/2016 11:59, Bakke, Silje Ljosland wrote:
2 4 5 3 5 4 6 3 2 4<tel:2%204%205%203%205%204%206%203%202%204>;}@font-face 
{font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 
4<tel:2%2015%205%202%202%202%204%203%202%204>;}/* Style Definitions 
*/p.Ms<http://p.Ms>oNormal, li.Ms<http://li.Ms>oNormal, 
div.Ms<http://div.Ms>oNormal {margin:0cm; margin-bottom:.0001pt; 
font-size:11.0pt; font-family:"Calibri",sans-serif; 
mso-fareast-language:EN-US;}a:link, span.Ms<http://span.Ms>oHyperlink 
{mso-style-priority:99; color:#0563C1; text-decoration:underline;}a:visited, 
span.Ms<http://span.Ms>oHyperlinkFollowed {mso-style-priority:99; 
color:#954F72; text-decoration:underline;}span.EpostStil17 
{mso-style-type:personal-compose; font-family:"Calibri",sans-serif; 
color:windowtext;}..MsoChpDefault {mso-style-type:export-only; 
font-family:"Calibri",sans-serif; mso-fareast-language:EN-US;}@page 
WordSection1 {size:612.0pt 792.0pt; margin:70.85pt 70.85pt 70.85pt 
70.85pt;}div.WordSection1 {page:WordSection1;}-->
Hi everyone,

We’re working on an archetype for the Montgomery-Åsberg Depression Rating Scale 
(MADRS). This scale contains several ordinal values where there is no 
description, and some where there is no text at all. This doesn’t work very 
well in archetypes, and particularly when uploading to a CKM, because there’s 
an expectation that every field should be filled in, and the CKM will replace 
empty fields with * or sometimes *([language code]). Is there any way to get 
around this?

See here for what the MADRS looks like: http://www.psy-world.com/madrs.htm


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

Ordinal values without descriptions

[Bakke, Silje Ljosland]

Hi everyone,

We're working on an archetype for the Montgomery-Åsberg Depression Rating Scale 
(MADRS). This scale contains several ordinal values where there is no 
description, and some where there is no text at all. This doesn't work very 
well in archetypes, and particularly when uploading to a CKM, because there's 
an expectation that every field should be filled in, and the CKM will replace 
empty fields with * or sometimes *([language code]). Is there any way to get 
around this?

See here for what the MADRS looks like: http://www.psy-world.com/madrs.htm

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

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

I think they’re only interested in the specs, not archetypes. And I think the 
point is that it should be possible to learn how the processes work without 
being shown. ☺

Regards,
Silje

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Ian McNicoll
Sendt: 5. april 2016 23:04
Til: For openEHR technical discussions
Emne: Re: CAMSS assessment of openEHR

Just to add. I sense that there is a real difficulty for those involved in the 
reviews in understanding anything other than traditional ISO/CEN type 
standards/specification processes.

Do we have an opportunity to show them how an archetype review process works, 
or to show how the specifications review process works?

Ian

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

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

On 5 April 2016 at 23:01, Ian McNicoll 
<i...@freshehr.com<mailto:i...@freshehr.com>> wrote:
Hi Silje,

Thomas and Erik have answered substantial aspects related to specification 
review.

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

The Clinical content review process and governance structures is documented at:

https://openehr.atlassian.net/wiki/display/healthmod/Archetype+authoring%2C+review+and+publication
https://openehr.atlassian.net/wiki/display/healthmod/Content+publication%2C+terminology+binding+and+language+translations
https://openehr.atlassian.net/wiki/display/healthmod/CKM+Governance+Environment

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)?”

All Clinical content development and approval process is accessed via the 
international CKM tool at openehr.org/ckm<http://openehr.org/ckm>. All reviewer 
and editorial comments, publication decisions and historical versions are 
accessible to registered users (free to register).

The Management Board publishes a monthly update on the foundation news list on 
the web. This is emailed to openEHR Members.


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


The Foundation is funded by membership fees from Ordinary members and Industry 
partners, as well as some sponsorship contributions, and in-kind support from 
Industry. This seed funding is augmented by considerable voluntary effort by 
Industry representatives, and clinical reviewers / editors. Some clinical 
content development is sponsored directly by national health services or 
industry partners.


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

The clinical content development process is fully version-controlled using 
semver.org<http://semver.org> principles and documented s indicated by Thomas.

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)?”

As Thomas indicated, this is under development for technical artefacts used and 
produced by openEHR implementers.

Clinical content artefacts are subjected to a rigorous technical test as part 
of the upload/ maintenance process in the CKM tool.

"this is an area of active development in openEHR and now has its own 
Component. Currently the only proper conformance testing is done by validation 
of XML data against the published openEHR XML schemas."

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

Clinical content Version compatibility rules and testing are handled 
specifically in the specifications and are instantiated in the CKM tool when 
those artefacts are updated, by issuing 'diff' and compatibility reports.


Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859<tel:%2B44%20%280%29775%20209%207859>
office +44 (0)1536 414994<tel:%2B44%20%280%291536%20414994>
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto:ian.mcnic...@openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 4 April 2016 at 16:02, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:
>
>
> On 04/04/2016 14:07

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 <openehr-technical@lists.openehr.org>
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 
<openehr-technical@lists.openehr.org<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<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto: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 
<silje.ljosland.ba...@nasjonalikt.no<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<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<https://openehr.atlassian.net/wiki/display/stds/CAMSS+Assessment+of+openEHR>,

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<tel:%2B44%20%280%29775%20209%207859>
office +44 (0)1536 414994<tel:%2B44%20%280%291536%20414994>
skype: ianmcnicoll
email: i...@freshe

RE: CAMSS assessment of openEHR

[Bakke, Silje Ljosland]

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 <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<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0=download]
Co-Chair, openEHR Foundation 
ian.mcnic...@openehr.org<mailto: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 
<silje.ljosland.ba...@nasjonalikt.no<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<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<https://openehr.atlassian.net/wiki/display/stds/CAMSS+Assessment+of+openEHR>,

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<tel:%2B44%20%280%29775%20209%207859>
office +44 (0)1536 414994<tel:%2B44%20%280%291536%20414994>
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

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

On 5 January 2016 at 08:52, Bakke, Silje Ljosland 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:
I’ve added the CAMSS assessment table to the page. Would appreciate any help in 
populating the pink cells. ☺

Regards,
Silje

From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 On Behalf Of Thomas Beale
Sent: Monday, January 04, 2016 4:08 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: CAMSS assessment of openEHR


I have set up a CAMSS wiki 
page<https://openehr.atlassian.net/wiki/display/stds/CAMSS+Assessment+of+openEHR>,
 Silje if you can copy the relevant CAMSS boilerplate in (assessment table etc) 
and make it look vaguely presentable (make child pages if you need) then I am 
sure the community can get it populated quickly for you, since it's clearly of 
general benefit.

- thomas
On 04/01/2016 14:24, Bakke, Silje Ljosland wrote:
Hi Thomas, thanks for your reply!

I don’t have any say in which assessment criteria are used, unfortunately. I’ve 
seen your criteria, and agree they’re more specifically applicable to e-health 
standards.

I’ll probably need a lot of help answering and justifying the CAMSS questions, 
especially those regarding the governance of the specifications. I hope it’s 
okay if I pose specific questions to this list.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Monday, January 4, 2016 2:57 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: CAMSS assessment of openEHR


Hi Silje,

I had a look at the website - it doesn't seem as if anyone is using CAMSS much, 
if we believe this page, which contains CAMSS 
assessments<https://joinup.ec.europa.eu/community/camss/og_page/camss-assessments>,
 none of which are health related. On this page 
<https://joinup.ec.europa.eu/community/camss/og_page/list-standards> there is 

RE: CAMSS assessment of openEHR

[Bakke, Silje Ljosland]

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<https://openehr.atlassian.net/wiki/display/stds/CAMSS+Assessment+of+openEHR>,

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<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

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

On 5 January 2016 at 08:52, Bakke, Silje Ljosland 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:
I’ve added the CAMSS assessment table to the page. Would appreciate any help in 
populating the pink cells. ☺

Regards,
Silje

From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 On Behalf Of Thomas Beale
Sent: Monday, January 04, 2016 4:08 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: CAMSS assessment of openEHR


I have set up a CAMSS wiki 
page<https://openehr.atlassian.net/wiki/display/stds/CAMSS+Assessment+of+openEHR>,
 Silje if you can copy the relevant CAMSS boilerplate in (assessment table etc) 
and make it look vaguely presentable (make child pages if you need) then I am 
sure the community can get it populated quickly for you, since it's clearly of 
general benefit.

- thomas
On 04/01/2016 14:24, Bakke, Silje Ljosland wrote:
Hi Thomas, thanks for your reply!

I don’t have any say in which assessment criteria are used, unfortunately. I’ve 
seen your criteria, and agree they’re more specifically applicable to e-health 
standards.

I’ll probably need a lot of help answering and justifying the CAMSS questions, 
especially those regarding the governance of the specifications. I hope it’s 
okay if I pose specific questions to this list.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Monday, January 4, 2016 2:57 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: CAMSS assessment of openEHR


Hi Silje,

I had a look at the website - it doesn't seem as if anyone is using CAMSS much, 
if we believe this page, which contains CAMSS 
assessments<https://joinup.ec.europa.eu/community/camss/og_page/camss-assessments>,
 none of which are health related. On this page 
<https://joinup.ec.europa.eu/community/camss/og_page/list-standards> there is a 
much larger list of 'recommended' standards which are all generic (PDF, GIF and 
so on) - I don't know what use this is.

This page 
<https://joinup.ec.europa.eu/community/camss/wiki/camss-05-detailed-camss-criteria>
 has a long page of assessment criteria, which seem mostly reasonable to me, 
but are will probably miss what I would consider the most important criterion 
for value - longevity. I personally think longevity is ultimately based on 
semantic scalability (lack of other things will also kill it, like lack of 
community, implementations etc). See here 
<http://wolandscat.net/health-informatics/desiderata-for-successful-e-health-standards/>
 for my set of criteria.

I also don't think that compatibility with other standards is necessarily a 
useful criterion - it depends on whether those other standards are in use and 
are themselves delivering value or just getting in the way.

But overall the assessment tool seems OK. What I can't see is any example of 
where it has been applied to an e-health standard.

- thomas


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org<mailto: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: Trial of openEHR's own 'stackExchange' on the openEHR wiki

[Bakke, Silje Ljosland]

I just posted a real question, hope someone can give me a good answer that 
solves my problem! ☺

Btw, does anyone else experience a strange behaviour of the wiki editor, where 
it automatically capitalises some words as you type?

Mvh.
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Tuesday, January 05, 2016 2:33 PM
To: Openehr-Technical
Subject: Trial of openEHR's own 'stackExchange' on the openEHR wiki


one of the features we don't use on the wiki is 'Questions', which you can see 
here.

This supposedly is the same kind of function as StackExchange, which we didn't 
get off the ground. So maybe we should try locally.

My proposal would be for some community members to raise a question or two at 
the above link and see what the experience is like for creating answers, 
upvoting etc. We might find it is good enough.

For reference, here is the openEHR StackExchange 
page, which might be 
useful for remembering questions people had.

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

I've added the CAMSS assessment table to the page. Would appreciate any help in 
populating the pink cells. :)

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Monday, January 04, 2016 4:08 PM
To: openehr-technical@lists.openehr.org
Subject: Re: CAMSS assessment of openEHR


I have set up a CAMSS wiki 
page<https://openehr.atlassian.net/wiki/display/stds/CAMSS+Assessment+of+openEHR>,
 Silje if you can copy the relevant CAMSS boilerplate in (assessment table etc) 
and make it look vaguely presentable (make child pages if you need) then I am 
sure the community can get it populated quickly for you, since it's clearly of 
general benefit.

- thomas

On 04/01/2016 14:24, Bakke, Silje Ljosland wrote:
Hi Thomas, thanks for your reply!

I don't have any say in which assessment criteria are used, unfortunately. I've 
seen your criteria, and agree they're more specifically applicable to e-health 
standards.

I'll probably need a lot of help answering and justifying the CAMSS questions, 
especially those regarding the governance of the specifications. I hope it's 
okay if I pose specific questions to this list.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Monday, January 4, 2016 2:57 PM
To: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Subject: Re: CAMSS assessment of openEHR


Hi Silje,

I had a look at the website - it doesn't seem as if anyone is using CAMSS much, 
if we believe this page, which contains CAMSS 
assessments<https://joinup.ec.europa.eu/community/camss/og_page/camss-assessments>,
 none of which are health related. On this page 
<https://joinup.ec.europa.eu/community/camss/og_page/list-standards> there is a 
much larger list of 'recommended' standards which are all generic (PDF, GIF and 
so on) - I don't know what use this is.

This page 
<https://joinup.ec.europa.eu/community/camss/wiki/camss-05-detailed-camss-criteria>
 has a long page of assessment criteria, which seem mostly reasonable to me, 
but are will probably miss what I would consider the most important criterion 
for value - longevity. I personally think longevity is ultimately based on 
semantic scalability (lack of other things will also kill it, like lack of 
community, implementations etc). See here 
<http://wolandscat.net/health-informatics/desiderata-for-successful-e-health-standards/>
 for my set of criteria.

I also don't think that compatibility with other standards is necessarily a 
useful criterion - it depends on whether those other standards are in use and 
are themselves delivering value or just getting in the way.

But overall the assessment tool seems OK. What I can't see is any example of 
where it has been applied to an e-health standard.

- thomas

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

CAMSS assessment of openEHR

[Bakke, Silje Ljosland]

Hi guys,

As part of a standards assessment project initiated by the Norwegian 
Directorate of Health, several health IT standards will be assessed using CAMSS 
(https://joinup.ec.europa.eu/node/66790). Have anyone done a CAMSS assessment 
of the openEHR specifications? If so, would it be possible to share the results?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

___
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 Thomas, thanks for your reply!

I don't have any say in which assessment criteria are used, unfortunately. I've 
seen your criteria, and agree they're more specifically applicable to e-health 
standards.

I'll probably need a lot of help answering and justifying the CAMSS questions, 
especially those regarding the governance of the specifications. I hope it's 
okay if I pose specific questions to this list.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Monday, January 4, 2016 2:57 PM
To: openehr-technical@lists.openehr.org
Subject: Re: CAMSS assessment of openEHR


Hi Silje,

I had a look at the website - it doesn't seem as if anyone is using CAMSS much, 
if we believe this page, which contains CAMSS 
assessments<https://joinup.ec.europa.eu/community/camss/og_page/camss-assessments>,
 none of which are health related. On this page 
<https://joinup.ec.europa.eu/community/camss/og_page/list-standards> there is a 
much larger list of 'recommended' standards which are all generic (PDF, GIF and 
so on) - I don't know what use this is.

This page 
<https://joinup.ec.europa.eu/community/camss/wiki/camss-05-detailed-camss-criteria>
 has a long page of assessment criteria, which seem mostly reasonable to me, 
but are will probably miss what I would consider the most important criterion 
for value - longevity. I personally think longevity is ultimately based on 
semantic scalability (lack of other things will also kill it, like lack of 
community, implementations etc). See here 
<http://wolandscat.net/health-informatics/desiderata-for-successful-e-health-standards/>
 for my set of criteria.

I also don't think that compatibility with other standards is necessarily a 
useful criterion - it depends on whether those other standards are in use and 
are themselves delivering value or just getting in the way.

But overall the assessment tool seems OK. What I can't see is any example of 
where it has been applied to an e-health standard.

- thomas

On 04/01/2016 12:42, Bakke, Silje Ljosland wrote:
Hi guys,

As part of a standards assessment project initiated by the Norwegian 
Directorate of Health, several health IT standards will be assessed using CAMSS 
(https://joinup.ec.europa.eu/node/66790). Have anyone done a CAMSS assessment 
of the openEHR specifications? If so, would it be possible to share the results?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>


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

RE: Advantage of ISO

[Bakke, Silje Ljosland]

No. The Creative Commons licenses guarantees the free (as in beer) use and 
distribution of the specifications and the free (as in speech) use, 
distribution and improvement of the artifacts. This is what makes openEHR open 
and not proprietary. The organisation of the body holding the copyright and 
trademark is completely irrelevant.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of "Gerard Freriks (privé)"
Sent: Thursday, September 03, 2015 9:11 AM
To: For openEHR technical discussions
Subject: Re: Advantage of ISO

I think that it is NOT a misuse.

openEHR has one owner.
CEN and ISO have members (countries) that are, all together, the owner.

This a huge difference, don’t you think?

Gerard


On Sep 3, 2015, at 8:48 AM, Bakke, Silje Ljosland 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:

This is a misuse of the dictionary definition. Using your interpretation, all 
free/open projects are proprietary unless both IP and trademarks are made 
Public Domain. Linus Torvalds is the IP copyright holder and trademark owner of 
Linux, but because it’s released under a free license, it’s not proprietary 
software. The same goes for the openEHR Foundation and openEHR 
specs/artifacts/software.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway


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

RE: Archetype versioning: Skipping v1 and going straight to v2?

[Bakke, Silje Ljosland]

Agreed.

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bjørn Næss
Sent: Saturday, August 29, 2015 12:21 PM
To: For openEHR technical discussions
Subject: SV: Archetype versioning: Skipping v1 and going straight to v2?

I also think the version number should not be changed if the review and 
approval process introduse no changes in the structure or semantic of the 
archetype.

Incrementing the version when no changes are introduced just makes things 
confusing and increase complexity.



Sendt fra min Samsung-enhet


 Opprinnelig melding 
Fra: "Bakke, Silje Ljosland" 
<silje.ljosland.ba...@nasjonalikt.no<mailto:silje.ljosland.ba...@nasjonalikt.no>>
Dato: 28.08.2015 15.05 (GMT+01:00)
Til: 
openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>
Emne: Archetype versioning: Skipping v1 and going straight to v2?
Hi everyone,

We've bumped into an issue related to versioning of archetypes and implementing 
non-published versions:

Several implementation projects are using archetypes from the 
http://arketyper.no CKM, many of which are still drafts or under review since 
the CKM switch to v0 for unpublished archetypes was done only recently, and the 
publicly available tools all use v1 by default, lots of functionality has 
already been made using unpublished v1 versions of archetypes, and will be 
deployed this autumn. Of course, when reviewed, these archetypes may go through 
drastic changes, and this will be a problem once other projects at a later time 
try to use archetypes which by then may have been published as v1.

One of our proposed solutions is to skip v1 for these archetypes and go 
straight to v2 when publishing them. Is this practically possible, and will it 
have any adverse consequences?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.no<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/arketyper_no>

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

Archetype versioning: Skipping v1 and going straight to v2?

[Bakke, Silje Ljosland]

Hi everyone,

We've bumped into an issue related to versioning of archetypes and implementing 
non-published versions:

Several implementation projects are using archetypes from the 
http://arketyper.no CKM, many of which are still drafts or under review since 
the CKM switch to v0 for unpublished archetypes was done only recently, and the 
publicly available tools all use v1 by default, lots of functionality has 
already been made using unpublished v1 versions of archetypes, and will be 
deployed this autumn. Of course, when reviewed, these archetypes may go through 
drastic changes, and this will be a problem once other projects at a later time 
try to use archetypes which by then may have been published as v1.

One of our proposed solutions is to skip v1 for these archetypes and go 
straight to v2 when publishing them. Is this practically possible, and will it 
have any adverse consequences?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.nohttp://arketyper.no/ / Twitter: 
@arketyper_nohttps://twitter.com/arketyper_no

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

RE: ACTION performer?

[Bakke, Silje Ljosland]

So it’s possible to specify the role of each participant?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of thomas.be...@oceaninformatics.com
Sent: Thursday, August 27, 2015 11:09 AM
To: Openehr-Technical
Subject: Re: ACTION performer?

Normally you would use participations.

Sent from my HTC

- Reply message -
From: Bakke, Silje Ljosland 
silje.ljosland.ba...@nasjonalikt.nomailto:silje.ljosland.ba...@nasjonalikt.no
To: 
openehr-technical@lists.openehr.orgmailto:openehr-technical@lists.openehr.org
 
openehr-technical@lists.openehr.orgmailto:openehr-technical@lists.openehr.org
Subject: ACTION performer?
Date: Thu, Aug 27, 2015 10:00



Hi all,



According to Norwegian law, the performer or main performer of a procedure has 
to be explicitly recorded. The main performer is not necessarily the same 
person who records the action, so the COMPOSITION.composer RM object may not be 
used for this. We can't seem to find any complete description of the 
ACTION.participations RM object, but if it's possible to specify the role of 
the participant there, this may possibly be used. Or will we have to explicitly 
model this in the ACTION.procedure archetype?



Any thoughts?



Kind regards,

Silje Ljosland Bakke



Information Architect, RN

Coordinator, National Editorial Board for Archetypes

National ICT Norway

Tel. +47 40203298

Web: http://arketyper.nohttp://arketyper.no/ / Twitter: 
@arketyper_nohttps://twitter.com/arketyper_no


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

ACTION performer?

[Bakke, Silje Ljosland]

Hi all,

According to Norwegian law, the performer or main performer of a procedure has 
to be explicitly recorded. The main performer is not necessarily the same 
person who records the action, so the COMPOSITION.composer RM object may not be 
used for this. We can't seem to find any complete description of the 
ACTION.participations RM object, but if it's possible to specify the role of 
the participant there, this may possibly be used. Or will we have to explicitly 
model this in the ACTION.procedure archetype?

Any thoughts?

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.nohttp://arketyper.no/ / Twitter: 
@arketyper_nohttps://twitter.com/arketyper_no

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

RE: Archetype editor, CKM and v0 v1

[Bakke, Silje Ljosland]

Thanks for replying Peter! ☺

I’ve personally used newer versions of both tools than what’s currently on the 
website, in fact we haven’t used TD v2.6 since we got our CKM in February 2014, 
since it doesn’t work with Norwegian Bokmål (nb) archetypes. If you need people 
to do testing for a release I’d be very happy to help, and I’m sure lots of 
other people would too. Is there any test documentation available so testers 
can know what to do and where to get the test versions of the tools?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Peter Gummer
Sent: Friday, August 07, 2015 10:55 AM
To: For openEHR technical discussions
Subject: Re: Archetype editor, CKM and v0  v1

Hi Silje,

Yes, that’s true, and we’ve been wanting to do new releases for a long time but 
it takes time, which we don’t have. There were some incompatibilities between 
the tools and also with old archetypes and templates. I think these have been 
fixed now, but I’m not sure. Somebody would need to test that the tools to make 
sure that they don’t introduce new problems. If we released them in an unstable 
state, this could cause much bigger problems.

Finding time to work on this is the problem.

Regards,
Peter


On 7 Aug 2015, at 18:07, Bakke, Silje Ljosland 
silje.ljosland.ba...@nasjonalikt.nomailto:silje.ljosland.ba...@nasjonalikt.no
 wrote:

I’m assuming there’s no reaction to this because everyone is still enjoying 
their well-earned holidays. ☺

But this is a serious issue, which leads to only people “in the know” being 
able to download updated tools and create and edit archetypes and templates 
which conform to the newest patterns. Precisely what we’d like to avoid, isn’t 
it?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Tuesday, August 04, 2015 10:45 AM
To: For openEHR technical discussions
Subject: RE: Archetype editor, CKM and v0  v1

On a related note; the openehr.orghttp://openehr.org website still advertises 
Archetype Editor v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. 
Especially now after the v1 - v0 change, the newest builds should be linked 
from the web site.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.nohttp://arketyper.no/ / Twitter: 
@arketyper_nohttps://twitter.com/arketyper_no

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, July 23, 2015 1:07 AM
To: 
openehr-technical@lists.openehr.orgmailto:openehr-technical@lists.openehr.org
Subject: Re: Archetype editor, CKM and v0  v1


good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything else, it 
must start with a dot. Somewhat safer perhaps.

- thomas

On 22/07/2015 23:34, Peter Gummer wrote:
Hi Ian,

The + is redundant here, since it’s just saying that there has to be one or 
more digits after the ‘v’. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the ‘v’, followed by anything at 
all. This amounts to the same, since any extra digits qualify as “anything at 
all”.

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
i...@freshehr.commailto:i...@freshehr.com wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

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




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
[cid:image001.jpg@01D0D101.27A48410]http://www.oceaninformatics.com/

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHRhttp://www.openehr.org/
Honorary Research Fellow, UCLhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCShttp://www.bcs.org.uk/
Health IT bloghttp://wolandscat.net/category/health-informatics/

[cid:image002.png@01D0D101.27A48410]http://uk.linkedin.com/in/thomasbeale


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.orgmailto: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: Archetype editor, CKM and v0 v1

[Bakke, Silje Ljosland]

I'm assuming there's no reaction to this because everyone is still enjoying 
their well-earned holidays. :)

But this is a serious issue, which leads to only people in the know being 
able to download updated tools and create and edit archetypes and templates 
which conform to the newest patterns. Precisely what we'd like to avoid, isn't 
it?

Regards,
Silje

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bakke, Silje Ljosland
Sent: Tuesday, August 04, 2015 10:45 AM
To: For openEHR technical discussions
Subject: RE: Archetype editor, CKM and v0  v1

On a related note; the openehr.org website still advertises Archetype Editor 
v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. Especially now after 
the v1 - v0 change, the newest builds should be linked from the web site.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.nohttp://arketyper.no/ / Twitter: 
@arketyper_nohttps://twitter.com/arketyper_no

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, July 23, 2015 1:07 AM
To: 
openehr-technical@lists.openehr.orgmailto:openehr-technical@lists.openehr.org
Subject: Re: Archetype editor, CKM and v0  v1


good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything else, it 
must start with a dot. Somewhat safer perhaps.

- thomas

On 22/07/2015 23:34, Peter Gummer wrote:
Hi Ian,

The + is redundant here, since it's just saying that there has to be one or 
more digits after the 'v'. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the 'v', followed by anything at 
all. This amounts to the same, since any extra digits qualify as anything at 
all.

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
i...@freshehr.commailto:i...@freshehr.com wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

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



___

openEHR-technical mailing list

openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
[cid:image001.jpg@01D0D0F8.DC60C2A0]http://www.oceaninformatics.com/

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHRhttp://www.openehr.org/
Honorary Research Fellow, UCLhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCShttp://www.bcs.org.uk/
Health IT bloghttp://wolandscat.net/category/health-informatics/

[cid:image002.png@01D0D0F8.DC60C2A0]http://uk.linkedin.com/in/thomasbeale


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

RE: Archetype editor, CKM and v0 v1

[Bakke, Silje Ljosland]

On a related note; the openehr.org website still advertises Archetype Editor 
v2.2.905 beta from 2013, and Template Designer 2.6.1213.3. Especially now after 
the v1 - v0 change, the newest builds should be linked from the web site.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
National ICT Norway
Tel. +47 40203298
Web: http://arketyper.nohttp://arketyper.no/ / Twitter: 
@arketyper_nohttps://twitter.com/arketyper_no

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, July 23, 2015 1:07 AM
To: openehr-technical@lists.openehr.org
Subject: Re: Archetype editor, CKM and v0  v1


good point. Maybe a slightly more civilised version would be

\.v[0-9]+(\..*)?

that forces there to be one or more digits, and if there is anything else, it 
must start with a dot. Somewhat safer perhaps.

- thomas

On 22/07/2015 23:34, Peter Gummer wrote:
Hi Ian,

The + is redundant here, since it's just saying that there has to be one or 
more digits after the 'v'. But the next thing that it says is that you can have 
anything at all after those digits.

So you might as well omit the +:

\.v[0-9].*

This says that there has to be a digit after the 'v', followed by anything at 
all. This amounts to the same, since any extra digits qualify as anything at 
all.

Peter


On 23 Jul 2015, at 01:55, Ian McNicoll 
i...@freshehr.commailto:i...@freshehr.com wrote:

Thanks Thomas,

I will go with

\.v[0-9]+.*

which will give us a bit of flexibility and solve Dave's problem (I think!).

unless anyone strongly objects, of course.

Ian

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




___

openEHR-technical mailing list

openEHR-technical@lists.openehr.orgmailto:openEHR-technical@lists.openehr.org

http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

--
[cid:image001.jpg@01D0CEA1.BB13ADF0]http://www.oceaninformatics.com/

Thomas Beale
Chief Technology Officer
+44 7792 403 613

Specification Program, openEHRhttp://www.openehr.org/
Honorary Research Fellow, UCLhttp://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCShttp://www.bcs.org.uk/
Health IT bloghttp://wolandscat.net/category/health-informatics/

[cid:image002.png@01D0CEA1.BB13ADF0]http://uk.linkedin.com/in/thomasbeale


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

RE: openEHR @ StackExchange

[Bakke, Silje Ljosland]

Could questions be about modelling, or implementation/specs only?

Regards,
Silje 

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Monday, May 25, 2015 1:41 PM
To: openehr-technical@lists.openehr.org; For openEHR clinical discussions
Subject: Re: openEHR @ StackExchange

On 25/05/2015 12:16, Diego Boscá wrote:
 I would assume it can be both: a question could be just about specs 
 (just the openEHR tag) or about any specific implementation (e.g.
 openEHR and java)


yep - that's how I think it would work.

- 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

Licensing of specs and artifacts

[Bakke, Silje Ljosland]

Can the resulting ADL be publicly distributed?

Yes, absolutely, as long as you do not try to re-sell the 13606 archetypes with 
a closed-source licence!!

It?s actually a little more strict than that; the SA (ShareAlike) clause in the 
Creative Commons BY-SA licence (which all the openEHR archetypes are licensed 
under) mandates that any derivative works are licensed under the same (or a 
compatible, but for practical purposes there aren?t any , see 
https://creativecommons.org/compatiblelicenses) licence, ie the CC-BY-SA 
licence.

Regards,
Silje



From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: Tuesday, April 28, 2015 2:26 PM
To: For openEHR technical discussions
Subject: Re: Licensing of specs and artifacts

Hi Diego,

I will bring this post to the attention of the Board for a more authoritative 
response on the copyright / licensing question. These are just my personal 
opinions for now though Heather, Sebastian, Silje and I have discussed many of  
these issues so I can think they are probably representative.

 The copyright holder is still openEHR? Does It have something to do
 with the CC-BY-SA license?

The emerging view seems to be that *any* fork of an archetype, even if it just 
changes local ownership (namespace in ADL2.0) should probably result in change 
of copyright to the new owner with attribution to the previous owner. CC is a 
bit vague on when new copyright should be applied however.

In your case, this is a very significant change and I would expect copyright to 
change.

 What license was decided we should use? Did we agree in which metadata
 field should we store this?
We are adding a new 'license' attribute to other_details in ADL1.4  which will 
become a fully-fledged attribute in ADL2 ...

other_details = 
[licence] = Creative Commons Attribution-ShareAlike 4.0 International 
License
[revision] = 0.0.1-alpha
[references] =  Derived from   Adverse Reaction, draft archetype, 
National eHealth Transition Authority [Internet]. NEHTA Clinical Knowledge 
Manager. Authored: 08 Nov 2010. Available at: 
http://dcm.nehta.org.au/ckm/OKM.html#showarchetype_1013.1.868_7(accessed Jan 
16, 2012).
[build_uid] = 0043896f-d388-437e-ad46-472cb74ec56b
[original_namespace] = com.bosca
[original_publisher] = Bosca Enterprises
[MD5-CAM-1.0.1] = D5C7A064A7345211256376F748D97B6B
[custodian_namespace] = com.bosca
[custodian_organisation] = Bosca Enterprises


We are in the final stages of preparing a 'beginner's guide' that explains this 
stuff in more detail.

 Does the author change?

I would probably say no, if the clinical content is unchanged.

Probably the source archetype will also need
 to be referenced somehow.

We would expect to see that attribution in References - see above

 What else should be changed/added?
In the new world, you would need to change the namespaces, particularly as 
creating 13606 versions are definitely 'new' archetypes.

I assume that also a 'generated' field should be added (I know ADL 2
has this as a explicit field ;) so for the moment probably the best is
 to store everything we can't put elsewhere in other_details.

I would expect 'generated' to apply to same ref model ADLS-ADL kinds of 
transforms only but interesting question. @Thomas ??

Can the resulting ADL be publicly distributed?

Yes, absolutely, as long as you do not try to re-sell the 13606 archetypes with 
a closed-source licence!!

Ian



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

Co-Chair, openEHR Foundation Management Board
Director, freshEHR Clinical Informatics
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 28 April 2015 at 09:00, Diego Bosc? yampeku at gmail.commailto:yampeku at 
gmail.com wrote:
I refloat this thread as I think I got a practical use case: I have
generated a transformation from openEHR archetypes to ISO13606
archetypes. I have a couple of questions about the resulting ADL.
The copyright holder is still openEHR? Does It have something to do
with the CC-BY-SA license?
What license was decided we should use? Did we agree in which metadata
field should we store this?
Does the author change? Probably the source archetype will also need
to be referenced somehow. What else should be changed/added?
I assume that also a 'generated' field should be added (I know ADL 2
has this as a explicit field ;) so for the moment probably the best is
to store everything we can't put elsewhere in other_details.

Can the resulting ADL be publicly distributed?


2014-10-05 23:02 GMT+02:00 Bert Verhees bert.verhees at 
rosa.nlmailto:bert.verhees at rosa.nl:
 Is there going to be a follow up on this discussion?
 Will we here something about it?

 Bert


 Op donderdag 2 oktober 2014 heeft Erik Sundvall erik.sundvall at 
 liu.semailto:erik.sundvall at liu.se het
 volgende geschreven:

 Thank you Grahame 

MedInfo 2015 openEHR tutorials

[Bakke, Silje Ljosland]

Hi Evelyn,

I?m very interested in the work you?re doing with this. I?ve just got 
confirmation I can attend Medinfo next year, so I?d be very happy to be part of 
this discussion there.

I?d also like to contribute to the clinical modelling tutorial/workshop, as 
outlined on the wiki page. Has anyone taken the lead on submitting the 
proposals? If so, is there anything I can do? If not, is anyone planning to?

Kind regards,
Silje Ljosland Bakke
Coordinator, National Editorial Board for Archetypes, National ICT Norway
Special Adviser, RD dept, E-health section, Bergen Hospital Trust
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_nohttps://twitter.com/arketyper_no

From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On 
Behalf Of Evelyn Hovenga
Sent: Wednesday, October 29, 2014 11:10 PM
To: 'For openEHR clinical discussions'; 'Sam Heard'
Cc: 'For openEHR technical discussions'; 'For openEHR implementation 
discussions'
Subject: RE: MedInfo 2015 openEHR tutorials

Pablo,

Heather Grain and I are working with Heather Leslie to develop the openEHR body 
of knowledge and an educational framework that will allow students to identify 
suitable learning pathways and enable educators to develop educational programs 
according to their own expertise and opportunities to deliver.  It would be 
beneficial to have some time with all potential educators to discuss this 
further at Medinfo.

Evelyn
eHealth Education Pty Ltd, RTO 32279
(trading as RSC Training and eHE Training)
?  e.hovenga at ehe.edu.aumailto:e.hovenga at ehe.edu.au
?  0408309839  '  1300 285 512
?  www.ehe.edu.auhttp://www.ehe.edu.au/


From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] 
On Behalf Of sam.heard at 
openehrfoundation.orgmailto:sam.he...@openehrfoundation.org
Sent: Thursday, 30 October 2014 8:08 AM
To: For openEHR clinical discussions; Sam Heard
Cc: For openEHR technical discussions; For openEHR implementation discussions
Subject: Re: MedInfo 2015 openEHR tutorials

Thanks Pablo

It is a good team. I have added one possible topic and a couple of names. I 
would suggest that you lead this if you are able. We are keen to nominate  a 
lead person for each conference. Then put together a team from the attendees.

Linking to the Web site and ensuring your work is visible is important. The 
deadline of December 15 will arrive quicker than we expect.

I will be pleased to assist in any way I can and have booked my ticket to the 
conference.

Cheers, Sam

Dr Sam Heard
Chairman, openEHR Foundation

From: pablo pazosmailto:pazospa...@hotmail.com
Sent: ?Thursday?, ?30? ?October? ?2014 ?1?:?44? ?AM
To: For openEHR clinical discussionsmailto:openehr-clinical at 
lists.openehr.org, Sam Heardmailto:sam.heard at oceaninformatics.com
Cc: For openEHR technical discussionsmailto:openehr-technical at 
lists.openehr.org, For openEHR implementation 
discussionsmailto:openehr-implementers at lists.openehr.org

Hi Sam,

I think right now the tutorial organization is happening in a very organic way: 
people are sharing they proposals so others can collaborate or detect possible 
overlaps.

If we need a group to centralize coordination or communication with MedInfo 
organizers/chairs, I would propose the people interested no giving tutorials 
that is mentioned here: 
http://www.openehr.org/wiki/display/resources/MEDINFO+2015+-+Sao+Paulo%2C+Brazilhttp://www.openehr.org/wiki/display/resources/MEDINFO+2015+-+Sao+Paulo%2c+Brazil


On my part, I don't have resources to have an stand (flight + hotel + 
conference fee is not cheap for us), but if I can help in any way, e.g. the 
community can use me as an spanish speaker interlocutor, I'll be more than 
happy to help and add my grain of sand.


About training, I'm doing a small survey to see what people think about the 
proposals already discussed on the lists. My goal is to curate that and to 
reach a new level of discussions beyond ideas. I don't have Heather Grain's 
email, I'll gladly send her my little survey (Already sent to Heather L and 
Evelyn).

Cheers,
Pablo.

--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.comhttp://cabolabs.com/es/home

From: sam.heard at openehrfoundation.orgmailto:sam.he...@openehrfoundation.org
To: openehr-clinical at lists.openehr.orgmailto:openehr-clinical at 
lists.openehr.org
Subject: Re: MedInfo 2015 openEHR tutorials
Date: Sun, 26 Oct 2014 04:50:10 +
CC: openehr-technical at lists.openehr.orgmailto:openehr-technical at 
lists.openehr.org; openehr-implementers at 
lists.openehr.orgmailto:openehr-implementers at lists.openehr.org
Thanks Pablo

Good feedback. It has been difficult to keep up with everything and I am in no 
way trying to impede any activity. I believe this is the first International 
Medinfo in a country where openEHR is up and running.

My wish is to have a group that coordinate the effort. If you feel you have 
this in hand, lets make sure it is public 

XSL transform files for other languages?

[Bakke, Silje Ljosland]

Hi everyone,

Are there any alternative XSL transform files like tdo-csharp.xsl but for other 
languages available anywhere? Specifically, a VB.net one would be very useful.
Kind regards,
Silje Ljosland Bakke
Coordinator, National Editorial Board for Archetypes, National ICT Norway
Adviser, RD dept, E-health section, Bergen Hospital Trust
Tel. +47 40203298


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141106/769bd00b/attachment.html

MedInfo 2015 openEHR tutorials

[Bakke, Silje Ljosland]

I've added myself and a topic on artefact governance to the main MEDINFO2015 
wiki page. I guess this topic belongs more in a tutorial than in a developers' 
workshop.  My participation is however dependent on my employer allowing me to 
attend the conference, which isn't clear yet.

Kind regards,
Silje Ljosland Bakke
Coordinator, National Editorial Board for Archetypes, National ICT Norway
Adviser, RD dept, E-health section, Bergen Hospital Trust
Tel. +47 40203298

 -Original Message-
 From: openEHR-technical [mailto:openehr-technical-
 bounces at lists.openehr.org] On Behalf Of Shinji KOBAYASHI
 Sent: Tuesday, October 21, 2014 3:57 PM
 To: For openEHR technical discussions
 Cc: openehr implementers; openEHR Clinical
 Subject: Re: MedInfo 2015 openEHR tutorials
 
 Dear colleagues,
 
 I updated Wiki description about MEDINFO 2015 and made the developers'
 workshop 2015 page.
 http://www.openehr.org/wiki/display/resources/MEDINFO+2015
 
 Could you all please take a look and add comments or describe your plan?
 
 
 Shinji KOBAYASHI
 
 2014-08-05 10:22 GMT+09:00 pablo pazos pazospablo at hotmail.com:
  Of course! I should have think of Jussara before. I'll talk with her
  and her fellow openEHR.br colleagues to see if we can get this organized.
 
  BTW, just to start the coordination I would like to do a workshop
  focused on openEHR data store and query. And if there's interest,
  another one focused on UI: generation, manipulation, processing,
  models, etc. (we're presenting a paper on this topic at the InfoLac
 congress, this year is in Uruguay!
  lucky me: http://infolac2014.org/index.php/en/)
 
  --
  Kind regards,
  Eng. Pablo Pazos Guti?rrez
  http://cabolabs.com
 
  
  From: sam.heard at oceaninformatics.com
  To: openehr-clinical at lists.openehr.org;
  openehr-technical at lists.openehr.org
  Subject: Re: MedInfo 2015 openEHR tutorials
  Date: Mon, 4 Aug 2014 08:30:32 +
  CC: openehr-implementers at lists.openehr.org
 
 
  Hi Pablo
 
  I wonder if Jusara could organise a submeeting in an academic/industry
  forum prior to MedInfo?
 
  Cheers Sam
 
  Sent from Windows Mail
 
  From: pablo pazos
  Sent: ?Saturday?, ?2? ?August? ?2014 ?9?:?06? ?AM
  To: For openEHR clinical discussions, For openEHR technical
  discussions
  Cc: For openEHR implementation discussions
 
  Thanks for the info Heather!
 
  I think we should do something similar to the previous workshops for
  devs, something simple to get newcomers to understand how to work with
  archetypes in software (parsing, processing, validating data,
  extracting paths, etc), and more specific topics for skilled openEHR
  devs (persistence options, REST APIs, querying, reporting, UI generation,
 ...).
 
  I would love to see a hands-on tutorial in which we can program live
  and help newcomers to pass the first barrier in openEHR software
 development:
  lose the fear of archetypes.
 
  Also I would like to know how we want to present this, should we
  submit the proposals individualy and then organize or should we
  coordinate and make one proposal with all the workshops/tutorials?
 
  Thanks!
 
  --
  Kind regards,
  Eng. Pablo Pazos Guti?rrez
  http://cabolabs.com
 
  
  From: heather.leslie at oceaninformatics.com
  To: openehr-technical at lists.openehr.org;
  openehr-clinical at lists.openehr.org
  Subject: RE: MedInfo 2015 openEHR tutorials
  Date: Fri, 1 Aug 2014 01:54:59 +
  CC: openehr-implementers at lists.openehr.org
 
  Hi Pablo,
 
 
 
  We have kept info on Conferences in the wiki:
  http://www.openehr.org/wiki/display/resources/Conferences
 
 
 
  See Medinfo 2013:
  http://www.openehr.org/wiki/display/resources/MEDINFO+2013+-
 +Copenhagen,+Denmark.
  2 half day sessions were held then ? one clinical modelling focussed
  and the other technical
 
 
 
  Regards
 
 
 
  Heather
 
 
 
  From: openEHR-technical
  [mailto:openehr-technical-bounces at lists.openehr.org]
  On Behalf Of pablo pazos
  Sent: Friday, 1 August 2014 12:14 AM
  To: openeh technical; openEHR Clinical
  Cc: openehr implementers
  Subject: RE: MedInfo 2015 openEHR tutorials
 
 
 
  Hi Shinji!
 
 
 
  By chance, do you have the agendas of the previous openEHR developer's
  workshops?
 
 
 
  It would be nice to see what has been done, do a little bit of
  introduction workshops for beginners and do some new cool stuff for
 skilled openEHR devs.
 
 
 
  BTW, maybe a good place to coordinate and share info about ideas would
  be the openEHR wiki.
 
 
 
  Thanks!
 
  --
  Kind regards,
  Eng. Pablo Pazos Guti?rrez
  http://cabolabs.com
 
  
 
  From: skoba at moss.gr.jp
  Date: Wed, 30 Jul 2014 10:25:16 +0900
  Subject: Re: MedInfo 2015 openEHR tutorials
  To: openehr-clinical at lists.openehr.org
  CC: openehr-technical at lists.openehr.org;
  openehr-implementers at lists.openehr.org
 
  Hi Pablo and all,
 
  We had developers' workshop at Medinfo2007, 2010 

Licensing of specs and artifacts

[Bakke, Silje Ljosland]

Hi everyone,

In light of the recent re-licensing of 
FHIRhttp://www.healthintersections.com.au/?p=2248 using the Creative Commons 
CC0 Public Domain Dedication as well as the discussion about licensing at the 
2014 openEHR Roadmap 
Meetinghttp://www.openehr.org/wiki/display/oecom/September+2014+Roadmap+Meeting
 in Lillestr?m on September 16 and 17, I'd like to restart the discussion on 
licensing of openEHR specifications and artefacts (mainly archetypes, but also 
potentially templates and terminology sets).

As of now, the specifications are licensed using the Creative Commons 
Attribution No-Derivativeshttp://creativecommons.org/licenses/by-nd/3.0/ 
(CC-B-ND) license, while the Creative Commons Attribution 
Share-Alikehttp://creativecommons.org/licenses/by-sa/3.0/ (CC-BY-SA) is used 
for artefacts. Several issues have been raised about this choice of licences. 
Feel free to add to this list, I'm bound to have forgot some issues:

CC-BY-ND (for specs):

? Theoretically, a hostile takeover of the openEHR Foundation might 
leave the openEHR specs dead, as with the CC-BY-ND only the copyright holder 
(the Foundation) has the rights to modify them. A forkable license like for 
instance CC-BY-SA would solve this issue. Global registering of the openEHR 
trademark would keep any derivates to be branded as openEHR.

CC-BY-SA (for artefacts):

? Commercial implementers might avoid using CC-BY-SA artefacts because 
the license requires any published modifications of the work to be licensed 
using the same license. This might lead implementers to believe the license 
would require them to license their entire software product as CC-BY-SA. There 
are several examples of CC-BY-SA works being used in copyrighted works, such as 
Wikipedia articles being used in newspapers, but this is probably reliant on a 
benign licensor, which any normal commercial company can't rely 100% on. The 
way I see it, this problem could be solved in one of two ways:

o   Use the CC-BY license, which retains the attribution clause, but doesn't 
require any derivative works to use the same license. This has the disadvantage 
of enabling proprietary tweaking of archetypes, which could potentially ruin 
interoperability.

o   Retain the CC-BY-SA license, but add an explicit clause that allows all 
implementers to use artefacts in closed-source, proprietary products with any 
license they like. Artefacts published by themselves, as standalone archetypes, 
templates or terminology sets would still be bound by the ShareAlike clause. 
This is supported by Creative Commons via the 
CC+https://wiki.creativecommons.org/CCPlus protocol.

I realise these issues will ultimately be decided by the board of the openEHR 
Foundation, but if the community can come to some kind of consensus on this 
issue I would hope it'd send them a strong signal.
Kind regards,
Silje Ljosland Bakke
Coordinator, National Editorial Board for Archetypes, National ICT Norway
Adviser, RD dept, E-health section, Bergen Hospital Trust
Tel. +47 40203298

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141001/5e2d6c81/attachment-0001.html

Texts about transforming between openEHR and other formalisms

[Bakke, Silje Ljosland]

Thanks ?ystein! I was primarily looking for something on a more specific and 
practical level, but I guess Rector is a good place to start.

Kind regards,
Silje Ljosland Bakke
Coordinator, National Editorial Board for Archetypes, National ICT Norway
Adviser, RD dept, E-health section, Bergen Hospital Trust
Tel. +47 40203298

Fra: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] 
P? vegne av ?ystein Nytr?
Sendt: 24. september 2014 20:59
Til: For openEHR technical discussions
Emne: Re: Texts about transforming between openEHR and other formalisms

24. sep. 2014 kl. 18.01 skrev Bakke, Silje Ljosland silje.ljosland.bakke at 
helse-bergen.nomailto:silje.ljosland.bakke at helse-bergen.no:


Hi,

I'm wondering if anyone could point me to any publically available texts about 
transforming archetypes (and templates) from openEHR to other formalisms. 
Academic publications exploring the (im)possibilities of automatic 
transformation would be ideal.


A highly recommended and succinct article about the distinctions, relationships 
and transformations between archetypes, frames, templates and
semantically tractable formalisms is: Alan Rector's: Axioms  Templates: 
Distinctions  Transformations amongst Ontologies, Frames,  Information 
Models .
His way of clearing up the terminology about (my words here...) information 
model (in the computer), templates (presentations for humans)
and domain knowledge (boundaries of reality) should be required reading for 
anyone working on domain modelling.
Look into the citations for more background. Available freely here: 
http://dl.acm.org/citation.cfm?id=2479840

(Archetypes are essentially just another template/frame/OO-inspired modelling 
convention. And yes, Alan Rector is  THE authority on the subject matter.)

Best regards,
--- ?ystein Nytr?

---
Inst. for datateknikk  og info.vitenskap | Dept. of computer and info. science
IDI, NTNU, NO-7491 TRONDHEIM, Norway
tel +47 73594459, mob +47 91897606



-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140924/03676999/attachment.html

Texts about transforming between openEHR and other formalisms

[Bakke, Silje Ljosland]

Hi,

I'm wondering if anyone could point me to any publically available texts about 
transforming archetypes (and templates) from openEHR to other formalisms. 
Academic publications exploring the (im)possibilities of automatic 
transformation would be ideal.

Kind regards,
Silje Ljosland Bakke
Coordinator, National Editorial Board for Archetypes, National ICT Norway
Adviser, RD dept, E-health section, Bergen Hospital Trust
Tel. +47 40203298
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140924/d186764c/attachment.html