RE: AQL query for blood pressure from the AQL documentation

[Bjørn Næss]

I am not sure where this fits in, anyway.

Given an AQL for the latest systolic like this:
select
   o/data[at0001]/events[at0006]/data[at0003]/items[at0004]
from
   composition c
contains
   OBSERVATION o[openEHR-EHR-OBSERVATION.blood_pressure.v1]
order by o/data[at0001]/origin desc
limit 1
I will return a representation of an ELEMENT where the value is a DV_QUANTITY.
For this value object you might navigate further into the attributes like i.e. 
/value/magnitude to get the number 160.0.

 {
"_type": "ELEMENT",
"archetype_node_id": "at0004",
"name": {
  "value": "Systolisk"
},
"value": {
  "_type": "DV_QUANTITY",
  "magnitude": 160.0,
  "units": "mm[Hg]"
}
  }

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-technical  On Behalf 
Of Thomas Beale
Sent: torsdag 2. mai 2019 13:52
To: openehr-technical@lists.openehr.org
Subject: Re: AQL query for blood pressure from the AQL documentation


Ian,

If you were referring to the discussion about paths and data types, i.e. how do 
you know if you can refer to some path inside a DvQuantity if the archetype 
only knows about DataValue and LOINC codes, it's true that you can use such a 
path, if the real data (Element.value) happen to be a DvQuantity, but you have 
to be able to reliably figure this out at runtime, presumably by inferring it 
from the LOINC or other code - every time? In this situation the AQL processor 
cannot help you, because it doesn't have any information about what lies beyond 
the Element.value point in the structure.

It seems to me that it would be preferable to convert data with DataValue 
specific archetypes, since the general case is that data are written once, read 
many times. In that case, you will have data that always has a typed analyte 
Cluster archetype (e.g. to DvQuantity, DvOrdinal etc), and and the AQL service 
will be able to do proper type / path checking. AQL authoring tools will also 
be able to work in a more obvious way (e.g. with auto-complete on paths etc).

So far I am not seeing a downside to this. I realise others have thought about 
it longer than I however ...

- thomas
On 02/05/2019 12:02, Ian McNicoll wrote:
The replies that seref and I gave address the issue. The vast majority of lab 
imports will use the generic analyte cluster.

On Thu, 2 May 2019, 12:01 Ian McNicoll, 
mailto:ian.mcnic...@gmail.com>> wrote:
Thomas this is not a problem. The aql works as designed

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

RE: AQL questions

[Bjørn Næss]

Thomas answered the CONTAINS operator. 

I am not sure how to best answer your second question. I will try the following 
:-) 

The node predicates as below: 

*c2/items[at0002]/items[at0001]/value/magnitude
*o/data[at0001]/events[at0002]/time

Here the "c2" and "o" is a reference to a path in the Composition, and the 
reference is defined in the FROM part of the AQL. The "c2" is synonymous with 
the following path: 

"c2" == 
"/content[openEHR-EHR-OBSERVATION.laboratory_test.v1]/data[at0001]/events[at0002]/data[at0003]/items[openEHR-EHR-CLUSTER.laboratory_test_panel.v1]"

Which gives "c2" + "path" to be: 

"/content[openEHR-EHR-OBSERVATION.laboratory_test.v1]/data[at0001]/events[at0002]/data[at0003]/items[openEHR-EHR-CLUSTER.laboratory_test_panel.v1]/
 /items[at0002]/items[at0001]/value/magnitude"


Vennlig hilsen
Bjørn Næss
Produktansvarlig 
DIPS ASA

Mobil +47 93 43 29 10

-Original Message-
From: openEHR-technical  On Behalf 
Of Georg Fette
Sent: torsdag 25. april 2019 19:30
To: openehr-technical@lists.openehr.org
Subject: Re: AQL questions

Hi Bjørn,
Thank you for your answers. They make me assume that the CONTAINS-operator is 
recursive because in your second query you ommited the part with "CONTAINS 
OBSERVATION o[openEHR-EHR-OBSERVATION.laboratory_test.v1]". Is this assumption 
correct ? This would make writing AQL a lot simpler.
Another assumption I have is that the predicate namespaces always relate to the 
aliased archetype the path they are used within starts with. In your first 
query you use at0001 and at0002 each two times but they seem to have different 
meanings.
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B009
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
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: AQL questions

[Bjørn Næss]

Hi - great question. 
The answer is as always; it depends. The query below (similar to yours) will 
work also. 
What you have to consider when building AQLs is repeatable structures to make 
sure you hit the right instance. For this use-case I guess you would like any 
EHR which has a Calcium result. Thus you don’t care about which result is 
Calcium. But if you wanted to get the excact CLUSTER with Calcium combined with 
i.e. HISTORY.time you have to be a bit careful. 

SELECT
e
FROM
EHR e
CONTAINS COMPOSITION c
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.laboratory_test.v1]
CONTAINS CLUSTER 
c2[openEHR-EHR-CLUSTER.laboratory_test_panel.v1]
WHERE
c2/items[at0002]/items[at0001]/value/magnitude > 123
ORDER BY
o/data[at0001]/events[at0002]/time DESC
LIMIT 10


An even simpler AQL if you want any CLUSTER of a specific type is to only query 
for Composition with the CLUSTER. Like this: 

SELECT
e
FROM
EHR e
CONTAINS COMPOSITION c
CONTAINS CLUSTER c2[openEHR-EHR-CLUSTER.laboratory_test_panel.v1]
LIMIT 10

Vennlig hilsen
Bjørn Næss
Produktansvarlig 
DIPS ASA

Mobil +47 93 43 29 10


-Original Message-
From: openEHR-technical  On Behalf 
Of Georg Fette
Sent: torsdag 25. april 2019 14:18
To: For openEHR technical discussions 
Subject: AQL questions

Hello,
I have some problems concerning the formulation of an AQL query.
I would like to check a laboratory analyte within a laboratory test. The 
analyte should have "Calcium" as analyte name and I would like to receive all 
EHRs that contain the analyte as the query result.
The SELECT part seems easy, as I just want the EHRs, so this looks like
this:

SELECT e

A problem I now have is about the nesting of the Archetypes. As the test is an 
OBSERVATION and an EHR contains only COMPOSITIONs, I wonder if I have to 
include a COMPOSITION in order to reach the tests. This would lead to a FROM 
part looking like this:

FROM EHR e
     CONTAINS COMPOSITION
         CONTAINS OBSERVATION
b[openEHR-EHR-OBSERVATION.laboratory_test_result.v1]

The next problem I have is about the definition of the containment of the 
analyte in the FROM part or better in the WHERE part. The FROM part would 
require me to define the actual nesting structure of the test-OBSERVATION up to 
the analyte-CLUSTER. This would look like this:

FROM EHR e
     CONTAINS COMPOSITION
         CONTAINS OBSERVATION
b[openEHR-EHR-OBSERVATION.laboratory_test_result.v1]
             CONTAINS HISTORY
                 CONTAINS EVENT
                     CONTAINS ITEM_TREE
                         CONTAINS CLUSTER 
c[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]

This looks a bit bloated, so I think this should rather be moved to the WHERE 
part, which would look like this:

FROM EHR e
     CONTAINS COMPOSITION
         CONTAINS OBSERVATION
b[openEHR-EHR-OBSERVATION.laboratory_test_result.v1]
WHERE
b/data[at0001]/events[at0002]/data[at0003]/items[at0097]/items[at0024].value
= 'Calcium'

In this WHERE path I am wondering about the necessity of the path part 
predicates (i.e. the [at...] parts). Are these predicates always necessary for 
every path part ? Or are they only necessary when the path part object would be 
ambiguous without the predicate (e.g. in the items of CLUSTERs or ITEM_LISTs) ?
Furthermore I wonder about the namespace from which the predicates are taken 
from. For the first part of the WHERE until the archetype slot is reached (i.e. 
b/data[at0001]/events[at0002]/data[at0003]/items[at0097])
the predicates are from the laboratory_test_result archetype. For the rest of 
the path (i.e. /items[at0024].value) the predicates are taken from the 
laboratory_test_analyte archetype. This switching of namespaces seems wrong, so 
I think I still have some misunderstanding of AQL concerning the predicates.

How would the correct query/queries look like ? Are there multiple valid 
alternatives to express my query using combinations of the approaches scetched 
above ?
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
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: AQL on specific list of compositions

[Bjørn Næss]

@ian – we have implemented the query you wrote:

“select c from EHR e contains FOLDER f contains COMPOSITION c where c…..”

You might even write:

“select c from EHR e contains FOLDER f contains FOLDER child_folder contains 
COMPOSITION c where c…..”


We made a restriction such that the COMPOSITION c MUST be referenced in FOLDER 
f and not any sub-folder. This was needed to avoid circular references and 
explosion in the result set.


Vennlig hilsen
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-technical  On Behalf 
Of Ian McNicoll
Sent: mandag 20. august 2018 11:22
To: For openEHR technical discussions 
Subject: Re: AQL on specific list of compositions

Yup but AQL is so cool for this kind of thing :)

I still want to do
Select c FROM EHR Contains folder x contains composition c

since logically folder x contains compositions.

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&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=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, 20 Aug 2018 at 10:14, Thomas Beale 
mailto:thomas.be...@openehr.org>> wrote:
Well if you have access to a Folder, you don't need to do an AQL query,
you can just retrieve the Folder structure and recurse through it,
picking up direct refs to VERSIONED_COMPOSITIONs.

Creating Folders from the data on the other hand requires writing some
queries that look for admissions and discharges, matching them up, and
generating a Folder for each pair, named after the institution and/or
dates of the stay.  A bit messy, but not hard to do, if one wants to
post hoc add Folders to 'old' EHRs that never had them.

- thomas


On 20/08/2018 10:07, Ian McNicoll wrote:
> Thanks Thomas,
>
> What are your thoughts on the AQL example I foolishly guessed at :(
> and that Seref quite correctly rejected!!
>
> How would/should we do...
>
> Select all compositions referenced by Folder x.


___
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: information about allowable data in a openEHR format

[Bjørn Næss]

Hi Dave
Your use-case is to create data into an EHR. You have different kind of data 
like problem/diagnosis<http://openehr.org/ckm/#showArchetype_1013.1.169>, 
medications<http://openehr.org/ckm/#showArchetype_1013.1.1445>, 
procedures<http://openehr.org/ckm/#showArchetype_1013.1.204>, 
height<http://openehr.org/ckm/#showArchetype_1013.1.138> and 
weight<http://openehr.org/ckm/#showArchetype_1013.1.2960>. These are all 
archetypes in openEHR and I have provided links to them above.

What you need to do is to create a Template based on these archetypes. Based on 
this Template you can create Compositions. Compositions are documents or 
transactions containing data into an openEHR system.

There are several ways to serialize this data. Both JSON and XML are used in 
production systems today.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Monaghan, David S
Sent: onsdag 22. november 2017 15:40
To: openehr-technical@lists.openehr.org
Subject: RE: information about allowable data in a openEHR format

Hey all,
Apologies for asking what is probably a simple question but I’m just starting 
out in this space now.
My question is:
If I have a patient record with ICD-9 and ICD-10 codes, Pharmacy codes, 
procedure codes, patient data such as age, sex, height, weight etc. and also 
free form clinical notes. Can I store all this kinda of data in a openEHR 
format? And if so could you provide me with a sample json of what that kind of 
patient record would look like?

Or point me in the right direction?

Thanks so much

Kind regards
Dave

Dr David Monaghan  | Optum
Lead Machine Learning Researcher – Product Engineering and Data Solutions
BLOCK C, SPENCER DOCK, Dublin, Ireland
T +353 749 200 436
E david_monag...@optum.com<mailto:david_monag...@optum.com>
www.optum.com<http://www.optum.com/>

Our United Culture  The way forward
Integrity  |  Compassion  |  Relationships  |  Innovation  |  Performance

Optum Services (Ireland) Limited, a private company limited by shares, 
registered in Ireland with company number 579794 and with its registered office 
at 70 Sir John Rogerson's Quay, Dublin 2.





This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL for multi-occurrence nodes

[Bjørn Næss]

I would also look at the ITS specification.  
https://github.com/openEHR/specifications-ITS/tree/master/REST_API

There is a XSD there which defines some structures.



Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA


 Opprinnelig melding 
Fra: Thomas Beale 
Dato: 03.11.2017 18:27 (GMT+01:00)
Til: openehr-technical@lists.openehr.org
Emne: Re: AQL for multi-occurrence nodes


Dileep,

see 
here<https://openehr.atlassian.net/wiki/spaces/spec/pages/4915240/Ocean+Informatics+EHR+Service+Interface#OceanInformaticsEHRServiceInterface-DataStructures>.
 But I suggest you post this question on the implementers 
list<http://www.openehr.org/community/mailinglists> to see if someone can point 
you to classes already available.

- thomas

On 03/11/2017 02:47, Dileep V S wrote:
Dear Thomas,

Can you point me to details of Java structures

regards

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

RE:

[Bjørn Næss]

This is great work. Look forward to read the details.
Congratulations!

Sincerely
Bjørn Næss
Product Owner openEHR platform
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ingram, David
Sent: fredag 27. oktober 2017 13:28
To: For openEHR clinical discussions (openehr-clini...@lists.openehr.org) 
; For openEHR technical discussions 

Subject:

An implementation focused evaluation of openEHR and its integration with 
Bayesian Belief Networks for clinical decision support
One of my most persistent PhD students, Seref Arikan, has published his 
ground-breaking PhD thesis on the UCL online repository.
A fuller announcement and link has been posted in the News Section of the 
openEHR web site at:
http://openehr.org/news_events/community_news
We hope it will make a useful contribution to the ongoing international 
advances in openEHR methodology.
David Ingram
Emeritus Professor of Health Informatics at UCL
President and Chairman of the Board of Governors of the openEHR Foundation
Trustee of the OpenEyes Foundation Charity
Academic Board Member, the Planetearth Institute

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

How to use ACTION.procedure for Surgery Reports

[Bjørn Næss]

I have written a note on how we will use ACTION.procedure to document what 
happened during surgery.
Have a look at the notes here: 
https://github.com/bjornna/openehr-discussion/blob/master/surgery/index.adoc
There is also some discussions on #slack: 
https://openehrclinical.slack.com/messages/C7U9JD1EK


Sincerely
Bjørn Næss
Product Owner openEHR platform
DIPS ASA

Mobil +47 93 43 29 10

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

RE: AQL for multi-occurrence nodes

[Bjørn Næss]

This is a very interesting topic. I have written out some of the problems in 
this repo: https://github.com/DIPSASA/openehr-conformance/tree/master/aql

The general answer is that you need to write you AQL as detailed as possible. 
Meaning you need to know which level you expect the multiple occurences to 
appear. Take a look at the examples given above. I would be happy to answer 
follow ups on this.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Dileep V S
Sent: fredag 27. oktober 2017 08:15
To: For openEHR technical discussions 
Subject: AQL for multi-occurrence nodes

Hi,

What is the expected response to AQL on a node with multiple occurrences? Does 
it return all the occurrences or only the first one?

If it is expected to return all occurrences, what is the structure of the 
response? will the occurrences be returned as an array?

If only the first one is returned, how do we get all the occurrences?  Adding 
multiple select lines in aql may not be practical as the number of occurrences 
can vary.

Can nay body give a select statement syntax for this?

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<http://healthelife.in/>  e: 
dil...@healthelife.in<mailto:dil...@healthelife.in>


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

RE: Does aql support multiple ehrids?

[Bjørn Næss]

There is a lot of use-cases involving multiple EHRs. The answer from Ian is 
defined in AQL specification.
In an upcoming version of the REST API I think population queries will be added 
to give client even more control on this kind of use-cases. We have already 
implemented this a while ago.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Dileep V S
Sent: fredag 27. oktober 2017 11:52
To: For openEHR technical discussions 
Subject: Re: Does aql support multiple ehrids?

Thanks Ian

Regards
Dileep V S
Founder
HealtheLife Ventures LLP
+91 9632888113
103, Innovation Centre, IIIT, Electronics City, Bangalore 560100, 
healthelife.in<http://healthelife.in>

On 27-Oct-2017 3:12 PM, "Ian McNicoll" 
mailto:i...@freshehr.com>> wrote:
Marand THinkEHR supports this ...

WHERE e/ehr_id/value MATCHES {

'e241715b-3ca7-435e-a474-718579aadaa2',

'0e7ac1d6-2dc6-40ec-8259-ac9f9a9727d1',

'ed74f788-4bd6-4e47-ab98-211643cc4b0c'}


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&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=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 27 October 2017 at 07:20, Dileep V S 
mailto:dil...@healthelife.in>> wrote:
Hi,

I have tested aql with single ehr and across all ehrs(without any ehrid). Can 
we pass an array of ehrids in an aql to limit the query to selected ehrs?

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<http://healthelife.in/>  e: 
dil...@healthelife.in<mailto:dil...@healthelife.in>


___
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.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [openEHR SEC] CONTAINS in AQL

[Bjørn Næss]

Yes - this is the way DIPS openEHR server works as well.

For Composition we match any descendant .  Any structure which matches will be 
valid no matter how deep the location is.

For Folder we have another case. There we only match the first level .  This 
must be treated differently since we for Folder navigate through object 
references.



Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA


 Opprinnelig melding 
Fra: Ian McNicoll 
Dato: 01.10.2017 19:05 (GMT+01:00)
Til: For openEHR technical discussions , 
sec 
Emne: Re: [openEHR SEC] CONTAINS in AQL

Hi Pablo,

The contains statement is intended to pick up any descendent and this is  how 
it is implemented by marand ocean and Ethercis.

This works down to cluster level and I suspect to element if we had any element 
archetypes.

On 1 Oct 2017 at 16:12, mailto:pablo.pa...@cabolabs.com>> wrote:

Hi all,

I'm reading through the AQL specs, on this section 
http://openehr.org/releases/QUERY/latest/docs/AQL/AQL.html#_containment it is 
mentioned that CONTAINS is from parent to child.

Most examples there show COMPOSITION CONTAINS ENTRY. In a case that there is a 
SECTION in the middle, should AQL be always COMPOSITION CONTAINS SECTION 
CONTAINS ENTRY?

Before reading this specific point I was thinking that CONTAINS allowed to look 
anywhere on the COMPOSITION tree, semantically looking for "child or 
descendant", instead of just "child".

If we have only direct "child" references, having a small tree of SECTIONs can 
make queries more complex, like COMPOSITION CONTAINS SECTION CONTAINS SECTION 
CONTAINS SECTION CONTAINS ENTRY ...

Would it be useful to have that kind of "child or descendant" containment 
operator added to AQL?


What do others think?

--
Ing. Pablo Pazos Gutiérrez
e: pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>
p: +598 99 043 145
skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 <http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
https://cloudehrserver.com<https://cloudehrserver.com/>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

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

[Bjørn Næss]

Hi 
We have implemented this in the form based on the operational template. 
Then we put reuse information with AQL to query structures to be reused for 
different purposes. 
Works perfectly well :-) 

Regards
Bjørn Næss
Product owner Arena EHR 
DIPS ASA

Mobil +47 93 43 29 10

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pieter Bos
Sent: onsdag 5. juli 2017 16:01
To: For openEHR technical discussions 
Subject: Re: Using aql for data set in DV_CODED_TEXT

It could be an application detail.

Or in ADL 2 it can be a query function in the rules section, as defined in the 
specs. Not sure if you want this in basic archetypes, but you can certainly do 
this in adl 2 templates.

I'm not sure what you can do in GDL.

Regards,

Pieter Bos
Nedap Healthcare

Op 5 jul. 2017 om 15:16 heeft Bakke, Silje Ljosland 
mailto:silje.ljosland.ba...@nasjonalikt.no>>
 het volgende geschreven:

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<http://arketyper.no/> / Twitter: 
@arketyper_no<https://twitter.com/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 
mailto:openehr-technical@lists.openehr.org>>
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<http://healthelife.in/>  e: 
dil...@healthelife.in<mailto:dil...@healthelife.in>


___
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

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

Re: Random / Synthetic Data Generation over Templates

[Bjørn Næss]

I am not sure if I understand the requirements either . But - what we have 
implemented is a random composition generator (CTRL+D) which populate a 
composition with data. Currently both valid and not valid data to test and 
verify validation. This is quite useful when testing openEHR forms.


Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA


 Opprinnelig melding 
Fra: "Anastasiou A." 
Dato: 18.04.2017 11:46 (GMT+01:00)
Til: For openEHR technical discussions 
Emne: RE: Random / Synthetic Data Generation over Templates

Hello Ian

Yes, that is what I understood and these services would be very useful indeed.

A forward "model" for a 4 digit hexadecimal number could be something like K = 
"[0-9A-F] [0-9A-F] [0-9A-F] [0-9A-F]".
K recognises things like "0F0F", "", etc. Using K in reverse would be to 
use the regular expression to generate (all the) strings that would match the 
model.

Similarly, a Template is a model that "matches" its data with constraints 
dictated by ADL and a reverse model would be a Template that is used to 
generate (all the) data that would conform with it. Of course, this can be done 
in a "typical" way, i.e. match the data type, or in a more realistic way by 
taking into account the condition (i.e. synthetic data).

All the best
Athanasios Anastasiou







From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: 18 April 2017 10:03
To: For openEHR technical discussions
Subject: Re: Random / Synthetic Data Generation over Templates

Hi Athanasios,

I'm not quite sure what you mean by 'reverse models'?

A couple of CDR vendors have implemented services that allow you to generate a 
dummy composition for any template that is registered with the CDR. That is 
nice but even nicer would be to have a service that allowed a dummy composition 
to be generated 'on-the-fly' from a submitted template, without leaving the 
template permanently on the CDR.

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&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=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 April 2017 at 07:43, Anastasiou A. 
mailto:a.anastas...@swansea.ac.uk>> wrote:
Hello Pablo and all

Thank you very much for the quick response. That's not too far from what I had 
in mind.

Ian, were you asking about "reverse" models offered as a service?

All the best
Athanasios Anastasiou



From: openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>]
 On Behalf Of Pablo Pazos
Sent: 14 April 2017 01:34
To: For openEHR technical discussions
Subject: Re: Random / Synthetic Data Generation over Templates

In my case i have that in my To Do list. I want to complete the services with 
an XML instance validator based on the OPT constraints, not just on the XSD. It 
will take some time to have a usable release.

On Thu, Apr 13, 2017 at 5:20 PM, Ian McNicoll 
mailto:i...@freshehr.com>> wrote:
Would there be any interest in making these services available if we could find 
some free uk hosting? I guess ideally we should post the template and get back 
a sample composition without any actual persistence of either.

On Thu, 13 Apr 2017 at 18:39, Diego Boscá 
mailto:yamp...@gmail.com>> wrote:
Yeah, LinkEHR can do that

Regards

El 13/4/2017 17:37, "Anastasiou A." 
mailto:a.anastas...@swansea.ac.uk>> escribió:
Hello everyone

I remember some time ago, there was a tool that given a detailed template 
description, it would populate it with random data taking
into account only knowledge about the datatype.

I vaguely remember Heather Leslie mentioningit but I may be wrong.

Is that functionality available from one of Ocean's tools? (e.g. the Template 
Designer)

Is similar functionality available through other tools? (e.g. LinkEHR, other).

Looking forward to hearing from you
Athanasios Anastasiou



___
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
--
Ian McNicoll

_

Re: Add SNOMED codes to values in Internal code set

[Bjørn Næss]

We simply add the wanted SNOMED codes to the Template. This works well for 
smaller subsets .  One example may be found in the URL below.  Unfortunately 
the examples are Norwegian, but I guess you will find the relevant elements .

https://github.com/bjornna/dips-ckm/blob/nymaster/templates/EyeModule/FU%20-%20Synsfelt.oet



Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA


 Opprinnelig melding 
Fra: Dileep V S 
Dato: 15.04.2017 11:00 (GMT+01:00)
Til: For openEHR technical discussions 
Emne: Add SNOMED codes to values in Internal code set

Hi,

I am trying to model some archetypes using coded text. The option values should 
ideally come from SNOMED. Currently we do not have access to a terminology 
service and so we are using Internal codes to achieve what we want.

However we would like recorded values to also include their SNOMED codes for 
backward compatibility when we start using terminology service in the future. 
How can we include a terminology code with the option values in internal code 
set.

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<http://healthelife.in/>  e: 
dil...@healthelife.in<mailto:dil...@healthelife.in>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: SNOMEDCT - correct representation

[Bjørn Næss]

Thanks Ian
You are right. The correct ID is  “SNOMED-CT” . Then the example will be as 
follows:
 
Høyre øye  

  
SNOMED-CT
  
  18944008

  
I don’t think any subsets should be used on this context. What we need is a way 
to say that the code_string “18944008” is defined by the terminology defined by 
terminology_id/value = “SNOMED-CT”.  This must be done the same way by all 
openEHR systems to enable a true open platform based on openEHR archetypes.

Thanks for the feedback from all of you!



Vennlig hilsen
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: tirsdag 25. april 2017 08.03
To: For openEHR technical discussions ; 
For openEHR implementation discussions 
Subject: Re: SNOMEDCT - correct representation

SNOMED-CT is the official designator, based on the archetype editor terminology 
list.
On Tue, 25 Apr 2017 at 06:36, Pablo Pazos 
mailto:pablo.pa...@cabolabs.com>> wrote:
Congratulations about the new adoption!

The IHTSDO recommends to use exactly "SNOMED CT" as the *name*, in our specs we 
are using SNOMED-CT as the name (it should be corrected to the name preferred 
by the IHTSDO). On an event they explicitly asked to avoid the SNOMED-CT with 
the hyphen when referencing the standard.
As for the term id, I've seen [snomed-ct::35917007 on the specs, or SNOMED-CT 
on sample archetypes: 
https://github.com/openEHR/specifications-ITS/search?utf8=%E2%9C%93&q=snomed&type=
Tested on the Ocean's archetype editor and they use:

constraint_bindings = <
["SNOMED-CT"] = <
items = <
["ac0001"] = 
    >
>
>


On Mon, Apr 24, 2017 at 7:33 PM, Bjørn Næss mailto:b...@dips.no>> 
wrote:
Norway just became a SNOMED country.
One simple question – what is the correct terminologyId to use for SNOMED-CT.

Currently we use ‘SNOMEDCT’ like below. Is this correct?

 
Høyre øye

  
SNOMEDCT
  
      18944008

  

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10


___
openEHR-implementers mailing list
openehr-implement...@lists.openehr.org<mailto:openehr-implement...@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org



--
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]<http://cabolabs.com/>
http://www.cabolabs.com<http://www.cabolabs.com/>
pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>
Subscribe to our newsletter<http://eepurl.com/b_w_tj>

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

SNOMEDCT - correct representation

[Bjørn Næss]

Norway just became a SNOMED country.
One simple question - what is the correct terminologyId to use for SNOMED-CT.

Currently we use 'SNOMEDCT' like below. Is this correct?

 
Høyre øye

  
SNOMEDCT
  
  18944008

  

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

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

SV: better diagram for 'clinical investigator recording process'

[Bjørn Næss]

Great Thomas.
I did a translation of this to Norwegian (attached).

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: onsdag 8. februar 2017 14.10
Til: Openehr-Technical ; For openEHR 
clinical discussions 
Emne: better diagram for 'clinical investigator recording process'


I have created a newer version of the oft-copied and used diagram on clinical 
process<http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_information_ontology>,
 as part of progressively upgrading diagrams in various specification documents.

Source is in draw.io format; here are the source 
XML<https://github.com/openEHR/specifications-RM/blob/master/docs/ehr/diagrams/clinical_investigator_recording_process.xml>
 along with generated 
SVG<https://github.com/openEHR/specifications-RM/blob/master/docs/ehr/diagrams/clinical_investigator_recording_process.svg>
 and 
PNG<https://github.com/openEHR/specifications-RM/blob/master/docs/ehr/diagrams/clinical_investigator_recording_process.png>.

I think this is an improvement in clarity and aesthetics for this diagram; the 
new version may be useful for presentations, training etc.

comments welcome.

- thomas
7Zxhd5o8FMc/jS/nIQkEeKlWt55tfXrartte9SBE5YjEJ+Bqn0//JBAQCK60gtOueHYGCQS898fN/yaxPTRabT8yZ734Sj0S9KDmbXvoogchQNjm/4mSp7TEBEZaMGe+J0/aFdz6/xFZqMnSje+RqHRiTGkQ++tyoUvDkLhxqcxhjD6WT5vRoHzXtTMnSsGt6wRq6XffixeyFGTfS1R8Iv58IW9tQZxWTB13OWd0E8r79SCaJVtavXKytuQXjRaORx8LRWjcQyNGaZzurbYjEgjbZmZLr5vsqc2fm5EwbnIBTC/45QQbkj0xDvilwynfmYud68Ht5fjqLivnbeVV8jvET5nd/FVi2OEiXgW8BPDdwJmSYJibZUQDypKTM8Ogobzqwl/NeeuBz9ufuIG/fnBYzHfXhK75DeDkO2VLwh6+05UTPgBobfm//jqc8ybmgRMJn2t8P4oZXZLCjbA90sa7msyj4ulmfhAUzpxMJkifiPaY4/nchoU6TeO1om5Gw3jirPxAwH1PmOeEjiyWJAMkjwuXpxsvdwJ/HvIylzdPmHiqteP64ltcfAAgt2rRh9KtvwiLybZQJH36kdAVidkTP0XW6qZ8356yN1I28bijGUsEFwWOTVnmyPdnnre8Y4jvSIzqkdKfR+rzl8ury8/jmxNg6oK6MX3TTJntIAWBVUHKUJCyapDCxuFImTVIHZWSqw2LyMNXjshHRshbAqUFMpBplsjImyiQYdSR0UKwsU6DjDR8vLOhsqHDChu4ERtGC2wAoMAxJVHMDSsiYxWTAh65KBOu8ZxoQTx5oJhIWMLnunEgK1a+54kWRRtr0fJqOxcSuZ+qUtifktAbiH3RtDAK7iNL7AuDQdiHBj8IaewusluKkz8RRzwCNNP6hNrkoUAFsT1khzQktQDyTWsK4ATjGgBl0weyN+Ov1n1m/rTvGtI4pqtEFWktdWGGUYFRU2C0DRVGHbQA436lLWxSYhH/u6FZxYcosd6AnwDgerur3Omlirj6Z3g7vrkf3F3+c1Wvr/Ky9MZ7ZFcGsEfdzSqx+fBx4cfklntHlD9yrMtR9RAOGwfC0WhsTPYEwjx4n2AgrLIHVPSAVsNeK4EQHYu98f3gy7e3ih7GQ3iO6AGEn+2DLasj9OqywXfpfipoIFyOSiY8mnIHWCGDTiPC+MNzt43EiB8Xa+SEdJq102na73UaAi3rNLGdnE7zfEbc2Kdh0joTT5Rptzu6FsINtTX2oKMSpraaYALYVRZhH6vzvLy6vbv5Njqr3lPjm2036z0xPsfeE+qVpKEOvq6UWwZ19/ANzos7fdSUuyE8T+503XyWO9yRaoPqyElX2F18vbx6GF/d3fw8H/YuxKcRe8nn/NgzLL3MXjb2f5SYVzdSctSU4Y64iyRj4I26y5dkDCIoNdNp+Znd6LQuqMCgTAXQ1TEMvQ4K3AIUDaaAdor9whVO8t0yIYq3JhNLq/EWPNz83Mjs6YegpG9khz8lNHs9ETtsTrIiqTqJV1qooPqm4Tg6I4ET+79I6YZ1DpF3uKZ+EuczEWSXJ//y0aysiYhumEvkVTu3Kg1ZZTGFzMqjpDZQ2uF+dZ4Kp63FCZECUG6XZkw1mDx6U0yhhkzlgwOVuRuszvi+dO6mngqQTRxnkcUyX4cXwuVEEWnN+HoFPahOmp8HPTyOF/npWzA7vibM5zYQPcYLuIKnyhXS7NKd7EoLp4hVnfQ+D6yqQYls/fhHYT+FDdmWPG4MW+omaR9dBTDLkpsCWE2tdKx3BCCG5cCGrFf2m7pe7oANrfIsLRKoDtlv4llvhHpDi53SeOxu3hyAvvnbeXP7bxuP5VwVx2Ply67OrBstDVbASkivm1mvGaxAaP8b1TQ1yNahFXj1wxllK3KitB59lcfJ0/pIorhXnTxIVEobbIJyzpFpyyMs+kDqHNf7oo+/aNFHNSwec9EHOt8REz0vSCWjfVB6kr2EjdMTs9KXmV2lJ7pZTk8s+3XiEIFyO7iz7AQ0gOpIXezmbsPCSh+bEFYRfokw9LZQPJLZx/DAmPXyBZMHvhgthKF8oDYLQ7BZvtPKMo8Gg2x/kBj8LDHg7IipUVZtQGQ9/5OiriCCqo663zCvTuDzbxP/rhPLhGzB9LKoOWB1kqg5IScQD3B5QSDQVUms17gStiFLznbQ3c5liFAlH7S+lg+jNtYlTTUIRuUeHdiwIw2CkVV/p5eKkGpD+QK/PzG1o6tjWHckXJKVGMYaGGJZoTbjzobaMvBDP1qKB2BTwq9/DyivWEaKKgLDqEl0wAt5bfx70waaNJMEIY332bulnDbZmvT2M0N8Oshbo8JFbfi24lqkRiJU41m9Dc826CvePXvACrOKZ9VFPp15tm5R7btn2/KsUenTdTXf68qzWUQvePZ6Mw38iIg1VoXudrkJw2jJ3fje4b5iUXJ1vYTqYLuj7tZoMEF9pITeKebyWt/YzQdidYblkPkTLseR1yhA8C35mcifR8Su5nhqv12X46GXI8IPd3+wJhXru78KhMb/Aw==___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: ELEMENT.null_reason proposal

[Bjørn Næss]

That seems to be my understanding of Thomas’ suggestion – and I think that is 
the way to go. Then we will have a small set of “classes of null flavours” , 
and the detailed and local description can be added to the second field . The 
second field may then be of type DV_TEXT to allow both unstructured and coded 
values.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av David Moner
Sendt: onsdag 25. januar 2017 14.24
Til: For openEHR technical discussions 
Emne: Re: ELEMENT.null_reason proposal

So, if I understand well, the idea is to add an attribute for representing 
clinical reasons for a null flavor, maintaining the current null_flavor for 
technical reasons only. Is that right?

2017-01-25 13:34 GMT+01:00 Ian McNicoll 
mailto:i...@freshehr.com>>:
Hi Diego,

That's a pretty good suggestion, although in that case we are really abandoning 
the idea of the current fixed base set of 'technical' null-flavours and 
allowing them to be replaced by local terms, while I was suggesting something 
more like the ISM_TRANSITION setup where archetype-specific 'clinical overlays' 
can be provided via the archetyped careflow_steps but are always associated 
with the underlying state_machine and current_status attribute.

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&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=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 25 January 2017 at 11:54, Diego Boscá 
mailto:yamp...@gmail.com>> wrote:
If null_flavour is a DV_CODED_TEXT, what stops anyone to create an
specialized archetype (directly from an rm class) that has the texts
(+ codes) needed in a given country/use case?
This probably should work even if set of null_flavour codes is fixed.
I don't know if this would be enough, but in theory it provides a
workaround for all issues (except the cluster one)

2017-01-25 12:33 GMT+01:00 Thomas Beale 
mailto:thomas.be...@openehr.org>>:
>
> Silje has just pinged me again on the question of whether we should have an
> ELEMENT.null-reason or similar attribute to accommodate specific reasons for
> null_flavour being set. There are 3 PRs on this as follows:
>
> SPECPR-41 - Enable content specific flavours of null to be specified per
> archetype
> SPECPR-62 - Add a 'reason for null' text attribute in the Reference model
> SPECPR-119 - CLUSTER also needs a Null_flavour
> SPECPR-151 - Add an attribute to ELEMENT to record 'null reason'
>
> These are all reporting the same problem. (The last one can probably be
> closed as a direct duplicate of SPECPR-62). Having re-read the comments on
> all, my inclination is to propose the simple addition of an attribute
> null_reason: DV_TEXT[0..1] to the ELEMENT class. This would be optional and
> will not invalidate any existing data, but on the downside it will be a data
> field that will often be emtpy (i.e. Void, or 'null' in the Java/C sense).
>
> What would the general reaction to proposing this change be?
>
> - 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<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



--
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: Context in persistent COMPOSITION archetypes?

[Bjørn Næss]

Hi

To the first question – technical: Is it possible to have context on a 
persistent composition?
Yes – I think that should be possible. Some will argue that the context is an 
EVENT_CONTEXT and such context should only be used for event based 
Compositions. I think it makes sense to have some context also for the 
persistent ones.

Then to Ian’s follow up –what is the underlying use-case here?
The use-case seems to be based on a distributed environment where several 
healthcare providers commit their data for a given EHR (subject of care). This 
seems to be a asynchronous messaging architecture where they send messages (as 
Compositions) to update a central repository.
If this is true – then I agree with Ian that the synchronization of the 
underlying data will be hard .

The idea seems to be to keep a clinical concept within one persistent 
composition. I guess the intention by this is to be able to update a single 
source for the information about a specific concept. Then the central service 
must do some bookkeeping to make sure that each concept is updated by creating 
a new version of the specific persistent composition.

Another approach would be a more synchronized architecture. Where you first 
query for the concepts and get back all the LOCATABLE’s . Then the client will 
be able to create new versions of each entry (by creating new versions of the 
surrounding container). And when doing this – why would you like to constraint 
the model to only have one ENTRY for each COMPOSITION? This question leads me 
to suggest that the context you would like to add should be on the ENTRY – 
being an EVALUATION, OBSERVATION, etc.  Could this be a solution?

BTW: We (DIPS) are implementing openEHR FOLDER to support use-cases like this. 
We will use FOLDER to realize a “FOLDER DOCUMENT”. This is kind of a persistent 
composition – but since it is a FOLDER it can combine several autonomous 
COMPOSITIONS in a shared view. I think this actually is PERSISTENT COMPOSITION 
done the right way. I think it would be used for all use-cases where we today 
create a PERSISTENT Template to model i.e. Social Summary, Previous Diseases. 
We will post some specifications/descriptions on this soon.

/Bjørn


Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Ian McNicoll
Sendt: 18. januar 2017 17:22
Til: For openEHR technical discussions
Emne: Re: Context in persistent COMPOSITION archetypes?

Hi Silje,

Can you tell us more about the background? Are you trying to provide the model 
for the message, or to store the data when it is received (or both)?

Where does the data come from and how is it managed / curated? Does it come 
from a single clinician (presumably GP) or from multiple sources? Is it 
curated/managed by the GP or is it managed by the recipient.

In the UK, all of the emergency summaries are essentially copies of summaries 
managed and curated by the GP, so there is no need to synchronise lists, as it 
appears you are trying to do here. That is pretty difficult and even with 
simpler, safer labs messages, my understanding is that people have stopped 
sending 'diffs' i.e just a note of updates/changes in favour of re-sending the 
current full version of the message again.

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

On 18 January 2017 at 15:10, Bakke, Silje Ljosland 
mailto:silje.ljosland.ba...@nasjonalikt.no>>
 wrote:
Hi,

Is is possible to add context, ie actual text or other data types, to a 
persistent composition. The Archetype Editor doesn’t seem to support this. The 
use case is entries to the Norwegian national summary records, where each entry 
needs to be given a code (of course using a specific, National code set) about 
whether this is a new entry, a change to an existing entry, a verification or 
an refutation. Our hypothesis is to use a specific persistent COMPOSITION 
archetype for these entries, with only one entry per composition, and a coded 
text element to hold the code for the type of entry.

Is there a better way of achieving what we need to do here?

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/

SV: Use of RM:provider

[Bjørn Næss]

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

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Ian McNicoll
Sendt: tirsdag 17. januar 2017 13.43
Til: For openEHR technical discussions 
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
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com<mailto:i...@freshehr.com>
twitter: @ianmcnicoll

[https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=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 
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 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 
<mailto: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,


___
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

SV: Could the specs group consider making uid mandatory?

[Bjørn Næss]

What kind of identifier should this be? ENTRY is not versioned. Will this UID 
be a version independent identifier or should it also keep references across a 
version hierarchy?

I agree that there are good reasons to add some identifier on an ENTRY. And it 
must not be mandatory - because it breaks existing systems.  Which also tells 
it is not needed since existing systems didn't need to use the optional UID.



Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA


 Opprinnelig melding 
Fra: Thomas Beale 
Dato: 19.12.2016 02:07 (GMT+01:00)
Til: openehr-technical@lists.openehr.org
Emne: Re: Could the specs group consider making uid mandatory?



right. Good argument from evidence for the UID. Want to create a PR with these 
notes?

Not sure about mixing URIs with UIDs... OTOH, usually easy to detect by parsing.

- thomas

On 19/12/2016 09:22, Heath Frankel wrote:
I think it should be a strong recommendation rather than mandatory considering 
it is currently optional and the need for backward compatibility.
I also think it maybe difficult to apply consistently in some cases such as 
feeder data. There are cases in CDA profiles where there are mandatory IDs and 
you have to populate it with something but then need to some how retain this 
same ID over revisions etc.
I also think a uri should be an allowed type of UID to support ids that are not 
guids and possibly associated with real world ids such as lab result ids, etc.

Regards

Heath


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

SV: Could the specs group consider making uid mandatory?

[Bjørn Næss]

If you add UID on ENTRY level and you want to use that for some 
referencing/look up functionality: 
How do you handle versioning of Compositions and its content?  Is it a new 
entry UID for each version ? 

Here are description on some functions we have added to DIPS Arena EHR Server 
to make it simpler/more convenient to work with addressing LOCATABLES. 

To make it simple for client application to access the unique reference to 
LOCATABLE we have added the function ehr-uri() to the AQL query 
syntax. One example may be: 

select 
ehr-uri(o) as EHRUri, 
o/data[at0002]/origin/value as Time,
o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude as 
Weight, o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/units as 
Unit 
FROM
COMPOSITION c contains observation o[openEHR-EHR-OBSERVATION.body_weight.v1] 
order by o/data[at0002]/origin/value desc
limit 5

One example of the ehr-uri may be:  
ehr:compositions/131b9960-a2b0-452b-a140-34990dd3487d::9624982A-9F42-41A5-9318-AE13D5F5031F::1/content[openEHR-EHR-OBSERVATION.body_weight.v1
 and name/value='Body weight_001']

And then when you want to get the resource defined by the EHR-URI we have added 
a simple LINK endpoint. This looks like this: 

/api/v1/link?ehruri=ehr%3Acompositions%2F131b9960-a2b0-452b-a140-34990dd3487d%3A%3A9624982A-9F42-41A5-9318-AE13D5F5031F%3A%3A1%2Fcontent%5BopenEHR-EHR-OBSERVATION.body_weight.v1%20and%20name%2Fvalue%3D'Body%20weight_001'%5D

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

-Opprinnelig melding-
Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Pieter Bos
Sendt: tirsdag 13. desember 2016 14.42
Til: For openEHR technical discussions 
Emne: Re: Could the specs group consider making uid mandatory?

That sounds reasonable. I wonder how many existing systems already do this…

Regards,

Pieter Bos
Nedap Healthcare

On 13/12/16 14:24, "openEHR-technical on behalf of Ian McNicoll" 
 
wrote:

There may be some advantages in routine application of uid at ENTRY level.

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


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


___
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

SV: Converting Archetype into Nosql Schemes

[Bjørn Næss]

The key part of our openEHR server is the composition/path index based on 
Lucene and served by Apache Solr. 
There are no SQLs involved in the query part here. 

Vennlig hilsen
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10

-Opprinnelig melding-
Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Ian McNicoll
Sendt: fredag 14. oktober 2016 07.49
Til: For openEHR technical discussions 
Emne: Re: Converting Archetype into Nosql Schemes

Hi,

You might want to take a look at an interesting project out of Kyoto University 
that was presented at MIE2016 recently - openEHR based on neo4j.

The presentation is on the openEHR wiki at ..
https://openehr.atlassian.net/wiki/download/attachments/38436882/HEC2016-Graph-openEHR.pdf?version=1&modificationDate=1476423862176&api=v2

The developer of the EtherCis openEHR CDR, Christian Chevalley, also has 
experience of writing an openEHR CDR against Intersystems Cache.
https://github.com/ethercis.

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


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


On 13 October 2016 at 17:29, Fadoua Khennou  wrote:
> Hello,
>
> I am a Phd student, working on the implementation of OpenEhr standard 
> with Nosql technologies in order to study the performances for such 
> plateformes.
>
> And because i have just got familiar with archetypes in the ADL 
> workbench and Ocean informatics, i would like to know is there an 
> automatic way of generating from  operational template the adequate sql or 
> nosql tables?
>
> If not should i integrate any other tools or modules in order to do 
> this conversion?
>
> Thanks in advance for your response.
>
>
> My regards,
> Fadoua
>
>
> --
> Cordialement,
>
> KHENNOU Fadoua
> __
>
> Phd student at USMBA-Fes, Morocco
>
> Transmission and Processing of Information laboratory
>
> __
>
>
> ___
> 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

SV: More generic reference model

[Bjørn Næss]

This is perfect timing with ongoing activities in Norway.
There is a government lead activity to explore how to use SNOMED-CT and openEHR 
archetypes together. The first domain is to use SNOMED-CT to define anatomical 
location and structures.

The most important outcome for this is to be able to reason over data and use 
the hierarchical structure to query for all entries in lower left limb which 
should include knee and meniscus entries (pseudo-definitions given here).

In parallel with this activity we are involved in a project where they will 
build an ontology of all entities and make that ontology model/platform as a 
basis to query data from different sources (systems). We are involved since we 
think openEHR reference model with archetypes is such an ontology. But in 
addition to that we need to map terms from different other terminologies like 
SNOMED-CT, LOINC and also Disease Ontologies.

In the end I think we need a shared pattern on how to model and implement this 
- and as mentioned the most important thing is to be able to do queries on this 
hierarchical/graph structured ontologies/terminologies.



/ Bjørn Næss - Product Owner  | DIPS ASA
Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: tirsdag 6. september 2016 23.04
Til: openehr-technical@lists.openehr.org
Emne: Re: More generic reference model




I will actually have some time to start to look at this in the next few weeks - 
i.e. to facilitate / coordinate some work, and possibly do some. I would 
propose to proceed as follows:

  *   gather current unmet requirements
  *   examine current state of AQL spec to clarify what it alredy says, what it 
lacks
  *   propose changes to AQL

The question of adding e.g. an Antlr grammar for the IHTSDO constraint 
expression syntax to AQL is almost trivial; the real question to me is: what is 
the querying + terminology interaction model we are trying to achieve.

So some example queries (pseudo-code is fine) would help. If Bert and others 
who want more progress can at least post some ideas at the requirements level - 
clear and succinct as possible please - it will help a lot.

Here is a wiki page for gathering this 
information<https://openehr.atlassian.net/wiki/display/spec/Terminology+Querying+for+AQL>.
 As usual, contributors should feel free to change it as required.

- thomas

On 06/09/2016 13:05, Bert Verhees wrote:
Op 6-9-2016 om 19:01 schreef Erik Sundvall:

Many of us think that a better integration of the openEHR and the Snomed CT 
modelling efforts would be great. But there are not enough resources (e.g. 
dedicated time of people with the right knowledge) being put into doing this, 
since this is hard (but interesting) work usually requiring somebody to pay 
people...

Hi Erik,

I do not want to undermine the value of your statement, contrary, I think it is 
very good when some organization or country builds the thing, the money 
involved is a piece of cake for such an entity.
Let the people with good connections start working on getting this arranged
The sooner the better!!!
---
But on the other hand, we should sit down and wait until something will happen.
First, I think, we need a list of requirements. We could start with that.
We need that anyway, even if someone succeeds in getting a big company or 
government to finance the project.

In my opinion, the most difficult work is the definition, following the (to be 
defined) requirements, how is this project going to look like?
Someone with experience in modeling modeling-languages and query-languages, 
someone who is clever in thinking about syntaxes and structures.

The implementing itself is easier, it is just programming. With help of ANTLR 
and a good definition, this will not be too hard.
Like there are written ADL-parsers/AQL-parsers as open source.
When there is a prototype ready, others can improve it, or inspired by a lousy 
prototype, start a new better one.
That is how open source usually works, and it can create big things. We know 
that.

I can help, I have knowledge of AQL, ADL, and SCT (expression constraints), 
enough of all three to add sensible ideas. But I cannot do it on my own.
I do not feel too confident. There is also a risk of failure when doing this 
alone.

So, to set up the requirements, how can we cooperate on that?
Do you have an idea?

Maybe a wiki? Someone needs to take the lead. Say how things are to be done, 
facilitates, etc.

Maybe it is too much to ask for someone to take the lead.
Let first inventory who wants to help. It will cost maybe a few hours in this 
initial phase.

--
So, who wants to help with this sub-project:
- having ideas about features
- set up requirements
- set up some global architecture

SV: Personal Health Record using CHBase (related to Health Vault)

[Bjørn Næss]

I have not looked into this before. This is a platform we have to deal with 
somehow – especially vendors in the Swedish market that wants to integrate with 
patient data.

Have you done any investigation on the datatypes to compare with openEHR 
clinical models?
In what way are the clinical models developed in CHBase?
Who is the owner of this platform and specification?

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Erik Sundvall
Sendt: mandag 30. mai 2016 17.50
Til: openehr-technical@lists.openehr.org
Emne: Personal Health Record using CHBase (related to Health Vault)

Hi!

The Swedish Government is financing and handing out a Personal Health Record 
service/platform to the Swedes. Now developers can find info about it at 
http://developer.halsaformig.se/

It seems to be based on CHBase http://www.getrealhealth.com/chbase/ that uses 
many of the API features equal or similar to Microsoft Health Vault.

The health-related PHR models are fairly simple (not many datapoints/details) 
and there are not very many models. The main ones are listed at 
http://developer.halsaformig.se/Reference/DataTypeMapping  and if you register 
for a free developer-account at https://developer.chbase.com/ you can read more 
details, for example this:

  *   Extending data types at 
https://developer.chbase.com/chbase/en-US/docs/Develop/Dn783274 that tells many 
things* including that any datatype can be extended by arbitrary XML as long as 
there is a transform backt to HTML registered with URI.
  *   HL7 FHIR integrations are being worked on.
Now to the questions:

  *   Have any of you already looked into openEHR mappings to/from CHBase or 
Microsoft Health Vault?
  *   The extension mechanism in CHBase is very permissive, using free-form 
XML, that could of course lead to semantc chaos with several overlapping 
incompatible extensions for the same kind of clinical data. I guess it could 
aslo be used to carry some suitable forms of openEHR-data in a more diciplined 
reusable manner. Any thoughts about that?
  *   Would it be a good idea to define a canonical way of storing openEHR data 
in CHBase/HealthVault so that all openEHR-based systems interacting with those 
products do it the same way and thus can exchange the semantically richer 
openEHR-based data as extensions via the PHRs? (Useful in the cases where that 
is the one of the few viable ways due to legal restrictions etc. Of course that 
is an unnecessary detour in the cases when you are allowed to do direct native 
communication between openEHR systems.)

(I guess this would be a suitable task for master-thesis students or beginning 
PhDs

Best regards

Erik Sundvall　

Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 
010-1036252 in Sweden)
RÖ:　
erik.sundv...@regionostergotland.se<mailto:erik.sundv...@regionostergotland.se> 
(previously lio.se) http://www.regionostergotland.se/cmit/
LiU:　erik.sundv...@liu.se<mailto:erik.sundv...@liu.se/t_blank>　
http://www.imt.liu.se/~erisu/







*) Excerpt from https://developer.chbase.com/chbase/en-US/docs/Develop/Dn783274 
below:



When building your application, you may find that you need to store additional 
information with an existing data type. For example, if you are using the 
Height data type, but you want to keep track of whether people were sleeping 
immediately before height was measured because the spine compresses during the 
day. The question is whether to:

  *   Incorporate this information into the existing base data type
  *   Use some other existing data type
  *   Ask the CHBase developers to create a new data type
  *   Extend the existing data type

To determine the appropriate course of action, inquire in the CHBase 
Forum<http://forum.chbase.com/>.

If the response to your inquiry is that the additional information should be 
stored as an extension of an existing type, you use the 
Extensions<https://developer.chbase.com/chbase/en-us/docs/sdk/P_CHBase_SDK_CommonItemData_Extensions>
 property of the 
CommonItemData<https://developer.chbase.com/chbase/en-us/docs/sdk/T_CHBase_SDK_CommonItemData>
 object returned by the HealthRecordItem . . :: . . 
CommonData<https://developer.chbase.com/chbase/en-us/docs/sdk/P_CHBase_SDK_HealthRecordItem_CommonData>
 property, which is a collection of 
HealthRecordItemExtension<https://developer.chbase.com/chbase/en-us/docs/sdk/T_CHBase_SDK_HealthRecordItemExtension>
 objects. By default, there's nothing in this list. If you have an instance and 
you add an extension instance to it, the framework saves that instance to the 
server and returns it when you read that instance back out.

CHBase data types can be extended by inserting XML into the 
HealthRecordItemExtension or by using a custom extension class. In the first 
method, you work with the XML details, which can be a bit clu

SV: SV: Usage of Compositoin.Category

[Bjørn Næss]

On 11/04/2016 11:07, Bjørn Næss wrote:
But if we want to avoid double results in querying, we need some sort of 
'is_derived' or 'is_copy' marker (and a link to original content) on the copy. 
At least that's where I got to the last time I thought about it.

Yes - I think we need some kind of marked. We have been thinking about adding 
this to the link. Some kind of "link to self". Then to avoid duplicates you 
MUST include that in every AQL. This is why we ended up with the proposal of a 
Composition category which solely of re-used (copies) data.

I'm not sure if this has the flexibility you (we) really want thought does it? 
It means that the entire Composition has to be treated as duplicate info to be 
excluded from query evaluation.

BNA: No you are right. It doesn't give the right level of flexibility when it 
comes to generating a Composition. So it is a trade off with the problem of 
duplicates when querying. We are working on a pattern for the user-inteface to 
cope with this problem. Because the end-user would like to "feel like" he is 
editing like before. But what is actually is doing is to create entries which 
will be referenced as copies.

And as you said : all the content of a given Composition MUST be treated like a 
copy. Only the metadata and mostly author and context.start_time should be new. 
This is not an ideal requirement/design - but the best of many worse choices so 
far



The same pattern could be applied on several levels (ENTRY, CLUSTER). I.e. a 
Blood Pressure with an attribute 'is_copy' should by default be excluded from 
AQL queries.

Something like that?


Right. If we did it in the most general fashion possible, 
LOCATABLE<http://www.openehr.org/releases/RM/latest/docs/common/common.html#_archetyped_package>
 could have a Boolean flag 'is_copy'. But then you have a False Boolean on 99% 
of all data, which is not great data design. If we say that any copy has to 
have a LINK attached pointing to what it is a copy of, then your suggestion 
above is better (if I understand correctly) - put an 'is_copy' flag there. It 
could be argued that 'meaning' should encode whether something is a copy or 
not, but I think a separate flag would be better, and in any case 'meaning' 
might still carry different reasons for making copies.

BNA: Yes - I think we should maintain meaning to carry optional reason for 
making a copy. And then we need to have the specific flag to tell if it is a 
copy.

- thomas


Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: mandag 11. april 2016 12.42
Til: openehr-technical@lists.openehr.org
Emne: Re: SV: Usage of Compositoin.Category

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

SV: Usage of Compositoin.Category

[Bjørn Næss]

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

Yes – I think we need some kind of marked. We have been thinking about adding 
this to the link. Some kind of “link to self”. Then to avoid duplicates you 
MUST include that in every AQL. This is why we ended up with the proposal of a 
Composition category which solely of re-used (copies) data.

The same pattern could be applied on several levels (ENTRY, CLUSTER). I.e. a 
Blood Pressure with an attribute ‘is_copy’ should by default be excluded from 
AQL queries.

Something like that?

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: søndag 3. april 2016 15.31
Til: openehr-technical@lists.openehr.org
Emne: Re: Usage of Compositoin.Category


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

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

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

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

Hi Ivar,



I'm not sure the situation is quite as clear-cut, in that I donlt

think there is necessarilly a simple distinction between primary data

which should normally be query-accessible and in-line vs. secondary

data which is normally query-inaccessible and referenced.



A few scenarios



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



2. Diagnosis event. Primary, in-line but depending on whether a

secondary problem list is maintained, you may not want to use these

original diagnoses events for decision support.



3. Problem summary. Secondary and definitely need to be

query-accessible, but may be in-line or referenced depending on

implementation.



4. Discharge summary. Mostly secondary but may introduce new primary

content and again, whether the content is in-lie or referenced is to

some extent an implementation decision. DIPS have decided to use

referencing, others do not.



5. End of Life Summary. The critical aspects of this document are

primary e.g Resuscitation wishes but other aspects are secondary

(though and may be in-line or referenced.



I think the points raised are valid but we may need to tease out

several axes here.



Ian







Dr Ian McNicoll

mobile +44 (0)775 209 7859

office +44 (0)1536 414994

skype: ianmcnicoll

email: i...@freshehr.com<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 11 March 2016 at 09:39, Ivar Yrke <mailto:i...@dips.no> wrote:

Hi

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



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



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

Adressing of i.e. discharge summaries

[Bjørn Næss]

There is a lot of compositions that is created for the purpose of sending the 
content to another healthcare provider. Discharge summaries is one example.
For instruction health care service request there is some elements and slots 
added to the protocol part. Here you can add both the requestor and the 
identifier.

In the Nehta CKM there is a composition archetype for referral. This archetype 
has some structure under context to add participation and identification of the 
requestor. I think this pattern would be the right way to do this.

Anyone with experiences or suggestions on how to do this?



Best regards
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10

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

SV: SV: Usage of Compositoin.Category

[Bjørn Næss]

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

The discussions about links: 
Yes we could use links. But where should we add the links? From my point of 
view the only place to add these lnks would be on the composition root. But 
then you miss the opportunity to add relationship between links. And there is a 
large group of archetyped compositions that is added into to EHR , but they are 
transported to another system on some other information model (HL7, EDIFACT, 
PDF, Paper, etc.). The simple idea behind this proposal is to define a generic 
system to create openEHR compositions that is the primary source for all this 
kind of messages. The only needed thing is to either use TDD or some other 
transformation of a "compiled" composition.  As far as I can see now this is 
the simplest and most efficient way to handle this. Then the content may be 
archetyped and the transformation could work directly on the RM model to create 
the expected outcome.


Best regards
Bjørn Næss
Product owner 
DIPS ASA

Mobil +47 93 43 29 10


-Opprinnelig melding-
Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: fredag 11. mars 2016 14.12
Til: openehr-technical@lists.openehr.org
Emne: Re: SV: Usage of Compositoin.Category


Currently I think we filter on 'report' COMPOSITIONs via something like:

FROM COMPOSITION c[openEHR-EHR-COMPOSITION.report.v1]
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.body_weight.v1]

So that would not need any change to the COMPOSITION.category to be achieved. 
Not saying there are not reasons to do it, just that the normal way today seems 
to satisfy the requirement.

Secondly, just a mechanical AQL thing: it should normally be possible to do:

WHERE c/category/defining_code matches {[openehr::434]}

- thomas

On 10/03/2016 12:32, Bjørn Næss wrote:
> Hi Ian
> Great response.
>
> The most important thing for me is to precisely define the semantic meaning 
> of the content in a composition. In this specific use-case the content of the 
> composition is always a copy of the primary source.
> This means that the Discharge letter only bring one new thing into the EHR - 
> that is the fact that there is an approved discharge letter. But the entries 
> in the composition is link and copies of entries in other primary sources.
>
> The requirements to the system is quite small:
>
> * Content of "report" documents MUST not be in the resultset when doing 
> normal AQL queries.
> * It MUST be possible to query for "report" compositions with specific 
> content.
>
> The solution to this problem is simple and I can give an example with an AQL 
> query. Below is a standard query for body weight. Look at the WHERE 
> condition. Here I am looking for all body weights which are NOT part of a 
> report composition. This WHERE condition will be the default filter on all 
> queries.
> If the client would like to query for all body weights in report document, 
> then just change from NOT EQUALS 434 to EQUALS 434.
>
>   SELECT 
> o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude
>   FROM COMPOSITION c
>   CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.body_weight.v1]
>   WHERE c/category/defining_code/terminology_id/value = 'openehr'AND 
> c/category/defining_code/code_string != '434'
>
>
> Given that we agree that there is a class of compositions which belongs to 
> the "report" group.
> Then we should add such semantic into the RM to make it precise and 
> consistent.
>
>
> Best regards
> Bjørn Næss
> Product owner
> DIPS ASA
>
> Mobil +47 93 43 29 10
>


___
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

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

[Bjørn Næss]

Yes - there must be some kind of misunderstanding. The intention have never 
been that end-user should do the important and challenging work on developing 
clinicial information models (archetypes). The idea have been that this gives 
the clinical community an opportunity to influent and co-operate in this work.

I think all agree that the development and deployment of ICT solutions for 
healthcare is a large socio-organizational-technical challenge.  The work done 
by domain experts is only a (important and essential) part of that problem 
domain.



Best regards
Bjørn Næss
Product owner
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: fredag 11. mars 2016 15.16
Til: openehr-clini...@lists.openehr.org; Openehr-Technical 

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


I can only see the abstract for now, but I think the authors seem to have 
developed the misconception that end-users would somehow be designing 
applications. openEHR doesn't try to do that, and it's the first time I've 
heard anyone suggest it. openEHR just enables domain experts (generally = a 
small proportion of healthcare professionals, who might also be some kind of 
system user in some part of the world) to more directly define the information 
content of the system, in such a way that it can be processed and queried on a 
semantic level.

The Business Purpose of Archetypes section in the Archetype Technology Overview 
<http://www.openehr.org/releases/AM/latest/docs/Overview/Overview.html#_business_purpose_of_archetypes>
 may help to show why this is useful and necessary (it's short!).

There are still many other problems to solve such as clinical workflows and 
user interaction / UX.

I am currently at Intermountain Health in Salt Lake City working with the 
Activity Based Design (ABD) group that has developed a new architecture that I 
think has a realistic chance of addressing a) workflow (e.g. typical nursing 
tasks like cannulation; more complex cooperative workflows that involve shared 
care) and b) some aspects of UI interaction within workflows. They are just at 
an early prototype stage, and it has taken nearly 2 years to get to the current 
architecture (naturally taking into account many previous attempts and 
experience).

This effort is the first I have seen that has what I think may be the needed 
theoretical understanding and technical architecture to starting to solve 
clinical process and (some of) UI/UX. And what does it rely on? Formal clinical 
models, and it assumes that those models are created by clinical experts. Not 
only that, it explicitly assumes a 'template' concept of the same kind as 
openEHR's, in order to construct useful data sets.

It considers these 'templates' as the basis of an 'Activity' description, which 
then adds new abilities to blend in some presentation directives, pre- and 
post-conditions, some workflow elements, cost-related items (e.g. ICD coding) 
and so on. The innovation here is to consider an Activity a unit of clinical 
work and to attach these process-related semantics into that level of artefact.

So let's just reflect on the fact that this research is only now emerging from 
one of the leading institutions in the world that has historically specialised 
in workflow and decision support.

openEHR as it is today is just a semantic content + querying platform, and I 
think we can reasonably say that we have some handle on generating 
developer-usable artefacts, i.e. things like TDS, TDO etc, but they are all 
content related. These are starting to be standardised now.

The openEHR of today needs to leverage new work such as ABD (or something like 
it) to achieve many of the things that the Norwegian paper talks about. The 
paper seems to be critiquing a somewhat unrealistic set of expectations re: 
openEHR, although I am sure it has useful lessons.

I'll provide a proper description of ABD ASAP, which I think will provide our 
community (particularly those working on clinical workflow, process etc) new 
ideas on 'the next layer' for openEHR.

- thomas
On 09/03/2016 23:58, Bakke, Silje Ljosland wrote:
Hi everyone!

As some of you may have noticed, a paper called "Evaluating Model-Driven 
Development for large-scale EHRs through the openEHR approach" 
(http://www.sciencedirect.com/science/article/pii/S1386505616300247) was 
recently published by a PhD student at the University of Tromsø. The paper has 
some pretty direct criticism of the ideal of wide clinical engagement in widely 
reusable information models, as well as the clear division between the clinical 
and the technical domain inherent in the openEHR model. I think a lot of the 
observations detailed in the paper are probably correct, for its limited scope 
(one Norwegian region and 4 y

SV: Usage of Compositoin.Category

[Bjørn Næss]

Hi Ian 
Great response. 

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

The requirements to the system is quite small: 

* Content of "report" documents MUST not be in the resultset when doing normal 
AQL queries. 
* It MUST be possible to query for "report" compositions with specific content. 

The solution to this problem is simple and I can give an example with an AQL 
query. Below is a standard query for body weight. Look at the WHERE condition. 
Here I am looking for all body weights which are NOT part of a report 
composition. This WHERE condition will be the default filter on all queries. 
If the client would like to query for all body weights in report document, then 
just change from NOT EQUALS 434 to EQUALS 434. 

SELECT 
o/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude 
FROM COMPOSITION c
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.body_weight.v1]
WHERE c/category/defining_code/terminology_id/value = 'openehr'AND 
c/category/defining_code/code_string != '434'


Given that we agree that there is a class of compositions which belongs to the 
"report" group.
Then we should add such semantic into the RM to make it precise and consistent. 


Best regards
Bjørn Næss
Product owner 
DIPS ASA

Mobil +47 93 43 29 10

-Opprinnelig melding-
Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Ian McNicoll
Sendt: mandag 7. mars 2016 18.16
Til: For openEHR technical discussions 
Emne: Re: Usage of Compositoin.Category

Hi Björn,

I finally got around to thinking a bit about this.

It is an interesting problem and I think I can see the need to specify 
different data handling requirements but I am not sure that overloading 
composition.category is the best approach here.

I suspect this will take a bit of teasing out (and other commit/query strategy 
metadata) - might it be better to put this in a cluster archetype in the 
Composition extension slot. That would let us play around with the requirements 
before pushing something definitive to the RM?

So far I have 3 axes:

1. Normal commit strategy: persistence vs. event  i.e do we normally overwrite 
an existing composition.

2. Source-of-truth i.e. Should this document be regarded as the primary source 
of truth for certain kinds of data or otherwise e.g Does a system look into 
event compositions or e.g to a Problem list for 'current problems'

3. Is this a primary document or secondary document? e.g. a Discharge letter is 
a secondary document derived from other primary records.

Just starting the discussion :)

Ian


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

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


On 17 February 2016 at 21:59, Bjørn Næss  wrote:
> We are discussing the use of Composition.Category which is a DV_CODED_TEXT.
>
> There is a terminology:
>
>
>
> 
>
>
>
>
>
> 
>
>
>
> Is it required to use only these categories or could an application 
> set any DV_CODED_TEXT?
>
>
>
> I think it would be ok to allow any category in this.
>
>
>
> To be concrete:
>
> The use-case is discharge summaries. These are Compositions which only
> (“mostly”) contains links to existing entries. We will be using links 
> but since the Composition should be transferred to another health 
> provider it must be serialized and validated against an template. 
> Technically this Compostions contains a lot of entries which is “link to 
> self”.
>
>
>
> The idea we are considering is to introduce a category for these 
> Compositions. The content will not be part of AQL results for normal 
> use-cases. But IF you ask explicit for these categories you will be 
> able to query for discharge summaries which contains body weight above 120 kg.
>
>  If we only add the references as links it will not be possible to add 
> them into forms and neither use a Template to validate the content. 
> This is the reason we are “thinking out of the box”.
>
>
>
> Any comments on this?
>
>
>
>
>
> Best regards
> Bjørn Næss
> Product Owner – Arena EHR
> DIPS ASA
>
&

SV: Usage of Compositoin.Category

[Bjørn Næss]

Actually - I did this concrete e-mail and addition to get some feedback on my 
previous e-mail :)
And as you say Thomas: The most important thing now is to have some input on 
the concept or semantics of this new term.

Currently we are prototyping on this functionality to see how it would work 
regarding creating, saving and querying content based on these attributes.

The concrete number, 434, was picked since it was not used and was in the same 
serie as the other category number.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Thomas Beale
Sendt: fredag 4. mars 2016 09.50
Til: openehr-technical@lists.openehr.org
Emne: Re: Usage of Compositoin.Category


Re: process, yes, it needs to be managed separately. Ian is the terminology 
component owner. But I assumed Bjørn  was talking about the semantics of the 
new term - 'Report'. Bjørn - can you elaborate on what Compositions would merit 
the 'report' Composition category?

- thomas
On 04/03/2016 08:45, Heath Frankel wrote:
Hi Bjorn,
How did you come up with the concept id of 434? We need to be careful about 
assigning our own concept ids, we really need openEHR to assign these, I 
suggest through the SEC process initiated by a Jira card.

At present we have two terminology files, as you know we have agreed to use the 
java implementation's terminology xml file as the interim standard 
representation but there are already concept ids allocated in the Archetype 
Editor terminology file which existed before the terminology specification and 
the java implementation. In this case it looks like 434 is safe to use as it is 
not assigned to an openEHR concept in the Archetype Editor, but 435 is 
allocated to an openEHR concept in the setting group, which appears to be 
missing from the terminology specification and the java implementation xml.

Let's start using the SEC process for managing openehr terminology concepts.

Regards

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bjørn Næss
Sent: Friday, 4 March 2016 6:46 PM
To: For openEHR technical discussions 
<mailto:openehr-technical@lists.openehr.org>
Cc: Team Selecta <mailto:teamsele...@dips.no>
Subject: SV: Usage of Compositoin.Category

I just added a «composition category» on my fork of the terminology project.

https://github.com/bjornna/terminology/commit/600dec3058cd85f9db3e5859d6bffa7f01a45edf



   
   
+ 


Any comments?


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

SV: Usage of Compositoin.Category

[Bjørn Næss]

I just added a «composition category» on my fork of the terminology project.

https://github.com/bjornna/terminology/commit/600dec3058cd85f9db3e5859d6bffa7f01a45edf



   
   
+ 


Any comments?

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Bjørn Næss
Sendt: onsdag 17. februar 2016 22.00
Til: openehr-technical@lists.openehr.org
Emne: Usage of Compositoin.Category

We are discussing the use of Composition.Category which is a DV_CODED_TEXT.
There is a terminology:


   
   


Is it required to use only these categories or could an application set any 
DV_CODED_TEXT?

I think it would be ok to allow any category in this.

To be concrete:
The use-case is discharge summaries. These are Compositions which only 
("mostly") contains links to existing entries. We will be using links but since 
the Composition should be transferred to another health provider it must be 
serialized and validated against an template. Technically this Compostions 
contains a lot of entries which is "link to self".

The idea we are considering is to introduce a category for these Compositions. 
The content will not be part of AQL results for normal use-cases. But IF you 
ask explicit for these categories you will be able to query for discharge 
summaries which contains body weight above 120 kg.
 If we only add the references as links it will not be possible to add them 
into forms and neither use a Template to validate the content. This is the 
reason we are "thinking out of the box".

Any comments on this?


Best regards
Bjørn Næss
Product Owner - Arena EHR
DIPS ASA

Mobil +47 93 43 29 10

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

Usage of Compositoin.Category

[Bjørn Næss]

We are discussing the use of Composition.Category which is a DV_CODED_TEXT.
There is a terminology:


   
   


Is it required to use only these categories or could an application set any 
DV_CODED_TEXT?

I think it would be ok to allow any category in this.

To be concrete:
The use-case is discharge summaries. These are Compositions which only 
("mostly") contains links to existing entries. We will be using links but since 
the Composition should be transferred to another health provider it must be 
serialized and validated against an template. Technically this Compostions 
contains a lot of entries which is "link to self".

The idea we are considering is to introduce a category for these Compositions. 
The content will not be part of AQL results for normal use-cases. But IF you 
ask explicit for these categories you will be able to query for discharge 
summaries which contains body weight above 120 kg.
 If we only add the references as links it will not be possible to add them 
into forms and neither use a Template to validate the content. This is the 
reason we are "thinking out of the box".

Any comments on this?


Best regards
Bjørn Næss
Product Owner - Arena EHR
DIPS ASA

Mobil +47 93 43 29 10

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

RE: Archetype publication question - implications for implementers

[Bjørn Næss]

Hi
A breaking change should always be new major version.
Then the problem is that changing version number introduces a huge cost. The 
cost is of course to the implementers - and by this I mean vendors, health care 
providers, national registries, integrations and so on. The whole ecosystem is 
influenced by such a change. Which makes it necessary to do a) not eagerly push 
major changes and b) when needed major changes should not influence earlier 
entries.

In this concrete change of Archetype there is two major changes:

1) Introduce UCUM as UNIT
I think we should just add a new unit - the UCUM and make the older deprecated. 
But keep both of them. This makes it possible to migrate slowly to the new 
schema for unit. In this case it is important to verify that the magnitude 90 
is the same for each of the unit. And it is the only two units used. This makes 
it somehow safe to compare the magnitude without checking the unit.

2) Migrate from CLUSTER for Location to a choice between DvCodedText and DvText
This changes is on one side a change in pattern and on the other side a 
reduction in functionality.


I guess the pattern change is introduced to handle uncertainty in two flavours.

1.   The list of local codes will never be complete - let us introduce the 
choice to also use free text

2.   The list of local codes is not precise enough - let us introduce the 
choice to explain the element with free text

This uncertainty will always be present when using coded text to describe a 
phenomena. It will never be precise enough and cover all use-cases. Given this 
- what is the criteria to introduce choice between text and coded text? Is this 
a normal case for this kind of elements? To simplify :

Colours: a) RED, b) BLUE, c) GREEN d)Other. RED, BLUE and GREEEN cover the 80% 
use-case. Other covers the rest. We have several options to model this:


a)  Expand the list of colours and add new colours as new requirements 
appear

b)  Introduce a supporting element to specify colour if other is selected

c)   Leave colours as Text field with the possibility to

a.   Add list of items in Template (limited or not limited to list)

b.  Add list of coded items in Template

c.   Bind element to Terminology in Template

Why is pattern a) chosen as the best way to model this kind of features?

The reduction in functionality in the Archetype is because the user now is 
restricted to 0..1 coded text or text. Before could user choose between 0..1 
coded text and an additional text so describe details of the location. I guess 
this is an wanted reduction in functionality and the intention may be to make 
entries more precise.


In my, technical, opinion: The changes introduced on this specific archetype 
should be applied in in such a way that no breaking changes are introduced. 
Just add UCUM and leave the CLUSTER as is and use the specific location to add 
specific details. Propose the changes as a possible new major version 
(v2-ALPHA) and collect more changes before forcing a new major version.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-implementers 
[mailto:openehr-implementers-boun...@lists.openehr.org] On Behalf Of Heather 
Leslie
Sent: 2. oktober 2015 06:11
To: For openEHR clinical discussions ; For 
openEHR implementation discussions ; 
For openEHR technical discussions 
Subject: Archetype publication question - implications for implementers

Hi everyone,

I'm seeking community input around a conundrum that has arisen regarding 
archetype governance or, more specifically, if we should offer a new version of 
an archetype that included breaking changes/corrections according to the 
openEHR specifications but which are not critical in terms of clinical safety - 
a bit of a grey zone, if you like. If clinical safety were implicated, the 
decision would be easy.

The Blood Pressure archetype was published in 2009 and I believe is in fairly 
wide use in systems at this point. Currently published version 
here<http://ckm.openehr.org/ckm/#showArchetype_1013.1.130>, and which has had 
only 'trivial', non-breaking changes, including addition of translations, etc 
since publication.

Recently the Norwegian community translated the archetype and then undertook a 
local review of the archetype. They have suggested some modifications to the 
archetype which include updating some of the data elements around identifying 
the body location of the BP measurement to be in keeping with more recent 
archetype patterns that we have been using, plus identified that the 
representation of degrees of Tilt was not using the UCUM units, plus a few 
minor additions.

The result is that their new candidate archetype 
(here<http://ckm.openehr.org/ckm/#showArchetype_1013.1.2189>) which includes 
these changes is regarded as a Major revision under our current CKM versioning 
rules and if republished warrants becoming a version 2

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

[Bjørn Næss]

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" 
Dato: 28.08.2015 15.05 (GMT+01:00)
Til: 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 / Twitter: 
@arketyper_no

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

LOCATABLE REF and EHR URI

[Bjørn Næss]

Looking at the Locatable Ref class: 
http://openehr.org/releases/1.0.2/architecture/rm/support_im.pdf

The as_uri function of LOCATABLE_REF is defined to return the following: 
"ehr://" + id.value + "/" + path

If we read Architecture Overview:  
http://openehr.org/releases/1.0.2/architecture/overview.pdf at page 
64.
The EHR scheme is defined as: 
ehr:ehr_locator/top_level_structure_locator/path_inside_top_level_structure

We get a little confused and think one of them is wrong.

I we define the following:
a = ehr_locator
b = top_level_structure_locator
c = path_inside_top_level_structure

Given the support_im definition we get the following allowed EHR uris:
ehr:/ a / b / c
ehr:/a/b
ehr://b/c

And given the architecture overview we get the following allowed uris:

ehr: a / b / c
ehr:a/b
ehr:/b/c


Which one is correct?
Could they both be correct? If yes - please explain.

Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

-- next part --
An HTML attachment was scrubbed...
URL: 

ISM Transition : definition of allowed transitions

[Bjørn Næss]

Thanks Ian
I forgot to tell that the example was only technical. I just picked Medication 
as an example ?
Anyway I guess this kind of technical possibilities is useful for the pharmacy 
review. And - then we must work on the tools to support this kind of 
definitions.

/
Bj?rn N?ss
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Ian McNicoll
Sent: 5. mars 2015 10:27
To: For openEHR technical discussions
Cc: openehr-implementers at lists.openehr.org
Subject: Re: ISM Transition : definition of allowed transitions

Hi Bj?rn,

I'm not sure I can answer your technical question but thought I should flag up 
that I am likely to be working on the pharmacy review use case for a UK 
project. My initial analysis is that this might require a separate archetype, 
or at least some extra detail. It might be worth comparing requirements.

Ian

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

Director, freshEHR Clinical Informatics
Director, openEHR Foundation
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 3 March 2015 at 13:46, Bj?rn N?ss mailto:bna at dips.no>> 
wrote:
NB! This is a new e-mail on the same subject since I didn?t see any mail on the 
mailing list. Just to check if it is working

We are currently developing a module for Careplan based on openEHR Archetypes. 
We are using INSTRUCTION/ACTIVITY/ACTION archetypes to model the clinical 
process.

One issue we are facing is the need to define which transitions that are 
allowed for a given Careflow Step.


To explain I will use openEHR-EHR-ACTION.medication.v1 as example. This ACTION 
archetype have Review medication as an possible ISM_TRANSITION. This is an 
transition that ends in ACTIVE state.
What we want to express is that this careflow step is only allowed for an 
active step (openehr::543). This means that is it not allowed to do this 
careflow step as a start transition (openehr::540).

A proposed ADL definition for this is given below:

ISM_TRANSITION[at0005] matches { -- Review medication
current_state matches {
   DV_CODED_TEXT matches {
 defining_code matches 
{[openehr::245]}
   }
}
transition matches{
   DV_CODED_TEXT matches {
 defining_code matches 
{[openehr::543] } ? only allow transition 543 (active)
   }
}
careflow_step matches {
   DV_CODED_TEXT matches {
 defining_code matches 
{[local::at0005]}-- Review medication
}
  }
}

To expand this example we want to allow only two transitions, i.e. ?active 
step? (openehr::543) and ?resume? (openehr::546).

A proposed ADL definition for this is  given below:


ISM_TRANSITION[at0005] matches { -- Review medication
current_state matches {
   DV_CODED_TEXT matches {
 defining_code matches 
{[openehr::245]}
   }
}
transition matches{
   DV_CODED_TEXT matches {
 defining_code matches 
{[openehr::543],[openehr::546] }
   }
}
careflow_step matches {
   DV_CODED_TEXT matches {
 defining_code matches 
{[local::at0005]}-- Review medication
}
  }
}


And then the questions:


1.   Is the first example allowed?
(defining the allowed transition)

2.   Is the second example allowed?
(defining two allowed transitions)





Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10


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

-- next part --
An HTML attachment was scrubbed...
URL: 

ISM Transition : definition of allowed transitions

[Bjørn Næss]

NB! This is a new e-mail on the same subject since I didn't see any mail on the 
mailing list. Just to check if it is working

We are currently developing a module for Careplan based on openEHR Archetypes. 
We are using INSTRUCTION/ACTIVITY/ACTION archetypes to model the clinical 
process.

One issue we are facing is the need to define which transitions that are 
allowed for a given Careflow Step.


To explain I will use openEHR-EHR-ACTION.medication.v1 as example. This ACTION 
archetype have Review medication as an possible ISM_TRANSITION. This is an 
transition that ends in ACTIVE state.
What we want to express is that this careflow step is only allowed for an 
active step (openehr::543). This means that is it not allowed to do this 
careflow step as a start transition (openehr::540).

A proposed ADL definition for this is given below:

ISM_TRANSITION[at0005] matches { -- Review medication
current_state matches {
   DV_CODED_TEXT matches {
 defining_code matches 
{[openehr::245]}
   }
}
transition matches{
   DV_CODED_TEXT matches {
 defining_code matches 
{[openehr::543] } - only allow transition 543 (active)
   }
}
careflow_step matches {
   DV_CODED_TEXT matches {
 defining_code matches 
{[local::at0005]}-- Review medication
}
  }
}

To expand this example we want to allow only two transitions, i.e. "active 
step" (openehr::543) and "resume" (openehr::546).

A proposed ADL definition for this is  given below:


ISM_TRANSITION[at0005] matches { -- Review medication
current_state matches {
   DV_CODED_TEXT matches {
 defining_code matches 
{[openehr::245]}
   }
}
transition matches{
   DV_CODED_TEXT matches {
 defining_code matches 
{[openehr::543],[openehr::546] }
   }
}
careflow_step matches {
   DV_CODED_TEXT matches {
 defining_code matches 
{[local::at0005]}-- Review medication
}
  }
}


And then the questions:


1.   Is the first example allowed?
(defining the allowed transition)

2.   Is the second example allowed?
(defining two allowed transitions)





Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

-- next part --
An HTML attachment was scrubbed...
URL: 

Problem-oriented records and querying by problem

[Bjørn Næss]

I like this approach.  The master care plan is what we call Patient plan.  
There should be only one of this in a given EHR. This plan evolves over time as 
more items are addes or removed.

To administer this plan you need a dashboard with functionality to filter on 
overdue,  finished,  etc. And of course you need commands like add, update,  
finish, etc.

The plan is a master view on plan items from different systems and with 
contributions from all health care specialities.

Depending on the users point of view it should be possible to dig into details 
about specific parts of the plan.

I am not sure if it is possible to archetype this dashboard.  I guess this is 
up to the application to implement this.  The clinical modeller should 
archetype the content of different plan items.  To make this work we need a 
basic set of INSTRUCTON/ACTIVITY/ACTION archetypes that make the outer 
boundaries of a care plan and care plan elements.


Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

 Original message 
From: Thomas Beale
Date:20/11/2014 19:07 (GMT+01:00)
To: openehr-technical at lists.openehr.org
Subject: Re: Problem-oriented records and querying by problem


I wonder if the GP 'master care plan' is more like a 'care plan
dashboard' rather than an actual care plan? With functions like 'show
all overdue / suspended / etc etc'...

- thomas

On 20/11/2014 17:25, Heather Leslie wrote:
> Hi Karsten,
>
> I think in practice you will see a variety of care plans depending on the 
> context.
>
> The endocrinologist will be using a diabetes care plan for their care of the 
> patient, and likely not having access to, nor particularly interested in, 
> what other specialists might be scheduling.
>
> The cardiologist will be using a cardiology-protocol-based care plan, 
> probably developed in splendid isolation from the endocrinologist activities.
>
> The rehab specialist will be using a purpose-built care plan for the 
> patient's recovery from a knee replacement.
>
> However it will be critical that the GP or coordinating primary care provider 
> develop/need a single global care plan, (which can be separated out for the 
> different purposes, if needed) that provides an overview of all activities 
> that the patient requires - what is due, overdue, planned etc. This will 
> ensure that the blood glucose and renal function tests required by both the 
> endocrinologist and cardiologist iare coordinated, if clinically appropriate 
> and tests/appts not repeated unnecessarily. They will have access to a 
> 'master' plan that will detail all reviews/goals/test/appointments for each 
> 'specialty' plan and have the ability to coordinate the components to suit 
> the best interests of the patient as a whole - a care plan for the patient, 
> not just one per problem.
>
> The patient or the parent/caregiver will also benefit with being able to 
> schedule appointments/tests etc.
>
> And we will need to be able to break down that master care plan to see which 
> components belong with each problem, or are shared between problems, and for 
> context-based sharing with other health care providers.
>


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

I guess smart querying services would do the work.  But should it also be 
possible for the client to say when unit conversion should be used and when not?

Use case is when user only want the units stored as grams,  and not kilos.

Maybe a pattern from HTTP could be used.  The accept pattern.

Accept: profile (metrics, british imperial)
Accept: gram, kilos

Of course all this add complexity and we must be sure that we really need it.


Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

 Original message 
From: Thomas Beale
Date:14/11/2014 10:14 (GMT+01:00)
To: openehr-technical at lists.openehr.org
Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible 
units


Should we have a way of marking the 'normative' units for computation /
conversion? So that then you only create AQL queries in the units you
want, and let the query service do the rest (e.g. by looking up the UCUM
DB)? In fact, you don't even need to mark anything as normative, if the
query service is smart, if would know how to do units comparisons. If it
hits weight data in other units, it does an on-the-fly conversion.

- thomas

On 14/11/2014 06:06, Bj?rn N?ss wrote:
> Thanks for your feedback on this small topic. I agree with your opinions, and 
> this may not be a huge problem. My point of view is not from an Archetype or 
> Template modelling point. I am more into Guideline modelling and population 
> queries.
>
> Take for instance the guide for Body Mass Index: 
> https://github.com/openEHR/gdl-tools/blob/master/cm/guidelines/BMI.Calculation.v.1.gdl
>  . This rule will be more complex if we add more units. Then the guideline 
> editor must consider all possible units and conversion between them. That is 
> of course doable and MUST be done if the clinical model say this is needed.
>
> Another use-case is population queries. If I want to find all entries of 
> body-weight that is between 0,3 and 3 kg. I must create a query that consider 
> all possible units; both grams and kilos from the metrics and lb from the 
> imperial. This is of course doable, but add more complexity when querying.
>
> I agree with you that this could be handled by templating. For a given system 
> we should use Templates that secure data quality, i.e. always use the same 
> unit for given use-cases.
>
> When I use the term system I do not mean one application. I am thinking about 
> the system of all health care applications in a large health enterprise or a 
> nation. If we only talk about applications this will not be a problem, 
> because you may/should have control on templates.
>
> @ian e.g very young children where some clinicians use grams and others use 
> kg for exactly the same patients in exactly the same circumstances.
> Yes - some clinicians want to use grams and other kgs. And I think the 
> application used to display data and/or create data should handle this.
>
> If I am, as a clinician,  used to think of a given quantity in grams, then I 
> want the application to give me data in grams. As clinician should not have 
> to use brain-capacity to convert between different units. Working in neonatal 
> I want all weights to be grams. But the question is if we then MUST add grams 
> to the Archetype?
>
> @ian Creating 2 different archetypes for each unit only moves the querying 
> complexity elsewhere (arguably worse).
> I agree when you put it like this :-). This would be a nightmare if we have 
> one archtype for each unit.
>
> And to bring back the postulate:  "DV_QUANTITY should be modelled with fewest 
> possible units". This only means that we should be restrictive when adding 
> more units because it may add complexity when using the archetype.


___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

I have been thinking about profiling. I am not sure if this fix the problem 
regarding complexity.
This may be an governance thing. If we define a metric and british imperial 
profile we may define that in Norway every application MUST use the metric 
profile and other countries may select ?british imperial?. This could make it 
easier to set up validation on entries.

Is this a usage you were thinking about?

Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: 13. november 2014 22:04
To: openehr-technical at lists.openehr.org; For openEHR clinical discussions
Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible 
units

On 13/11/2014 20:34, Bakke, Silje Ljosland wrote:

The original context for this discussion was this archetype: 
http://arketyper.no/ckm/#showArchetype_1078.36.25 (default archetype language 
for this CKM is Norwegian, but it can be changed manually)



Being an all-metric country since the 1800s, we've removed lbs as a possible 
unit, but added g (gram) for weighing infants.



There is something I have been thinking about for a while, which is whether we 
need some kind of 'profiles' in archetypes, that can be used select or deselect 
alternative constraints. An 'alternative' in an archetype is technically

  1.  an alternative object constraint under a single-valued attribute; 
example: a DV_QUANTITY and a DV_COUNT as siblings under ELEMENT.value 
representing 'amount of tobacco'
  2.  any optional object under a container attribute, typically with other 
siblings
  3.  any branch of a tuple (ADL 2 speak) or branch of C_DV_QUANTITY - this is 
the units example

So I have been thinking whether we need something like a profile section, with 
named profiles, pointing to the paths of things in (or not in) that profile. We 
could imagine profiles like:

profiles = <
["metric"] = 
["system international"] = 
["british imperial"] = <...>
["us imperial"] = <...>
>

Now the question is whether this just applies to units, or whether it's more 
global. For example, could there be an argument to create profiles for 'general 
practice', 'icu', 'aged care'? Consider the example of the BP archetype. It 
contains 'systolic pressure', 'diastolic pressure', 'pulse pressure' and 'mean 
arterial pressure'. Now the last two are only used in anaesthesiology and 
specific instruments (from memory); one could imagine some profiles that would 
select out pulse pressure for just 'anaesthesiology'.

Right now, this selection occurs by people specialising archetypes, and 
ultimately making templates, and along they way, getting rid of things they 
don't want, and keeping what they do. But there's no way you can run a query 
over an archetype library and filter it on some specialty, or even 'metric'.

But there are many other reasons for specialising and removing / keeping 
elements as well - geographical, legislative, anything...

So for now this remains just an idea - we would need some input from clinical 
modellers to know whether it's a useful one or not.

- thomas
-- next part --
An HTML attachment was scrubbed...
URL: 

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

An application need that kind of service.  But this is actually not the 
problem. See my latest mail regarding guildelines and population queries.


Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

 Original message 
From: pablo pazos
Date:14/11/2014 01:07 (GMT+01:00)
To: openeh technical ,openEHR Clinical
Subject: RE: Postulate: DV_QUANTITY should be modelled with fewest possible 
units

Hi Bj?rn,

IMO when you have complex unit processing, a lookup service for UCUM might be 
needed. UCUM contains multipliers and correspondences between different unit 
systems, check this:

http://unitsofmeasure.org/ucum-essence.xml

Using this, a constraint on archetypes might not be needed. What do you think?

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


From: b...@dips.no
To: openehr-technical at lists.openehr.org; openehr-clinical at 
lists.openehr.org
Subject: Postulate: DV_QUANTITY should be modelled with fewest possible units
Date: Thu, 13 Nov 2014 20:07:00 +


I want to try out a postulate regarding modelling of datavalues, and more 
specific DV_QUANTITY.



The postulate is:



Postulate 1: A data type of DV_QUANTITY should be modelled with fewest possible 
units!



Reason behind this is to make queries and reasoning over the values easy. This 
makes it both faster and safer  building sustainable software and systems using 
these values.

I also think that converting between i.e. grams and kilos should be done in the 
client (user interface / integration engine/ etc.).



What do you think?









Vennlig hilsen
Bj?rn N?ss
Product Owner
DIPS ASA

Mobil +47 93 43 29 10



___ openEHR-technical mailing list 
openEHR-technical at lists.openehr.org 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

Thanks for your feedback on this small topic. I agree with your opinions, and 
this may not be a huge problem. My point of view is not from an Archetype or 
Template modelling point. I am more into Guideline modelling and population 
queries. 

Take for instance the guide for Body Mass Index: 
https://github.com/openEHR/gdl-tools/blob/master/cm/guidelines/BMI.Calculation.v.1.gdl
 . This rule will be more complex if we add more units. Then the guideline 
editor must consider all possible units and conversion between them. That is of 
course doable and MUST be done if the clinical model say this is needed. 

Another use-case is population queries. If I want to find all entries of 
body-weight that is between 0,3 and 3 kg. I must create a query that consider 
all possible units; both grams and kilos from the metrics and lb from the 
imperial. This is of course doable, but add more complexity when querying. 

I agree with you that this could be handled by templating. For a given system 
we should use Templates that secure data quality, i.e. always use the same unit 
for given use-cases. 

When I use the term system I do not mean one application. I am thinking about 
the system of all health care applications in a large health enterprise or a 
nation. If we only talk about applications this will not be a problem, because 
you may/should have control on templates. 

@ian e.g very young children where some clinicians use grams and others use kg 
for exactly the same patients in exactly the same circumstances.
Yes - some clinicians want to use grams and other kgs. And I think the 
application used to display data and/or create data should handle this. 

If I am, as a clinician,  used to think of a given quantity in grams, then I 
want the application to give me data in grams. As clinician should not have to 
use brain-capacity to convert between different units. Working in neonatal I 
want all weights to be grams. But the question is if we then MUST add grams to 
the Archetype? 

@ian Creating 2 different archetypes for each unit only moves the querying 
complexity elsewhere (arguably worse).
I agree when you put it like this :-). This would be a nightmare if we have one 
archtype for each unit. 

And to bring back the postulate:  "DV_QUANTITY should be modelled with fewest 
possible units". This only means that we should be restrictive when adding more 
units because it may add complexity when using the archetype.



Vennlig hilsen
Bj?rn N?ss
Product owner 
DIPS ASA

Mobil?+47 93 43 29 10

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Heather Leslie
Sent: 14. november 2014 06:09
To: For openEHR technical discussions; For openEHR clinical discussions
Subject: RE: Postulate: DV_QUANTITY should be modelled with fewest possible 
units

I echo Ian's opinion.

The value of having an archetype with metric and imperial units inside the one 
asset is that if you use one unit, you can still compute if you receive data 
using the other units as you have a common model and clear relationship between 
units. Templates is where you select what you want for your use case. If you 
take one set of units out of your archetype then when you receive data using 
alternative units you are relying on application based assumptions of semantic 
equivalence, rather than the 'no-brainer' of using the same archetype, 
different units.

And the notion of managing/governing/maintaining profiles, on top of 
archetypes, templates, terminology subsets, GDL rules and AQL queries makes my 
modelling/governing head hurt. I don't think this is sustainable, even if it is 
desirable. IMO this is what templates are for.

Regards

Heather

> -Original Message-
> From: openEHR-technical [mailto:openehr-technical- 
> bounces at lists.openehr.org] On Behalf Of Ian McNicoll
> Sent: Friday, 14 November 2014 11:57 AM
> To: For openEHR clinical discussions
> Cc: openeh technical
> Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest 
> possible units
> 
> Hi Pablo,
> 
> I would agree, this information is also carried in the Archetype 
> Editor property files, although I suspect not as well maintained as the UCUM 
> file.
> 
> @Bjorn - I am not really sure why this is such a problem.
> 
> As a modeller I would expect to remove any unwanted/unneeded units at 
> template level. You would there fore only be having to deal with 
> situations such as body weight where in your context both grams or kg might 
> be specified.
> Again as a modeller I would want to reduce this complexity where 
> possible but there must be clinical situation e.g very young children 
> where some clinicians use grams and others use kg for exactly the same 
> patients in exactly the same circumstances.
> Creating 2 different archetypes for each unit only moves the querying 
> complexity elsewhere (arguably worse).
> 
> @Thomas - the profile suggestion is interesting but it feels to me 
> that it a

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

Se below: 

Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil?+47 93 43 29 10

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Diego Bosc?
Sent: 13. november 2014 21:23
To: For openEHR technical discussions
Cc: openehr-clinical at lists.openehr.org
Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest possible 
units

As mentioned on twitter, I agree with that postulate for templates, but not 
general archetypes :)

[Bj?rn N?ss] I partly agree. I agree that the Templates would adapt archetypes 
to a given use-case and as part of that constraint units. 

But my concern in bringing this up is the query part. I have been very lucky 
with archetypes that makes it possible to model and save the maximum dataset 
for every phenomena we meet. But then - when we are using queries, CDS, process 
support and reporting over archetyped data we need to reduce complexity where 
we can. Healthcare is a complex domain. The maximum dataset for simple 
observations like body temperature, body weight, etc. shows this. This is why I 
want to introduce this postulate to remember to keep complexity down as often 
as possible. 

Of course it is not hard to query over grams and kilos, compare them and do 
whatever we want. But the real question is why do we need to do that? 

For general archetypes that will be reused in different use-cases and different 
modules it is best to define the datastructure in a consistent way. And then 
leave it up to the user-interface to display the data in a way that fits the 
current user or user-group. 




2014-11-13 21:07 GMT+01:00 Bj?rn N?ss :
> I want to try out a postulate regarding modelling of datavalues, and 
> more specific DV_QUANTITY.
>
>
>
> The postulate is:
>
>
>
> Postulate 1: A data type of DV_QUANTITY should be modelled with fewest 
> possible units!
>
>
>
> Reason behind this is to make queries and reasoning over the values easy.
> This makes it both faster and safer  building sustainable software and 
> systems using these values.
>
> I also think that converting between i.e. grams and kilos should be 
> done in the client (user interface / integration engine/ etc.).
>
>
>
> What do you think?
>
>
>
>
>
>
>
>
>
> Vennlig hilsen
> Bj?rn N?ss
> Product Owner
> DIPS ASA
>
> Mobil +47 93 43 29 10
>
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> ehr.org

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

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Bjørn Næss]

I want to try out a postulate regarding modelling of datavalues, and more 
specific DV_QUANTITY.

The postulate is:

Postulate 1: A data type of DV_QUANTITY should be modelled with fewest possible 
units!

Reason behind this is to make queries and reasoning over the values easy. This 
makes it both faster and safer  building sustainable software and systems using 
these values.
I also think that converting between i.e. grams and kilos should be done in the 
client (user interface / integration engine/ etc.).

What do you think?




Vennlig hilsen
Bj?rn N?ss
Product Owner
DIPS ASA

Mobil +47 93 43 29 10

-- next part --
An HTML attachment was scrubbed...
URL: 

Archetype Naming proposals - do we need V0?

[Bjørn Næss]

I also agree on this. 

It is a good idea to decide the versioning from Archetype to Archetype. If 
there are no need for breaking changes in the Archetype then the version should 
not be altered. 

If some of the archetypes from a clinical point of view must be changed in a 
not backward compatible way then the Archetype should be either a) moved to a 
new version (v2) or b) if the changes are very large moved to a completely new 
Archetype. 

As many have said it is use at own risk when using Archetypes that is not 
approved. Said that , I think it is important to show that openEHR Archetypes 
is a safe choice for the long term. This is why we should not change naming and 
versioning without very good reasons. 

+1 for the proposal from Marand v/ Bostjan :-) 

Vennlig hilsen
Bj?rn N?ss
Product Owner 
DIPS ASA

Mobil?+47 93 43 29 10

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Heath Frankel
Sent: 13. oktober 2014 00:11
To: For openEHR technical discussions
Cc: For openEHR technical discussions; For openEHR clinical discussions
Subject: Re: Archetype Naming proposals - do we need V0?

I completely agree with this,
The number one priority is that all existing clinical data using archetypes 
published in CKM for the last 2-5 years is not Invalidated by this process. I 
understand that it was use at your own risk but surely vendors that have taken 
the risk to be early adopters get some support by the foundation.

I think we need to keep all archetypes in CKM as they are unless there is 
evidence that no one is using a particular archetype. They must be treated with 
the same status of published as new ones, they have passed the test of time and 
more importantly the test of implementation.

I see no problem with starting with v2 for the next iteration.

Regards

Heath

> On 7 Oct 2014, at 2:02 am, "Bo?tjan Lah"  wrote:
> 
> Hi everybody,
> 
> sorry for not jumping in this earlier...
> 
> We (Marand) are looking at this from a vendor point of view much like 
> Sebastian from Code24. We have quite a bit of existing data, apps with AQLs, 
> etc.
> 
> Now if I understood everything correctly we have two ways:
> - existing archetypes would initially change from v1 to v0.* something 
> and once published would become v1.0.0
> - existing archetypes would initially change from v1 to 
> v1.0.0-unstable (or -alpha - to be decided) and once published would 
> become v1.0.0
> 
> I have no problem with either style and think both would work equally well.
> 
> But this is not the only change - we would also add namespace to ids so final 
> (published) full archetype id would be:
> org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.0
> which includes namespace as well as new full version number.
> 
> So this makes change anyway much larger and needs to be tackled no matter if 
> versions in CKM now go to v0 or to v1*-alpha. 
> Even though archetype id will in fact not change in ADL1.4, other_details 
> will carry all the rest and we can already start using it. 
> 
> The question is - does it make sense to start using it while our whole stack 
> is still on ADL1.4 as it affects quite a few things:
> - existing stored RM data
> - RM paths - this might be in AQLs or other tools that use such paths
> 
> I would think this is too much hassle and would probably change to new 
> versioning only when we also support ADL2.
> 
> The only danger I see with this is that we'd suddenly have existing archetype 
> ids in the system with openEHR-EHR-OBSERVATION.lab_test.v1 which in CKM might 
> be completely different due to them going though the release process (back to 
> v0* or v1...-unstable) and finally becoming 
> org.openehr::openEHR-EHR-OBSERVATION.lab_test.v1.0.0.
> This case would indeed be solved by releasing them as v2.0.0 instead of 
> v1.0.0 - perhaps this can be on case-by-case basis - I assume not all 
> archetypes in the sprint will change in an incompatible way?
> 
> Best regards,
> --
> Bostjan Lah
> Marand d.o.o.
> 
>> On 5 Oct 2014, at 21:03, Sebastian Iancu  wrote:
>> 
>> On 10/3/2014 5:40 PM, Ian McNicoll wrote:
>> 
>> Hi Ian,
>> 
>>> Hi Sebastian,
>>> 
>>> Many thanks for your input. Your contribution is particularly important as 
>>> Code24 is, as you say,  one of the early pioneers of managing openEHR data 
>>> and related artefacts.
>>> 
>>> You have raised an important and very real issue, but I agree with 
>>> Sebastian Garde that the .V0 question itself, is actually not what is going 
>>> to potentially cause you a problem.
>>> 
>>> Firstly I would defend what has been done in CKM to date as being 
>>> completely in line with the specs and with the revisioning rules (which 
>>> actually have worked extremely well for published archetypes). It has 
>>> always been clear that any archetypes not marked as 'published' must be 
>>> considered unstable and cannot be guaranteed to follow the numbering rules. 
>>> I understand why you might take

New online archetype and template tooling project

[Bjørn Næss]

What a great start!
I really look forward to the next weeks in this important project.


Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

 Original message 
From: Erik Sundvall
Date:10/10/2014 18:03 (GMT+01:00)
To: openehr implementers
Cc: For openEHR technical discussions
Subject: New online archetype and template tooling project

Dear openEHR community!

The openEHR 2014 roadmap meeting in Norway agreed on starting a community 
tooling project to create a new open source based web-accessible archetype and 
template editing framework/workbench capable of ADL 2.0 (formerly named ADL 
1.5).

A wiki-page contains the basic info you need to join or monitor this effort:
http://www.openehr.org/wiki/display/dev/Online+archetype+and+template+tools
Please read that wikipage before asking about details on the mailinglist, and 
feel free to add thoughts and comments on that page.

This will be a joint open effort by industry, academia, healthcare 
organizations and other openEHR community members.

If you are interested in joining the first (and possibly the second) online 
live discussion hour in this project, then indicate preferred times on the 
"Doodle" at http://doodle.com/gm456xavg3fcgvw5 at latest during Monday (yes now 
October 13). It covers some of the upcoming weeks. Apologies for not providing 
perfect timing alternatives for all timezones around the globe. Joining the 
live discussion is of course _not_ a requirement to join the project, your 
ideas, contributions and feedback is welcome via other channels.

This mail is cross-posted to both the implementers and the technical lists, but 
please respond and discuss the project only on the implementers list 
openehr-implementers at lists.openehr.org or/and on the project wikipage mentioned above.

Best regards & happy hacking,
Erik Sundvall
(Coordinating http://openehr.org/programs/software/ )

Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 
010-1036252 in Sweden)
Li?: erik.sundvall at lio.se 
http://www.lio.se/itc/ & http://www.lio.se/testbadd
LiU: erik.sundvall at liu.se 
http://www.imt.liu.se/~erisu/
-- next part --
An HTML attachment was scrubbed...
URL: 

SV: Exception messages on TemplateDesigner 2.7.60.2

[Bjørn Næss]

Nice ;-)


Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10


 Opprinnelig melding 
Fra: Kjetil J?rgensen 
Dato: 28.11.2013 15.12 (GMT+01:00)
Til: For openEHR technical discussions 
Emne: RE: Exception messages on TemplateDesigner 2.7.60.2


Go to Tools -> Knowlegde Repository -> Edit repository list. Verify that you 
have set the template files directory. Had a similar problem and the solution 
was to set a default directory for template files.

With regards,
Kjetil J?rgensen
Developer
DIPS ASA
Telephone +47 75 59 21 18
Mobile +47 90 50 15 65

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of pablo pazos
Sent: 28. november 2013 15:03
To: openeh technical; openehr implementers
Subject: Exception messages on TemplateDesigner 2.7.60.2

Hi all, I'm creating a template from scratch with my own archetypes created 
using Archetype Editor (attached). When I try to save the template I get weird 
messages:

- Cannot access a disposed object. Object name: 'FileSystemWatcher'.
- Object reference not set to an instance of an object.

Any ideas?


[cid:image001.png at 01CEEC4B.DD7E7E40]

[cid:image002.png at 01CEEC4B.DD7E7E40]



--
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 38335 bytes
Desc: image001.png
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 38939 bytes
Desc: image002.png
URL: 

SV: Rich text format in DV_TEXT

[Bjørn Næss]

This is a very relevant issue.  We have the same in our application.  Some of 
the fields will be DV_TEXT but we want to show some rich formatting.

It is crucial to be compatible with Archetypes from CKM, and different vendors 
producing or consuming Archetypes.  So it is not an option to make changes on 
the Archetype.  Just as you tell.

We did not find any workarounds.  So any good idea or proposal is very welcome.


Vennlig hilsen
Bj?rn N?ss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10


 Opprinnelig melding 
Fra: Sebastian Iancu 
Dato: 23.09.2013 14.57 (GMT+01:00)
Til: For openEHR technical discussions 
Emne: Re: Rich text format in DV_TEXT


Hello,

Actually the question is more generic, the archetype itself is not very 
important.

What we need is to store rich-text (html from a web-editor) on a DV element. 
The text may include several paragraphs, and a few simple formatting tags like 
bold, italic, colors, etc. To my knowledge, to accomplish this the RM 1.0.2 
specifications is suggesting DV_PARAGRAPH (with DV_TEXT chunks holding 
necessary formatting) or alternatively DV_PARSABLE (with formalism=html). In 
any case not a single plain DV_TEXT.

Thus, if we intend to use published archetypes on CKM 
(openEHR-EHR-EVALUATION.clinical_synopsis.v1), from your experience what is the 
best option:
- use DV_TEXT chunks/elements (with or without DV_PARAGRAPH) with the right 
formatting ( = not an easy option to implement in our app, and also that 
specific archetype is not prepared for that)
- specialize the archetype the so that allows also DV_PARAGRAPH or DV_PARSABLE 
( = I don't think that is allowed by the owned constraints)
- propose changes to RM so that DV_TEXT allows also 'simple' rich-text content, 
like html for instance, and not only per-word-formatting
- create our own local archetypes based on CKM version, but with the 'right' DV 
elements ( = not a nice option considering knowledge management)
- or use a single DV_TEXT, and misuse its 'value' to hold also html.

Thanks,
Sebastian Iancu



On 9/23/2013 5:06 AM, Heather Leslie wrote:
Hi Alessandro,

Curious as to the use case for the DV_PARSABLE. Can you share?

I?ll let the engineers discuss potential enhancements to the datatype?

Heather

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Alessandro Torrisi
Sent: Friday, 20 September 2013 11:57 PM
To: For openEHR technical discussions
Subject: Rich text format in DV_TEXT

Hello,

we are using an archetypes from the CKM called 
openEHR-EHR-EVALUATION.clinical_synopsis.v1. Over there is an DV_TEXT element 
called Synopsis

One of our clients want to use rich text format inside that field. According 
the specification it is not allowed to put formatted text over there. I rather 
should use a DV_PARSABLE.

How should i handle this correctly? The options i see are :
- specialise the archetype and add an DV_PARSABLE, and leaf the existing 
DV_TEXT empty
- create my own archetype where I set the Synopsis element to a DV_PARSABLE

beside this question, i wonder if it will be better to give the DV_TEXT 
datatype the possibility to put over there rich text. If we also add the 
parameter formalism to it, there is no really need any more for a DV_PARSABLE.

--
Alessandro Torrisi



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

-- next part --
An HTML attachment was scrubbed...
URL: 

SV: State transitions - ACTIVITY/ACTION

[Bjørn Næss]

Great.

I wrote an e-mail earlier that did not get to the mailing list. Content was:

There is one more "missing link" in my understanding:
Given that there is an ACTIVITY in INITIAL state and the user want to cancel 
the ACTIVITY; then it should be possible to do a transition from INITIAL 
directly to CANCELLED state.

One reason to do this is if the patient dies.

This transition is not defined in the state machine - as far as I can see. 
First I thought that the right way to do this was to remove the ACTIVITY. But 
after some thinking I was not satisfied with this solution. I think it would be 
correct if the ACTIVITY was terminated in CANCELLED state.

Do I misunderstand something or should this also be a possible transition?


With regards,
Bj?rn N?ss
Product owner
DIPS ASA
Telephone +47 75 59 24 55
Mobile +47 93 43 29 10


Fra: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] 
P? vegne av Thomas Beale
Sendt: 11. september 2013 18:06
Til: openehr-technical at lists.openehr.org
Emne: Re: State transitions - ACTIVITY/ACTION

On 10/09/2013 09:38, Bj?rn N?ss wrote:
Hi all.

We are discussing some details with the INSTRUCTION STATE MACINE. I will go 
directly to my two questions:

1
The state machine define transition from all not-terminated states to a 
terminated state. Except from POSTPONED state. There is no defined transition 
from POSTPONED to CANCELLED. The question is how we should model the scenario 
where the ACTIVITY is in POSTPONED and the user want to CANCEL the ACTIVITY in 
one step?

Is there a missing transition in the specification or did we misunderstood 
something?

yes, this should be added in.



2
There is a time_out transition from all not-terminated step to EXPIRED. Except 
from Scheduled. There is no time_out transition defined from SCHEDULED to 
EXPIRED

Given the scenario is SCHEDULED and the time for start of the ACTIVTY is 
passed. Should there be a transition named time_out from SCHEDULED to EXPIRED. 
When this transition occurs then system should be notified in some way.

Is there a missing transition named time_out from SCHEDULED or do we 
misunderstood something?


we should also add this in.

- thomas
-- next part --
An HTML attachment was scrubbed...
URL: 

SV: State transitions - ACTIVITY/ACTION

[Bjørn Næss]

Hi
Yes that is my opinion as well.

And there is one more "missing link" in my understanding:

Given that there is an ACTIVITY in INITIAL state and the user want to cancel 
the ACTIVITY; then it should be possible to do a transition from INITIAL 
directly to CANCELLED state.

This transition is not defined in the state machine - as far as I can see.

First I thought that the right way to do this was to remove the ACTIVITY. But 
after some thinking I was not satisfied with this solution. I think it would be 
correct if the ACTIVITY was terminated in CANCELLED state.

One reason to do this is if the patient dies.

With regards,
Bj?rn N?ss
Product owner
DIPS ASA
Telephone +47 75 59 24 55
Mobile +47 93 43 29 10


Fra: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] 
P? vegne av pablo pazos
Sendt: 10. september 2013 23:30
Til: openeh technical
Emne: RE: State transitions - ACTIVITY/ACTION

Hi Bj?rn, I think your points are correct, and there are some missing 
transitions on the ISM.


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

From: bna at dips.no
To: openehr-technical at lists.openehr.org
Date: Tue, 10 Sep 2013 10:38:47 +0200
Subject: State transitions - ACTIVITY/ACTION
Hi all.

We are discussing some details with the INSTRUCTION STATE MACINE. I will go 
directly to my two questions:

1
The state machine define transition from all not-terminated states to a 
terminated state. Except from POSTPONED state. There is no defined transition 
from POSTPONED to CANCELLED. The question is how we should model the scenario 
where the ACTIVITY is in POSTPONED and the user want to CANCEL the ACTIVITY in 
one step?

Is there a missing transition in the specification or did we misunderstood 
something?

2
There is a time_out transition from all not-terminated step to EXPIRED. Except 
from Scheduled. There is no time_out transition defined from SCHEDULED to 
EXPIRED

Given the scenario is SCHEDULED and the time for start of the ACTIVTY is 
passed. Should there be a transition named time_out from SCHEDULED to EXPIRED. 
When this transition occurs then system should be notified in some way.

Is there a missing transition named time_out from SCHEDULED or do we 
misunderstood something?

With regards,
Bj?rn N?ss
Product owner
Telephone +47 75 59 24 55
Mobile +47 93 43 29 10
www.dips.com

[cid:image001.png at 01CEAF16.E6344690]

This message is for the designated recipient only and may contain confidential 
or private information. If you have received it in error, please notify the 
sender immediately and delete the original.


___ openEHR-technical mailing list 
openEHR-technical at lists.openehr.org 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4149 bytes
Desc: image001.png
URL: 

State transitions - ACTIVITY/ACTION

[Bjørn Næss]

Hi all.

We are discussing some details with the INSTRUCTION STATE MACINE. I will go 
directly to my two questions:

1
The state machine define transition from all not-terminated states to a 
terminated state. Except from POSTPONED state. There is no defined transition 
from POSTPONED to CANCELLED. The question is how we should model the scenario 
where the ACTIVITY is in POSTPONED and the user want to CANCEL the ACTIVITY in 
one step?

Is there a missing transition in the specification or did we misunderstood 
something?

2
There is a time_out transition from all not-terminated step to EXPIRED. Except 
from Scheduled. There is no time_out transition defined from SCHEDULED to 
EXPIRED

Given the scenario is SCHEDULED and the time for start of the ACTIVTY is 
passed. Should there be a transition named time_out from SCHEDULED to EXPIRED. 
When this transition occurs then system should be notified in some way.

Is there a missing transition named time_out from SCHEDULED or do we 
misunderstood something?

With regards,
Bj?rn N?ss
Product owner
Telephone +47 75 59 24 55
Mobile +47 93 43 29 10
www.dips.com

[cid:image001.png at 01CEAE11.EE4E29A0]

This message is for the designated recipient only and may contain confidential 
or private information. If you have received it in error, please notify the 
sender immediately and delete the original.

-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4149 bytes
Desc: image001.png
URL: 

SV: openEHR-technical Digest, Vol 18, Issue 50

[Bjørn Næss]

You are absolutely right.  Yesterday I where in a meeting with two national 
stakeholders for data specification regarding patient with drug/alcohol 
problems.  The problem we as a vendor and our customers and users face is that 
they ask for almost the same thing.  And they can not agree.  That's when they 
ask if we, as a vendor, can map between the terms.

I said no. I said you have to agree about the meaning of your data.  Then, 
maybe, we can do the mapping.  Or even better: there will be no mapping and we 
can reuse data inside the EHR and between different organisations.

The base of semantic interoperability is in a firm core definition of what the 
data is about.  Then the software can let magic things happen.


Bj?rn N?ss
Product Manager
DIPS ASA

Mobil +47 93 43 29 10


 Opprinnelig melding 
Fra: Thomas Beale 
Dato: 31.08.2013 10.12 (GMT+01:00)
Til: openehr-technical at lists.openehr.org
Emne: Re: openEHR-technical Digest, Vol 18, Issue 50


On 30/08/2013 17:42, William Goossen wrote:

Semantic interoperability is absolutely compromised when for the same clinical 
concept variants of archetypes are created.
If justified for internal system development , the moment exchange with another 
system requires harmonizing on datapoint to datapoint level. I have done about 
2000 in perinatology 800 in stroke care 1250 in youth care 100 in nursing 
oncology 20 in reuma, 400 in general nursing 250 in diabetes care 200 in GP 
care 100 in cardiology. In the past 13 years.
The inconsistencies for the same data element in the various domains are BIG, 
without clinical justifiable reasons.
That same situation exists if you have locally / vendor specific arechetypes .



The same situation exists if you have local, regionally and nationally 
competing HL7 messages, CDAs, FHIR specs, CCDs, DICOM-SR, NCI BRIDG models, and 
all the rest. That is the situation today.

Archetype technology doesn't solve the problem of organisations not 
collaborating, it just gives much better technical support and capability for 
building semantic specifications of content and creating software and UI from 
them.

The sociological problem still needs work. That's why identification, 
governance, and networks of cooperation are important.

Still, we didn't get nowhere. Now everyone seems to agree on how systolic BP 
should be represented :)

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

SV: ACTIVITY and timing

[Bjørn Næss]

Hi Pablo
Thanks for the quick response!

I guess you are right regarding Cron and ISO 8601 when it comes to implement 
the DV_PARSABLE attribute timing on the ACTIVITY class.

The openEHR-EHR-CLUSTER.timing.v1 is developed to define "structured 
information about the timing (intended or actual) of administration or use of a 
medicine, other therapeutic good or other intervention that is given on a 
scheduled basis." And it's intended use is  "with medication orders and other 
instructions where timing is complex and needs to be computable." This 
archetype does also include a parsable element named "parsable syntax".

So the key question is: To be able to exchange structured information about 
timing - would it be better to use openEHR-EHR-CLUSTER.timing.v1 or should we 
use the mandatory parsable timing attribute on ACTIVITY class?

I can see pros and cons:

Use the attribute on ACTIVITY class:

? To use an attribute that is always present (in EHR Information Model).

? To reduce clinical modeling effort - since you don't have to include 
structure about timing in every ACTIVITY.
(I guess clinical modeling should be done with specialization some way to 
define an Action  Archetype with timing information).

Use the openEHR-EHR-CLUSTER.timing.v1 (or another defined structure)

? to be able to share timing information as Archetype defined structure 
between openEHR enabled systems .

? to be able to let the Clinical Modeling people define the complexity 
of timing in HealthCare

I can also see some challenges with the optional attribute WF_DEFINITION on the 
INSTRUCTION class and the mandatory attribute timing on the ACTIVITY class. I 
think there will be some correlation between these attributes in a given 
use-case.

With regards,
Bj?rn N?ss
Product owner
Telephone +47 75 59 24 55
Mobile +47 93 43 29 10
www.dips.com

[cid:image001.png at 01CE9670.54B7FA90]

This message is for the designated recipient only and may contain confidential 
or private information. If you have received it in error, please notify the 
sender immediately and delete the original.

Fra: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] 
P? vegne av pablo pazos
Sendt: 10. august 2013 14:21
Til: openeh technical
Emne: RE: ACTIVITY and timing

Hi Bj?rn,

I don't use timing yet, but only because the healthcare domains I'm working on 
doesn't require complex timing management.
Said that, I have investigated how to use timing for more complex scenarios, 
like hospitalization medication management.

One option is to use cron expressions. That's great because is a de facto 
standard for developers, and linux support that at the OS level. So it's 
something that you can write/parse but also execute to trigger events. Another 
option would be to use ISO 8601 duration notation, standard and easy to 
create/parse. I'm sure there are more options out there, but I would recommend 
those two.

In my opinion the current specs lack information about how to use timing, and 
that makes things more complex to us (developers).

http://en.wikipedia.org/wiki/Cron
http://en.wikipedia.org/wiki/ISO_8601

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

From: bna at dips.no
To: openehr-technical at lists.openehr.org
Date: Sat, 10 Aug 2013 10:24:14 +0200
Subject: ACTIVITY and timing
Hi
ACTIVITY has a field for timing.  It's datatype is parsable.
Some archetypes use a CLUSTER archetype to define detailed timing information 
for the given ACTIVITY.

I am curious if anyone have experiences with implementing timing for Activity 
and which strategy you are using?
Will detailed timing information in a CLUSTER make timing information on 
Activity obsolete? Or will detailed timing information on Activity remove the 
need for a timing CLUSTER?



Bj?rn N?ss
Product Owner
DIPS ASA

Mobil +47 93 43 29 10
___ openEHR-technical mailing list 
openEHR-technical at lists.openehr.org 
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4149 bytes
Desc: image001.png
URL: 

ACTIVITY and timing

[Bjørn Næss]

Hi
ACTIVITY has a field for timing.  It's datatype is parsable.
Some archetypes use a CLUSTER archetype to define detailed timing information 
for the given ACTIVITY.

I am curious if anyone have experiences with implementing timing for Activity 
and which strategy you are using?
Will detailed timing information in a CLUSTER make timing information on 
Activity obsolete? Or will detailed timing information on Activity remove the 
need for a timing CLUSTER?



Bj?rn N?ss
Product Owner
DIPS ASA

Mobil +47 93 43 29 10
-- next part --
An HTML attachment was scrubbed...
URL: 

SV: How to model this XML type as Archetype?

[Bjørn Næss]

Hi Ian
Thank you for a quick response!

Ok - so my modeling is ok :) Still there is a minor problem/challenge. I have 
to make a report from the Archetype. Given the following value instance of the 
archetype element:



  AccidentSite_001


  T - Other transport area 
  

  local

at0074
  



I need to transform this into the following XML element in the report:



As I can see there is no way to model the key of the coded text ("T"). I can do 
some business logic to look up the value from an external terminology. But it 
would be simple and clean if I could model the key ("T") in the Archetype. Then 
a value instance could look like this:



  AccidentSite_001


  T - Other transport area 
 T
  

  local

at0074
  



Are there anyone facing the same problem? How do you handle this?

With regards,
Bj?rn N?ss
Product owner
Telephone +47 75 59 24 55
Mobile +47 93 43 29 10
www.dips.com

[cid:image001.png at 01CE50BF.24E24FB0]

This message is for the designated recipient only and may contain confidential 
or private information. If you have received it in error, please notify the 
sender immediately and delete the original.

Fra: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] 
P? vegne av Ian McNicoll
Sendt: 13. mai 2013 10:45
Til: For openEHR technical discussions
Emne: Re: How to model this XML type as Archetype?

Hi Bjorn,

This is exactly how I would have modelled it. This is not really an Ordinal 
which implies some sort of ordering or scale of the values e.g -,0,+,+++,.

In your examples the letters V, T , B , G etc are really just shortcuts.

Ian

}



On 13 May 2013 06:22, Bj?rn N?ss mailto:bna at dips.no>> wrote:
Authorities require the reporting of injury. It is defined XSD for the message 
to be sent. Some items have numbers. These are perfect ordinal. The problem is 
the following XML type. How should these be modeled as archetype data types?


 






   


So far I have modelled it like below. Is there a better way? I wish I could use 
ordinal with letters

ELEMENT[at0072] occurrences matches {0..1} matches { -- Skadested
value matches {
   DV_CODED_TEXT matches {
   defining_code matches {
   [local::
   at0073,  
   -- V - Vei, gate, fortau, gang- , sykkelvei
   at0074,  
   -- T - Annet transportomr?de
   at0075,  
   -- B - Bolig boligomr?de
   at0076,  
   -- G - Jordbruksbedrift, skogbruk
   at0077,  
   -- I - Institusjon, sykehus, syke-, adershjem, off.kontor
   at0078,  
   -- H - Lekeplass
   at0079,  
   -- S - Skole, h?yskole, universitet, barnehage, familiebarnehage i 
privat hjem eller liknende skolefritidsordning
   at0080,  
   -- P - Sport-, idrettsomr?de (ogs? p? skole/h?yskole/universitet)
   at0081,  
   -- N - Fri natur, hav, sj? og vann
   at0082,  
   -- A - Annet skadested
   at0083] -- U - 
Ukjent skadested
   }
   }
   }
}


With regards,
Bj?rn N?ss
Product owner
Telephone +47 75 59 24 55
Mobile +47 93 43 29 10
www.dips.com

This message is for the designated recipient only and may contain confidential 
or private information. If you have received it in error, please notify the 
sender immediately and delete the original.


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



--
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

How to model this XML type as Archetype?

[Bjørn Næss]

Authorities require the reporting of injury. It is defined XSD for the message 
to be sent. Some items have numbers. These are perfect ordinal. The problem is 
the following XML type. How should these be modeled as archetype data types?


 






   


So far I have modelled it like below. Is there a better way? I wish I could use 
ordinal with letters

ELEMENT[at0072] occurrences matches {0..1} matches { -- Skadested
value matches {
   DV_CODED_TEXT matches {
   defining_code matches {
   [local::
   at0073,  
   -- V - Vei, gate, fortau, gang- , sykkelvei
   at0074,  
   -- T - Annet transportomr?de
   at0075,  
   -- B - Bolig boligomr?de
   at0076,  
   -- G - Jordbruksbedrift, skogbruk
   at0077,  
   -- I - Institusjon, sykehus, syke-, adershjem, off.kontor
   at0078,  
   -- H - Lekeplass
   at0079,  
   -- S - Skole, h?yskole, universitet, barnehage, familiebarnehage i 
privat hjem eller liknende skolefritidsordning
   at0080,  
   -- P - Sport-, idrettsomr?de (ogs? p? skole/h?yskole/universitet)
   at0081,  
   -- N - Fri natur, hav, sj? og vann
   at0082,  
   -- A - Annet skadested
   at0083] -- U - 
Ukjent skadested
   }
   }
   }
}


With regards,
Bj?rn N?ss
Product owner
Telephone +47 75 59 24 55
Mobile +47 93 43 29 10
www.dips.com

[cid:image001.png at 01CE4FA9.58399880]

This message is for the designated recipient only and may contain confidential 
or private information. If you have received it in error, please notify the 
sender immediately and delete the original.

-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4149 bytes
Desc: image001.png
URL: